Validation Defined<\/strong><\/p>\n Requirements validation is the fourth component\u2014with elicitation, analysis, and specification\u2014of requirements development. Validation assesses whether a product actually satisfies the customer needs (doing the right thing). In contrast, verification determines whether the product of a development activity meets the requirements established for it (doing the thing right). Both activities are vital to successful product development, but we will focus on validation here. Requirements validation attempt to ensure that:<\/p>\n Validation ensures that the requirements exhibit the desirable characteristics of excellent requirement statements (complete, correct, feasible, necessary, prioritized, unambiguous, and verifiable) and of excellent requirements specifications (complete, consistent, modifiable, and traceable). Of course, you can validate only requirements that have been documented, not implicit requirements that exist only in someone\u2019s mind. This is why I endorse actually writing down requirements details instead of relying on imperfect human memories.<\/p>\n Validation isn\u2019t a single discrete phase that you perform after gathering and documenting all the requirements. Some validation activities, such as incremental reviews of the growing SRS, are threaded throughout the iterative elicitation, analysis, and specification processes. Other activities, such as formal SRS inspection, provide a final quality gate prior to baselining the SRS. Include requirements validation activities as discrete tasks in your project plan.<\/p>\n Project participants sometimes are reluctant to invest time in reviewing and testing an SRS. Intuitively, it seems that inserting time into the schedule to improve requirements quality would delay the planned ship date by that same duration. However, this expectation assumes a zero return on your investment in requirements validation. In reality, that investment can actually shorten the delivery schedule by reducing the rework required and by accelerating system integration and testing. Better requirements lead to higher product quality and customer satisfaction, which reduce the product\u2019s lifetime costs for maintenance, enhancement, and customer support. Investing in requirements quality always saves you more money than you spend.<\/p>\n Test Thinking<\/strong><\/p>\n On many projects, testing is a late-stage activity. Requirements-related problems linger in the product until they\u2019re finally revealed through time-consuming system testing or by the customer. If you start your test planning and test-case development early, you\u2019ll detect many errors shortly after they\u2019re introduced. This prevents them from doing further damage and reduces your testing and maintenance costs.<\/p>\n Figure 1 illustrates the V model of software development, which shows test activities beginning in parallel with the corresponding development activities. This model indicates that acceptance testing is based on the user requirements, system testing is based on the functional requirements, and integration testing is based on the system\u2019s architecture.<\/p>\n Figure 1. The V model of software development incorporates early test planning.<\/p><\/div>\n Plan your testing activities and begin developing preliminary test cases during the corresponding development phase. You can\u2019t actually run any tests during requirements development because you don\u2019t have any software to execute yet. However, conceptual (that is, implementation-independent) test cases based on the requirements will reveal errors, ambiguities, and omissions in your software requirements specification (SRS) and analysis models long before the team writes any code.<\/span><\/p>\n Reviewing Requirements<\/strong><\/p>\n I\u2019m a big fan of performing both formal and informal requirements reviews of growing requirements documents. A requirement might make perfectly good sense to the person who wrote it, but if others don\u2019t understand it, there\u2019s a problem. User representatives are particularly well-suited to validating the correctness of each requirement. Developers and testers can examine requirements to assess whether they understand each one well enough to do their part of the project work based on that requirement. The structured and disciplined technique of inspection provides a way for various reviewers to compare their interpretations and make sure they understand each requirement in the same way. This is something that simply passing requirements out to multiple reviewers and asking what they think does not accomplish.<\/p>\n I\u2019m so enthusiastic about reviews of requirements and other software project deliverables that I wrote a book about it,\u00a0Peer Reviews in Software: A Practical Guide<\/em>\u00a0(Addison-Wesley, 2002). I\u2019ve provided some recommendations about how to get the most out of your requirements reviews in two earlier blog posts titled \u201cTwo Eyes Aren\u2019t Enough,\u201d parts one and two.<\/p>\n Evaluating Prototypes<\/strong><\/p>\n Most people have difficulty envisioning how a new system will look and behave from reading a textual requirements specification. Prototypes are a way to bring requirements to life, to put something more tangible in front of the user and solicit feedback. A prototype represents a partial, preliminary, or possible way you might address a particular set of requirements. Prototypes can be static or dynamic, electronic or paper, evolutionary or throwaway. When you create a prototype, you\u2019re taking a tentative step into the solution space. While not committing you to building the software in a particular way, a prototype is an excellent tool for requirements validation. Users can interact with prototypes, thereby simulating their interactions with the ultimate system, to see if a system based on those requirements would really meet their needs.<\/p>\n In recent years, vendors have developed numerous tools to help automate and streamline this process. You can now buy tools that actually simulate proposed systems, help you quickly build prototypes or wireframe representations of the system, and model the behavior of the system based on a set of use cases or functional requirements. All of these tools are intended to facilitate a user\u2019s understanding of requirements to help validate that those are in fact the correct requirements for the system.<\/p>\n Defining Acceptance Criteria<\/strong><\/p>\n Software developers might believe that they\u2019ve built the perfect product, but the customer is the final arbiter. Customers perform acceptance testing to determine whether a system satisfies its acceptance criteria. If it does, the customer can pay for a product developed under contract or the user can cut over to begin using a new corporate information system. Acceptance criteria\u2014and hence acceptance testing\u2014should evaluate whether the product satisfies its documented requirements and whether it is fit for use in the intended operating environment. Having users devise acceptance tests is an effective requirements development strategy. The earlier in the development process that users write acceptance tests, the sooner they can begin to filter out defects. In fact, some agile software development methodologies employ user acceptance tests in lieu of writing detailed functional requirements.<\/p>\n Acceptance testing should focus on anticipated usage scenarios. Key users should consider the most commonly used and most important use cases when deciding how to evaluate the software\u2019s acceptability. Acceptance tests focus on the normal courses of the use cases, not on the less common alternative courses or whether the system handles every exception condition properly. Automate acceptance tests whenever possible. This makes it easier to repeat the tests when changes are made and additional functionality is added in future releases. Acceptance tests also ought to address nonfunctional requirements. They should ensure that performance goals are achieved on all platforms, that the system complies with usability standards, and that all committed user requirements are implemented.<\/p>\n Having customers develop acceptance criteria thus provides another opportunity to validate the most important requirements. It\u2019s a shift in perspective from the requirements-elicitation question of \u201cWhat do you need to do with the system?\u201d to \u201cHow would you judge whether the system satisfies your needs?\u201d If the customer can\u2019t express how she would evaluate the system\u2019s satisfaction of a particular requirement, that requirement is not stated sufficiently clearly. However, keep in mind that user acceptance testing does not replace comprehensive requirements-based system testing, which covers both normal and exception paths and a wide variety of data combinations that users might not think of.<\/p>\n Simply writing requirements isn\u2019t enough. You also need to make sure that they\u2019re the right requirements and that they\u2019re good enough to serve as a foundation for design, construction, testing, and project management. Acceptance test planning, peer reviews, prototype evaluation, and requirements testing techniques will help you to build higher-quality systems faster and more inexpensively than you ever have before.<\/p>\n Jama Software has partnered with Karl Wiegers to share licensed content from his books and articles on our web site via a series of blog posts, whitepapers and webinars.\u00a0 Karl Wiegers is an independent consultant and not an employee of Jama. \u00a0He can be reached at\u00a0<\/i>http:\/\/www.processimpact.com<\/a><\/i>.\u00a0 Enjoy these free\u00a0<\/i>requirements management resources<\/a><\/i>.<\/i><\/i><\/p>\n \u00a0<\/i><\/p>\n","protected":false},"excerpt":{"rendered":" If you\u2019re going to go to all the trouble to build software system, you\u2019d like to be confident that you\u2019re working from the right requirements. You\u2019d like to know that the product you build has a high chance of satisfying customer needs and will let them get their jobs done in a way they find […]<\/p>\n","protected":false},"author":68,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[50],"tags":[49,51,38,98],"industry":[],"class_list":["post-3410","post","type-post","status-publish","format-standard","hentry","category-requirements-management","tag-best-practices","tag-business-requirements","tag-karl-wiegers","tag-validating"],"acf":[],"yoast_head":"\n\n
![\"\"](\"https:\/\/static.jamasoftware.com\/www\/imports\/2013\/06\/a32f1.jpg\")