Here are some additional recommendations about how to make peer reviews of your requirements documents as effective as possible.<\/p>\n
Don\u2019t Overwhelm the Reviewers<\/strong><\/p>\n Many BAs wait until their requirements specification is complete before they present it to some reviewers. Busy developers, testers, project managers, and users have difficulty finding the time to scrutinize a large document on short notice. It\u2019s far more effective to review an evolving document incrementally. Give reviewers just a few pages at a time, preferably soon after an elicitation activity. Nearly anyone should be able to find thirty minutes to review a small quantity of information once in a while.<\/p>\n Incremental, informal reviews will uncover a lot of problems. Expect to make multiple review passes through the requirements over time. Each review cycle will reveal errors that the reviewers didn\u2019t spot the first time. As the requirements continue to change and grow, people might need to revisit portions of the requirements documentation that they examined in an earlier draft.<\/p>\n You don\u2019t need to hold a meeting for each peer review. Sometimes it works fine just to ask one or a few reviewers to look something over and tell you what they see. Combine these sorts of informal individual reviews, which I call peer deskchecks, with formal inspections of documents that are nearly done.<\/p>\n Build a Collaborative Partnership with Project Stakeholders<\/strong><\/p>\n Explain to users why their input is so critical to ensuring the quality of the requirements and how it contributes to the quality of the ultimate software product. Make them understand that their review effort is a vital contribution, not an idle exercise. Begin forging this collaboration early in the project so these participants realize they\u2019re valued members of the team.<\/p>\n On many projects, my software development teams at Kodak identified product champions,<\/em> key customer representatives who worked closely with the business analysts. We negotiated the exact responsibilities with each product champion. But one responsibility was not<\/em> optional: to review requirements specifications and evaluate prototypes. Without user review, we couldn\u2019t tell whether we\u2019d accurately captured the voice of the customer. We were pleased that all of our product champions accepted this responsibility. They provided great value through their reviews.<\/p>\n Invite the Right Reviewers<\/strong><\/p>\n Determine early in the project what perspectives you need represented in your requirements reviews and who can provide these perspectives. Figure 1 illustrates the essential points of view a requirements review should take into account. Particularly consider getting the participation of the following:<\/p>\n \u2022 Customers who provided requirements input.<\/p>\n \u2022 Developers who will have to design and implement the requirements.<\/p>\n \u2022 Testers who will have to verify that the requirements were properly implemented.<\/p>\n Work products must be reviewed in a context, not in isolation. The reviewers must ascertain whether the work product meets its own specification. The top-level requirements documentation has no specification or reference document, so you need customers or others who provided requirements input to review the deliverable. Also, you might invite another BA to participate who\u2019s adroit at spotting poorly written or missing requirements. The downstream \u201cvictims\u201d of the requirements specification can check to see whether it will satisfy their needs. And if your product connects in some way to any other products, have representatives of those other components make sure the pieces will fit together properly.<\/p>\n Rather than having all these different reviewers just read through the document, consider using perspective-based reading,<\/em> in which each reviewer examines the deliverable from the point of view of a specific document consumer. For example, a user seeks to determine whether the documented requirements would in fact let him achieve his business objectives. A developer checks to see whether the document contains the information he needs to design and implement a solution. A tester considers whether the requirements are precise and detailed enough to be verifiable. These different points of view will reveal different types of problems.<\/p>\n Have Reviewers Examine Appropriate Deliverables<\/strong><\/p>\n It might not be reasonable to expect all your user representatives to effectively review a detailed software requirements specification. They should certainly understand use cases, though, as use cases ought to be written from the user\u2019s point of view. Make sure your reviewers can comprehend the requirements documents and diagrams well enough to validate them. If the requirements documents are too technical for the reviewers to follow, you\u2019re wasting their time.<\/p>\n Design for Reviewability<\/strong><\/p>\n Present the information in a specification in forms that make it easy for reviewers to understand it and to examine it for problems. There are many ways to communicate besides natural language text. If your eyes glaze over when reading a long list of textual requirements, maybe a diagram or a table would be an effective alternative. Remember that a requirements specification is a communication tool. If your requirements deliverables don\u2019t speak to their intended audiences, the deliverables need further work.<\/p>\n Inspect All Requirements Deliverables<\/strong><\/p>\n Informal reviews certainly are helpful, but more systematic inspections will find more defects. Inspections and other group reviews also are a way to force the issue of getting reviewers to actually look at the work product. Inspections are a powerful technique for spotting ambiguous requirements. During an inspection, one inspector (not the author) serves as the reader. The reader presents his interpretation of each requirement to the other inspectors. If his interpretation doesn\u2019t match their own understanding, perhaps the team has detected an ambiguity, a statement that can be interpreted in more than one way. Individual informal reviews often overlook ambiguities because an ambiguous requirement can make sense to each reader, even if it means something different to each of them.<\/p>\n Emphasize Finding Major Errors<\/strong><\/p>\n The greatest leverage from a review comes from finding major errors of commission and omission. These are the defects that can help you avoid extensive\u2014and expensive\u2014rework much later in the project. Ambiguous and erroneous requirements send developers and testers in the wrong direction. Missing requirements are among the hardest errors to detect. They\u2019re invisible, so inspectors don\u2019t see them during their individual preparation. Because they don\u2019t exist, the inspection reader won\u2019t describe them.<\/p>\n Fixing typographical and grammatical errors is useful because any changes that enhance effective communication are valuable. However, this should be done before sending out the document out for broad review, perhaps by having a single skilled editor go through it initially. Otherwise, reviewers can trip on these superficial errors and fail to spot the big defects that lie underneath. When I see an issues log from a review that contains mostly cosmetic and spelling mistakes, I worry that perhaps the reviewers overlooked major problems.<\/p>\n No business analyst can get the requirements right on his own. Get a little help from your friends to make sure that what you\u2019ve written will satisfy customer needs and will let the rest of the development team do a first-class job.<\/p>\n Check out Peer Reviews: Two Eyes Aren’t Enough, Part 1<\/a>.<\/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\u00a0http:\/\/www.processimpact.com<\/a>.\u00a0 Enjoy these free\u00a0requirements management resources<\/a>.<\/em><\/p>\n <\/p>\n","protected":false},"excerpt":{"rendered":" Here are some additional recommendations about how to make peer reviews of your requirements documents as effective as possible. Don\u2019t Overwhelm the Reviewers Many BAs wait until their requirements specification is complete before they present it to some reviewers. Busy developers, testers, project managers, and users have difficulty finding the time to scrutinize a large […]<\/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":[842],"tags":[53,54,55,21,51,56,57,58,59,38],"industry":[],"class_list":["post-3159","post","type-post","status-publish","format-standard","hentry","category-reviews","tag-ba","tag-babok","tag-business-analysis","tag-business-analyst","tag-business-requirements","tag-cbap","tag-ccba","tag-cmmi","tag-iiba","tag-karl-wiegers"],"acf":[],"yoast_head":"\n