Requirements analysis

There is, as Ansel Adams is supposed to have said "nothing worse than a sharp image of a fuzzy concept". Requirements analysis is the bit of a project in which we try to reach a coherent and complete vision of what the finished project will be like, and ensure that we all have the same image! It is very hard to do well and very easy to discover later that document describing the requirements has something important missing or some error, for all that everyone was willing to sign it off at the time.  This post examines some of the problems and suggests a tool or two.

One problem is that requirements can come in from all sides: One model for requirements gathering has the catchy acronym FURPS+ (excuse me :-)  ); the acronym reminds us to look for requirements in:

• Functionality
• Usability
• Reliability
• Performance
• Supportability
• Plus some other places!

A related problem is that requirements have to be collected from different parts of the project team - some will come from the business side of the house others won't be apparent until we're trying to decide how to build it. Issues of importance to one faction may be gobbledygook to another:

"You’ve had numerous meetings with the development team, with QA and operations. On the whiteboard there’s an orphaned sub-system component that is bracketed and crossed out in red, because that embarrassing dead end was drawn with an indelible marker-pen and you cannot erase it. You’ve taken the output from these sessions, rendered it in Visio, peer reviewed it and exported it to PowerPoint. You’re especially pleased with the logical sequencing of the slide builds that animate how each of the system components fits together.

And now, you’ve just finished presenting the system architecture to the end-users and client. “Any questions?” you ask, hopefully. No one responds. They stare blankly back at you. But then, to your relief, the silence is broken. “No. It all looks good to me,” replies one of the stakeholders. “But it’s technical stuff. And that’s your bag, not mine.”

When eliciting stakeholder input to architectural requirements, this is the primary impediment. Mostly, it’s neither technophobia nor aversion; it’s that they just don’t get it. Technology is your domain, not theirs. “Looks good to me” is your problem, not theirs…because without their input and viewpoint, your architecture will be biased toward a technical--not a business--solution (at least in their eyes)."

(From Building Architectural Requirements, Bit by Bit, by Ian Whittingham, PMP September 24, 2007)

It can be difficult to find sensible compromise when requirements clash, or indeed to see that there is a clash. In a very interesting set of articles (and a book), Mark Kozak-Holland has examined the story of the Titanic, drawing parallels with software projects. He has an interesting example  of the clash between business and technical requirements:

In the end, Titanic's architects opted to go with the highest level of safety and incorporate all the latest and advanced safety technologies. After all, they were building the best ship they could based on the latest emerging technologies. However, Titanic's architects started to make compromises to these safety features because of executive business pressure, notably from White Star Director Bruce Ismay, who wanted to create the ultimate passenger (first-class) experience. For example, four of the bulkhead walls did not reach the top deck and were only 10 feet above the water line, to make room for a spacious 200 foot ballroom. Similarly, triple stacked lifeboats (48 in all) that would have obscured the ocean vista from the first-class suites were compromised for a single but much lower bank of 16 lifeboats.

Similarly, in today's IT projects hundreds of micro-decisions are made daily or weekly, decisions that are deemed too technical for business executives. Non-functional requirements are typically beyond the comfort zone of most business executives, so any compromises to these may not be readily understood. Yet they may have a major impact later once the solution is in production and affect the business itself.

[from IT Project Lessons from Titanic (Part 3) by Mark Kozak-Holland October 20, 2003]

Another problem is that requirements gathering seems like preparation for the project rather than the project itself - it is easy to rush on to "the doing bit".

Walt Washburn has recently published some helpful ideas in an article called Requirements Practices Every Project Manager Must Know (September 26, 2007). One thing I like about this is the spreadsheet he has (available from a link in the article), as a method of keeping all the requirements information organized. This tries to get the requirements into a list of things each starting with an assumption, leading to a  requirement and a plan for testing whether it has been met. The other "tedious spreadsheet" one would want to link into, it seems to me is the risk log - requirements work is a rich source of risks (to a project manager a risk is something that might happen, and would require some change to the project if it did happen). Requirements work can also be a great source of exclusions (exclusions are things that are not included in the current project - for example because they are nice-to-have features that are too expensive, would take too long to build, or have been considered and then abandoned for some other good reason). It is certainly a good idea to keep a list of exclusions (some business case templates have a section for them, for example). Having a list of exclusions is very useful when some of that material comes up for discussion again, as it has a habit of doing during a project. We have agreed we are not doing the exclusions, you say  - perhaps they can be done  in a future project, for now we need to concentrate on finishing on schedule.

Use cases (or the related idea, personas) can be a very useful way of checking the requirements. A use case is a run through of what the system does when an imaginary user tries to do a specific imagined task.  A persona is a fictitious but typical user of the system who has been assigned a personality and requirements- we can try to decide whether the design will meet the needs of "Lorna Librarian" "Sammy Student" and the like, and may catch problems.

Cheap and quick prototypes can also be very useful; very simple and inexpensive ones such as paper prototypes or PowerPoint shows may be fitted into the requirements analysis as a test that   we have the concept sharp as well as the image. Whether the results are then as beautiful as the photographs of Ansel Adams is of course still in the balance...

Comments

[prerna]

nice article

[Craig Brown]

This post has been included in the 5th edition of the Carnival of Business Analysts which has been published at Better Projects.

The Carnival is a series of blog posts that collect other qualityblog posts on topics themed around the BABOK knowledge areas. Edition 5 is on Requirements Analysis.

Read the Carnival of Business Analysts at Better Projects.