During the validation phase the requirements are evaluated against a question “Do the requirement specify the right product?”. We check with the stakeholders whether the requirements specify the product/service/change they really want. After the stakeholders approve the requirements and commit that these requirements are what need to be delivered, they are base lined and form a kind of contract for the rest of the project.
Characteristics of a good requirement
Before we send the requirements to the stakeholders asking them for approval and commitment we also validate the requirements against certain quality criteria, quality standards which are applicable within the organization we work for. The most popular characteristics of good requirements are:
- Necessary – A requirement must add some value to a product being made/ service to be delivered. It must specify something that a stakeholder really wants, or something that is required by applied standards.
- Complete – A requirement statement must fully describe the functionality to be delivered. The description must be sufficient for the developer to understand and implement it.
- Correct – Each requirement must accurately describe the required functionality, and must be technically correct. It should not conflict with its source requirement at a higher-level.
- Unambiguous – A requirement must have only one possible interpretation for all the readers, within the context of a product. While (or when) writing down a requirement avoid ambiguous words like e.g. “support”, “adequate”, “handles”, “fault tolerant”, “user friendly”, “as much as possible”, “robust”, “several”, “as fast as possible”.
- Technically available – The implementation of a requirement must be possible given the technical and organizational constraints. Do not specify the impossible.
- Verifiable – A requirement must be ‘quantified’ in such a way that a test can validate whether this requirement has been correctly implemented.
- Implementation free – A requirement states what is required not how a requirement should be met. A requirement statement should not reflect its design or implementation.
Characteristics of a good requirements specification
Besides validation of requirements, the requirements documents can be validated as well. The “rule of thumb” is to check these 4 characteristics, also called 4C:
Requirements Validation techniques
The most popular requirements validation techniques are reviews which could be classified as follows (based on their formality levels):
- formal review/ inspection.
Reading techniques to increase effectivness of a review
Especially during the peer-reviews and inspection, it is additionally possible to improve effectivness of a review by using different reading techniques. Here is quite a complete list of these supportive techniques:
- Perspective-based reading
- Defect-based reading
Ad-hoc reading technique
The ad-hoc reading technique does not give any guidance for reviewers. The reviewers simply attempts to find as many defects as possible by examining the document using the skills and knowledge they have. The ad-hoc technique is very dependent on the individuals performing the inspection.
Checklist-based reading technique
In checklist-based reading, the reviewer is given a checklist with questions that are to be answered during the review. The questions shall draw the attention of the reviewer to some aspects of the inspected document that are often found defective. Checklists give support to the reviewer, so that the result of the review is not dependent on the skills of the individual.
- Checklists add structure to the review process. It is therefore less likely that readers will forget to check some aspects of the requirements document.
- Checklists are great introduction of newcomers. The checklist gives them hints about what they should be looking for, so they feel more able to participate in the review process.
- Only defects of a particular type are detected (defects listed on a checklist). Hard-to-find defects that can be found through a deep understanding of the document are often missed. The checklist-based reading technique can only find errors that have been previously encountered or thought of as the list of inspection questions is written.
- Checklists are typically quite generic, not be suitable for all types of documents.
- This technique misses instructions on how the questions should be answered (i.e. should the reviewer read through the document once and then answer the questions, or examine the document while considering a single question at a time).
- In checklist-based reading techniques, the reviewers are overloaded with excessive information as the checklists tend to be extensive, and the reviewer must go through all of the reviewed documentation.
- Be aware that the checklists must be updated regularly with new knowledge if we want to benefit from them.
Perspective-based reading technique
When using the perspective-based reading technique reviewers use different roles or points of view when reviewing. For example, reviewing as a tester, reviewing as a designer, etc. Each role has scenarios that include questions and activities that tell the reader how to review.
- The research has proven that perspective-based reading is more effective, systematic, focused than other reading techniques.
- It provides consistent guidelines for review work. The reader knows how he should read the document.
- The reader is only responsible for his role and the defects that can be detected with regard to his particular point of view.
- The effectiveness of perspective-based reading significantly depends on selection of appropriate perspectives to be used
Scenario-based reading technique
A scenario-based reading technique offers a set of formal procedures how to review a document. A quite popular version of scenario-based reading is defect-based reading technique.
To use the defect-based reading technique we need to create a model of possible defects in requirements documents. For each defect class from the model (e.g. the class of data type inconsistencies, incorrect functions, and/or missing or ambiguous functions), we develop a set of questions that would characterize the defect class. While reading the document, the reviewer tries to answer the questions and find defects in the document. Each reviewer applies only a single scenario/looks for one fault class only. All reviewers together achieve then sufficient coverage of the document.