Once the goal has been defined, the budget has been set, and the timeline has been planned, it is often not fast enough to define the requirements and start implementation. To avoid mistakes, a review of the requirements can ensure their quality.
But how does this actually work? And isn’t a detailed review of the requirements inefficient if they change frequently in the project anyway? An important pillar of requirements management is the review and coordination of requirements. Implementing an efficient review process can help to ensure that your project does not falter.
Faulty Requirements – Why is This not a Rarity?
“The car should be fast and safe.” At first glance, this requirement makes sense in terms of the end product. However, this requirement will only leave the supplying company with many unanswered questions. How fast should it be and what is actually considered safe? Of necessity, it will have to get back in touch with the client and the project will stall.
The requirements manager (also called requirements engineer) wonders: How could such an unclear requirement make it into an official requirements specification? The answer is quite simple. The company saved costs at the wrong end and did not conduct a review process of the requirements or did so inappropriately. As a result, an ambiguous, as well as the untestable requirement has been sent to the supplier. The exemplary company is not an isolated case.
The cause of project failure or the completion of a project with functional limitations and/or resource overruns can be inadequate requirements management, in which the quality of the requirements in the project was not sufficiently tested. The CHAOS report is a study published by the Standish Group that examines the success and failure factors in IT projects. It divides projects into three types: Successful, Failed, and Completed with Resource Overruns or Functional Limitations. Resource overruns can occur both financially and in terms of time.
When comparing 1994 and 2015, the number of successful projects has increased by approximately 45% and the number of failed projects has decreased by 39%. Overall, there is a trend that the number of failed projects has decreased over the years. One cause that has contributed to the decrease is the higher quality of requirements. However, the decisive factors for project failure are still:
- Lack of input from users,
- Incomplete/unclear requirements,
- Frequent requirement changes.
Two of these three factors can be avoided by an effectively conducted review in requirements management. What exactly does review mean? The German translation of the term review is retrospective or reviewing. A review is therefore an examination carried out in retrospect. Doesn’t an additional process of reviewing all requirements automatically lead to an increase in costs? In order to assess this, the effects of incorrect requirements should be considered in more detail.
The Cost-Effectiveness of a Review Process
One reason for the necessity of reviews for testing and reconciling requirements is the exponential cost development that the occurrence of a defect and its rectification can cause at an advanced stage of the project. The cost development can be described by the cost curve, which is based on a model of the American software engineer Barry W. Boehm.
It says that in the development process later occurring requirements and/or changes of the requirements cause clearly higher costs. As with the rule of ten of the error costs (English also “rule of ten”), the costs rise per development step by the factor 10.
Cost curve according to Boehm
The diagram clearly shows that as the development process of a product/service progresses, the level of costs for a possible error correction also increases. If a requirement has to be changed again in the implementation phase, this can result in costs 100 times higher than if the adjustment had been made in the analysis phase.
This is because the later in the process a change occurs, the higher the probability that it will have an impact on further requirements. The later a requirement is identified as unrealistic, incorrect, or of low quality, the more expensive it becomes. Conversely, this means that a review carried out as early as possible minimizes the risk and such a requirement can be discovered early and corrected with little effort.
It is therefore important to establish a suitable control process in requirements management and to check the requirements at an early stage for their feasibility, testability, etc. A possible release process must be provided for in the course of planning. An example process is shown in the figure below.
The requirement is written and is therefore in draft status. The requirement structure is then checked by the requirement manager in the status review. If corrections need to be made, the requirement is rejected and returned to draft status.
In Assessment, the requirement is subjected to a technical assessment; if corrections are necessary, it is also rejected and the process starts again in Draft status. When all control processes have been successfully completed, the requirement is accepted. A possible further step is an Approved status after the approval of a superior, from which the release of the requirement follows.
Not Seeing the Forest for the Trees – Avoiding the Confirmation Bias
You have implemented a review process to check and reconcile your requirements. Nevertheless, faulty requirements occur even in advanced development. How can this happen? An important aspect of ensuring requirements quality through review processes is the avoidance of so-called confirmation errors. Reviewing requirements multiple times minimizes errors. However, it is common knowledge that people can succumb to a certain degree of self-deception. Information that is contrary to one’s own opinion is ignored or interpreted in such a way that it fits the corresponding view. This is an element from human psychology called confirmation bias. The confirmation bias is also addressed in the syllabus of the “Certified Tester Foundation Level” (CTFL) certification of the “International Software Testing Qualifications Board” (ISTQB) in relation to requirements reviews:
“An element of human psychology called confirmation bias can be a hindrance to accepting information that contradicts current beliefs. For example, developers expect their code to be correct, and confirmation bias makes it difficult for them to accept that the code is not correct.” (ISTQB, CTFL Syllabus, 2018)
The view of one’s own requirements can therefore be somewhat clouded. Therefore, it should be avoided that a requirement written by one person can also be successfully checked by the same person. It is essential to have all requirements checked by at least a second specialist. An effective way is to have another expert check the requirement for the correctness of the content. This method is also known as peer review, which is often used in scientific publications to confirm the quality of the publication. The word “peer” means “like-minded”. In the company, the requirement should therefore be reviewed by colleagues who work in the same field in order to be able to correctly evaluate the effects, dependencies, and implementation of the requirements from a technical perspective as well. In addition to checking the content, the requirements should also be checked for formal correctness by requirements engineers.
Having the requirements checked using targeted methods and by a larger group of people significantly reduces the risk of them being changed afterward. An informal review is a simple way of doing this. This is what is colloquially known as the “four-eyes principle”. The author of a requirement passes the requirement on as a work product to a person/group for validation. The review in the informal review does not follow a defined process. However, the draft is analyzed and commented on within a defined period of time. The author receives the comments back to adapt the requirement. The next step is to decide whether and how to incorporate them.
Other applicable methods are inspections and walkthroughs, which are formal reviews. They are defined by a prescribed process and are often used for milestones or final versions. A special feature of inspections is the assigned roles. An independent moderator leads the review. The inspectors, consisting of peers and experts, review and evaluate the work product against requirements and goals. The author tries to understand the criticism and its impact and explains functions only when necessary.
In a walkthrough, the author interactively explains his/her work product to a selected group of reviewers. The participants can ask questions and exchange ideas. The author can further explain the work product or directly discuss solutions. This form of review is usually used in early project phases and is not only used in classic requirements management. In agile development in connection with Scrum, the so-called sprint review is usually conducted at the end of sprints.
The Sprint Review is a meeting at the end of a Sprint in which the Scrum Team and all stakeholders come together to reflect on what was achieved during the Sprint and whether the objectives of the Sprint were achieved. Stakeholders may include the Product Manager, the Scrum Master, the development team, and all other people involved in the development process.
The Sprint Review should not be confused with the Retrospective, although both meetings are a form of review. The difference between Review and Retrospective is in the details.
The Sprint Retro Meeting takes place after the Sprint Review. While the review discusses what was developed, the sprint retrospective focuses on how something was implemented. The process is reflected upon. Questions are answered such as what is going well, what could be improved and how could the overall productivity be increased.
So What Does This Mean for Your Requirements Management?
The reasons have been explained why checking the content and form of requirements through a review process in your development workflow is a sure way to bring the quality of your requirements to a high level. When implementing the process, a good balance should always be struck between effectiveness and cost. Which methods and how the validation is done depends mainly on the complexity of your project.
For smaller projects, for example, the Informal Review form is worthwhile. In the case of more complex projects, which have a larger number of requirements or also have to comply with special safety specifications or quality requirements, the review should be defined in greater depth. In this case, the support of suitable tools is also useful.
We have bundled our many years of experience in a wide range of industries and the continuous expansion of our knowledge of effective methods and tools in our Center of Competence (CoC) Requirements Management. Benefit from our expertise in requirements management. Contact us and together we will find the optimal solution for you.
LICENSES:
- Headerbild: “Business teamwork works with a tablet with internet streaming service” / ©alphaspirit/ stock.adobe.com