What would you think if I sang out of tune
Would you stand up and walk out on me?
Lend me your ears and I'll sing you a song
And I'll try not to sing out of key
(With a little help from my friends - Lennon/McCartney)
If requirements management practices were songs entering a popularity contest, requirements validation would hardly be a favorite contender. It's easy to understand why: validation is usually a tedious, time consuming task, and, as with nearly every quality control activity, it is supposed to reveal defects, going against our natural desire of being right, not making mistakes, and singing in tune.
Even within the field of quality control, validation is typically a relegated concept. Many software standards and industry practices focus almost entirely on verification activities, such as integration testing and code inspections. Verification is important to determine whether the product meets the established requirements, but despite its lack of appeal, validation is a crucial step to ensure that the requirements themselves are correct and satisfy business and user needs.
Several validation techniques are available for determining that requirements are "in tune"--free from ambiguities, inconsistencies, redundancies, omissions, and other problems that will prevent them from being a reliable foundation for design and for final system verification. These techniques include informal reviews, requirements inspection, prototyping, and requirements testing, among others.
Informal reviews
During the requirements phase in a traditional software development life cycle, the analyst may benefit from talking to a few stakeholders, analyzing the information received, and submitting some fragments of a specification for a quick, informal stakeholder review. This type of preliminary review is useful for collecting initial feedback and for fact-finding and fact-validating.
For many companies, informal reviews are the only method of requirements validation. In agile environments, requirements analysis typically occur in small, informal stages throughout the development life cycle, with face-to-face communication and user stories serving as anchors for requirements refinement and validation. Clearly, the effectiveness of this type of validation depends heavily on the quality of the interaction between customers and the development team. If high-quality interaction is not possible due to customer unavailability, lack of consensus, or other factors, this approach poses a serious risk of producing requirements that are inadequately developed or, even worse, wrong.
Requirements inspection
When a formal requirements process exist, a full inspection can complement the work done via informal reviews.
Inspection is a well-known type of formal peer review, in which a small team of inspectors can be assembled representing different perspectives (such as analyst, customer, developer, and tester) to perform a careful exam of the SRS, use cases, or any other important requirements document. Requirement inspections occur after elicitation, analysis and specification are completed for a given set of requirements. The inspection team typically follows a well-defined process and produces a report containing their judgment as to whether the requirements are correct, complete, clear and verifiable enough for design to begin.
Some researchers suggest that inspection meetings are too labor intensive to be justifiable, but in many cases these meetings can reveal defects that none of the reviewers would have found working individually. Grady and Van Slack (1994), among other authors, report an economy of as much as 10 hours of labor for every hour invested in inspecting requirements documents and other software deliverables. When a team doesn't have the time to inspect everything, risk analysis can be used to differentiate requirements that demand inspection from less critical documents for which an informal review will suffice.
Prototyping
Even requirements that look good on paper may reveal conflicts, omissions, and other problems during a demonstration of system behavior using a prototype. Rapid prototyping can accelerate the discovery of specification errors that would be easily missed in a requirements walkthrough due to a gap between the users' intentions and the actual specification (not necessarily attributable to requirements inconsistency or omission).
Some organizations substitute prototypes for formal requirements documents to validate and refine requirements without incurring the overhead associated with creating requirements documentation.
Requirements testing
In requirements testing, test cases are derived early in the project life cycle to validate the requirements stated in the SRS or other requirements documents. Requirements testing helps identify incomplete and ambiguous requirements because the inability to associate a test case with a particular requirement indicates a problem with a requirement statement.
- - - - -
Even though this is not one of the easiest practices to implement, building requirements validation into a company's culture is one of the most effective ways to detect errors before they move to the other phases of the software development life cycle amplified. The requirements validation techniques mentioned in this article, and others, such as acceptance criteria definition, are useful tools to help analysts evaluate the correctness and quality of the established requirements. The decisions about how much effort to devote to improving requirements quality before proceeding with design and implementation, and which techniques to use for a particular project, should be risk-based. The factors to take into account include the estimated impact of undetected errors, the degree of involvement of project stakeholders in early validation stages, and how critical the material being inspected is to project success.
Submitting our work to the scrutiny of others is not instinctive human behavior. Like getting up to sing in front of an audience, it can feel threatening, which is why the organizational culture must emphasize requirements validation as a collaborative, nonjudgmental tool for improving the quality of software requirements. In order to enable successful requirement validation, the business analyst has to overcome any resistance she may have against having others point out places where improvement is needed, and feel confident that she won't suffer any public ridicule if defects are discovered in her requirements--even if she sings them.
Sources consulted
Abran, Alain, and James W. Moore, eds. 2001. Guide to the Software Engineering Body of Knowledge, Trial Version. Los Alamitos, CA: IEEE Computer Society Press.
Andrews, B.A.; Goeddel, W.C., Jr. "Using rapid prototypes for early requirements validation". Digital Avionics Systems Conference, 1994. 13th DASC., AIAA/IEEE, 30 Oct.-3 Nov. 1994 Page(s):70 - 75
Grady, Robert B. , and Tom Van Slack. 1994. "Key Lessons in Achieving Widespread Inspection Use." IEEE Software 11(4):46-57.
Lan Cao; Ramesh, B. "Agile Requirements Engineering Practices: An Empirical Study". Software, IEEE Volume 25, Issue 1, Jan.-Feb. 2008 Page(s):60 - 67.
Wiegers, Karl E. 2003a. Software Requirements, Second Edition. Redmond, WA: Microsoft Press.
Author: "Adriana Beal received her B.S. in electronic engineering and an MBA in strategic management of information systems from two of the most prestigious graduate schools in Brazil. For the past 10 years, she has been identifying business needs and determining solutions for business problems for a diverse client base that includes IT, telecom, and major U.S. financial institutions. She works for ThinkBRQ, a NY-based IT consulting firm, and is the principal consultant at 2wtx, a small web agency offering web strategy consulting and online training for Business Analysts. She is a classically-trained pianist who overcame her stage fright a couple of years ago to play Bossa Nova at a Brazilian Festival in Pittsburgh, PA. She doesn't sing."