• Elicit the Details: Business stakeholders and development teams often speak very different languages. So if we start with a handoff of a requirements document, we often find out - much too late - that what we thought they wanted and what they actually wanted are very different things. By getting involved in the elicitation process, developers can ensure that the project team is using as many ways possible to ensure that everyone is speaking the same language.
• Ask Questions: When defining requirements, there are two key questions that must be addressed: What is the application supposed to do and how is it going to do it? Often teams focus only on one. Or, worse, some stakeholders can be focused on the question of "what" while the others are focused more on the "how." This inevitably leads to shortcomings in the finished application. The methods that can be used for requirements elicitation and gathering depend on the extent that various groups will agree to be involved. Workshops, where stakeholders explore user scenarios and use cases, can work well when user representatives are available. In situations where there are many different stakeholders, questionnaires and surveys may be the way to go. Individual interviews with subject matter experts are also useful as are building interactive prototypes. The more of these vehicles you can get involved in, the more discussion takes place upfront. This gives you the opportunity to ask more questions, clarify and ensure that there is truly understanding between what the business is saying it wants, and what it is you can actually build for them.
• Create User Scenarios: Discussions that focus on users and how they're going to use a product, application, or system generally yield great results. Users and business stakeholders generally find it more natural to describe their business tasks and usage goals than to define all of the functionality they expect to see in a product. Use cases, scenarios, and user stories are related terms that are frequently used to describe a system's user requirements. Use cases don't replace the need to define the detailed functional requirements that will ultimately be implemented. However, exploring use cases or user scenarios can help ensure that the requirements you implement will ultimately allow users to accomplish their goals.

• Create Analysis Models: The natural language requirements found in the average specification document are full of ambiguities, redundancies and gaps. To decompose high-level requirements into detailed, specific functional requirements, it can be helpful to build analysis models. Analysis models are graphical diagrams that visually outline requirements. This makes it easier to uncover missing or redundant requirements by taking away the tedious and error-prone tasks of reading through piles of text. While you may immediately be thinking that this is something that you can do using UML, it's likely that you'll need to create models for this stage of the process at an even higher level of abstraction to ensure that the business user can get the big picture.
• Build and evaluate prototypes: A prototype provides opportunities to interact with a simulation or portion of the final system. Basically, prototypes bring use cases to life. A prototype or set of screen designs doesn't show the business logic happening behind the scenes or illustrate the complete behavior of the application in all scenarios. It can't indicate how all exceptions and error conditions are going to be handled. However, when used with the right audience, a prototype can be invaluable in helping everyone get on the same page about existing requirements for a new system.
• Prioritize Requirements: Every software development organization has limits around resources and time. Therefore every team needs to determine which of its allocated requirements are most important. Prioritizing requirements allows teams to implement the right sets of user functionality in the right sequence. Prioritization should be a collaborative process that involves both a customer and a technical perspective to balance customer value against cost and technical risk.

• Look for ambiguities: Requirements written in natural language are filled with ambiguity. Negative requirements, sets of vague and subjective terms, complex logic, omissions, synonyms, and adverbs lead to multiple interpretations by different readers. It is cheaper to correct ambiguities in the requirements phase than to deal with disappointed customers. As a result teams should establish an agreed upon vocabulary prior to writing requirements.
• Store Requirements in a Database: By storing requirements in a commercial requirements management tool, teams can overcome many of the limitations imposed by textual documents. Requirements management tools make it easy to store additional information and attributes about different classes of requirements information. They facilitate tracking requirement status and provide a mechanism for retaining requirements that have been rejected or approved, and later deleted from a baseline. The tools also make it easier to work with groups of requirements that are intended for multiple future releases. In addition, organizations that keep requirements in a shared online database can better facilitate communication and collaboration among distributed teams.
• Trace Requirements into Design, Code and Tests: It is valuable to be able to link each software functional requirement back to its origin, so teams should embrace traceability information that connects functional requirements to associate design elements, code segments and tests to accelerate debugging and software maintenance. Requirements management tools can be a great aid to managing traceability data.

• Review the Requirements: The best quality practice available to software teams is formal peer review of requirements documents. Peer review provides an indication of how well others understand the requirements and ensure that they communicate clearly, effectively and efficiently to the various stakeholders. The analyst should create complementary views of the requirements selected from textual requirements, analysis models, scenarios, prototypes, tests and other representations - all of which can be reviewed concurrently. All project stakeholders should review the requirements to ensure accuracy, completeness, and the optimal level of detail to deliver software that truly meets the business needs.
• Create tests cases from requirements: Teams should begin testing as soon as they have some requirements in hand. Deriving test cases from use cases and scenarios is a valuable way to find problems in the use cases themselves.

• The design and coding tasks can follow the models already agreed upon by the business analysts, user and IT staff, so misunderstanding and miscommunications are dramatically reduced;
• Because there will be fewer clarification and adjustments later on, rework is reduced;
• Features are developed with respect to priority, so unnecessary or superfluous elements are less likely to bog down the projects progress;
• Testing and QA can be carried out directly against the requirements; there's no opportunity for the quality teams to be focused on the wrong test cases;
• Testing and QA can be performed more quickly and efficiently - earlier in the lifecycle and as development progresses - saving time and money over the traditional practice of testing the finished code against requirements; and
• End user satisfaction rises, because the finished product matches the initial expectations and requests.

Trackback(0)

TrackBack URI for this entry

Comments (1)

Subscribe to this comment's feed

Bob Whitehead said:

... Much of what the author proposes is achievable if one simply writes the software's reference manual, user's guide, and tutorial before coding the program. Since these documents describe in detail how an application works, writing the documents (complete with GUI design, outputs, and error messages) would provide a very useful design specification. This approach doesn't cover what goes on behind the scenes, of course, but one can make the format of the documentation flexible enough to accommodate the information.

report abuse vote down vote up

October 29, 2007
Votes: +0

Write comment