One aspect of reviewing a requirements document is the process of reviewing. Karl Wiegers (“More about software requirements”, Chapter 8, page 69-73 ) or Suzanne Robertson (“An early start to testing: How to test requirements” www.itmweb.com/essay505.htm ) wrote a paper on the process of reviewing a requirments document.
One aspect though may justify some additional attention: What words or concepts do we expect in the requirements document, that we need to review?
Sometimes it is worthwhile to search for a marketing brochure on the system that is to be developed, and to read about its features, its performance or its functions.
In other words: we make an attempt to look at this system as a system engineer or a potential buyer of the system and wonder what makes this system worth building? Is it – for instance - more accurate than what was built before? Will it have more features? Is it simpler to manipulate?
While contemplating on this, we will make a few notes on characteristics (like reliability, diagnostics, response time), and we make some notes how these characteristics could be measured (physical units, like hour, seconds, kilobyte, etc). This is no more than our first best guess, but usually worthwhile.
A similar approach can be done by browsing through the requirements document, making some notes, making some diagrams, etc. It is an attempt to come up with topics that should be addressed in the requirements document, and the question during the review is: are these topics indeed addressed in the requirements document?
One might argue that the author has gone through this process already, so we can assume it is covered. But – alas – the author finds it hard to maintain this helicopter-view, and gets entangled in details, and misses crucial aspects (sometimes). As a reviewer we contribute in the development process by providing a fresh look at the document, so that the development process might run smooth: without “oh, sorry, we forgot”, or “when we discover an error in a test-phase: sorry, Chapter 4 and 8 of the document were written by different authors, and therefore the reliability figures are different”.
Sometimes a word count of the words in the requirements document may also provide inspiration for key words that need the reviewer’s attention. This gives certainly an idea what not to review: words that occur so frequently that it will be prohibitive to spend time on these words.
Sometimes an organization has a history of making errors/omissions/ in certain aspects of the system. By analyzing cost- or schedule-overruns we may have found for instance: that, the lack of proper requirements for “altitude control” caused a lot of trouble. So, this is an excellent reason to analyze this aspect very carefully. By consequence: algorithms, accuracy, etc will be topics worth reviewing. And, we will therefore look for units like degrees, radians, etc.
We may even obtain some suggestions from the author(s) of the requirements document. Would you be so kind to look for A, B, C, since we had a very inexperienced person writing these Chapters? In the light of producing a good product, as soon as we can, this is beneficial for the team.
Topics that are usually forgotten by development organizations, like diagnostics, error reporting and maintenance are also worth adding to our lists of review interests.
Yet, another way to find topics for Requirements Analysis is to look in the Table of Contents of the document under review. While glancing through the Table we will find areas of interest. The Contents may even raise some questions for further investigation. Jot them down. This is the time to be curious: Is topic A also present in the document? Is its performance stated?
The Review of the requirements is a wonderful opportunity to revisit the problem we are trying to solve. If we are catching defects in this early phase we are greatly assisting the success of our project. This Prologue is an invitation to think “in the box” and “out of the box”, within the scope of the project.
What is needed is a thorough discussion between authors, reviewers and users of requirements documents. What are important aspects to consider? Not all errors are equally important. Not all issues or defects are equally important either. How will tools assist these user communities?
So a suggestion is: chew on the review and its keywords. Writing requirements is not easy, and reviewing requirements takes time.
Our goal is: Detect important defects early.