Three Perspectives on Requirements Quality: Authors, Reviewers, QA-Engineers
Several roles are concerned with requirements quality. Of course, there is the requirements author, writing the requirements. But there is also the reviewer, who proof-reads and validates the requirements. And finally, there is the QA-Engineer, responsible for the overall quality of all artifacts created during the engineering process. Each of these roles needs a different view on requirements and different tools in order to do their work efficiently and achieve a high requirements quality. In this article I am going to show you how the Qualicen products specifically support authors, reviewers and QA-engineers in their work to keep requirements quality high.
The Requirements Author
The task of requirements author is to engineer and document the requirements in a requirements specification. Depending on the context, she is using different tools for this purpose. In some cases this is Microsoft Word, in other cases she uses specialized tools such as IBM Doors or PTC Integrity. She does not only write the requirements once, but also changes the requirements after discussions with colleagues, merges or splits single requirements or changes the structure of the specification. Typically, a requirements author has a company specific guideline stating naming conventions or standard keywords (e.g. “must” vs. “should”).
The Qualicen tools support the workflow of the author with automatic quality checks. These checks work like an extended spelling checker. As soon as the requirements author changes a requirement she immediately gets feedback on the quality of her change. Our plugin directly integrates the feedback into her authoring environment. So she needn’t change tool or switch to a special report. Hence, without a context switch, she can assess the reported quality issues an decide whether she wants to change her specification or not.
Let’s look at our PTC Integrity Plugin as an example. The screenshot below shows it in action. The plugin adds two extra fields to a requirement: QRC Findings and QRC Findings Text. We can display the field contents by displaying the appropriate columns in a requirements document. As soon as the requirements author changes and saves a requirement, the plugin analyizs the requirements text for quality issues and the author gets immediate feedback. The first column displays the list of found issues. Additionally, the second column displays the requirements text with the problematic locations highlighted. Quickly, the requirements author can review the issues, change the requirements text, save the requirement again and go on with her work.
The Requirements Reviewer
The task of the requirements reviewer starts when the requirements author finished a first complete version of the specification. The reviewer typically reads the whole specification in detail. He investigates, for example, if the requirements are complete and correct and if they are testable. He also assesses whether the requirements are precise and unambiguous and whether the company guidelines have been correctly applied. Ideally, the reviewer can focus on the hard tasks, evaluating completeness and correctness. However, in practice reviews often include remarks on language and violations of a guideline. For the reviewer it is helpful to get an overview over all quality issues in a whole document.
The Qualicen tools support the reviewer with automatic checks on ambiguous language and guideline violations. The reviewer can quickly go through the list of findings and adopt the critical ones into his review. He can either use the plugins also used by the author. In this case he filter on certain findings types or use the search built into authoring tools such as PTC Integrity. The reviewer can also use Qualicen Scout. Using the document perspective, he can get go through a specific document with the findings highlighted. Alternatively he can use the Findings Perspective to review the individual findings.
In the screenshots below, there is the Findings Perspective and the Document Perspective of Qualicen Scout. The main window shows a list of currently selected findings. The reviewer can use the filters on the right to select findings according to various criteria, such as finding type or details of the findings message. By selecting a finding in the list, he can look at the findings details.
The next screenshot shows the document perspective of Qualicen Scout. The findings are hightlighted directly in the document text. On the right side there are filters to select findings according to varous criteria.
The QA-Engineer
The final role is the role of a quality engineer. The quality engineer is responsible for the overall quality of the product and hence also for the overall quality of the development artifacts. Her task is to set quality goals and to define the quality assessment processes and techniques. She permanently evaluates the quality of the various development artifacts. Hence, she has to keep an overview over a large set of documents. Therefore, she cannot go into the details of each document but rather needs to quickly grasp the current state, the trend and potential problems quickly. She is interested in how the quality evolves over time to figure out her teams are getting bettter. She also wants to know quality hot spots in the specification. Such hot spots may hint on deeper problems, for example a new team member who does not know about the company guideline.
Qualicen Scout supports the quality engineer by providing metrics and a freely configurable dashboard that shows aggregated information for the projects she is responsible for. The information in the dashboard is updated as soon as the requirements are updated. This way, she always knows about the current state of the quality of the requirements documents and can identify problem hotspots.
As an example, below is a screenshot of a Qualicen Scout dashboard. The dashboard shows a couple of metrics, such as the size of the specification or the number of findings. It further shows how the size of the specification and the number of findings evolved in the past. Finally it shows an overview over the most common findings types and how the findings are distributed over the parts of the specification (in the treemap in the lower left corner).
Summary
There are three roles that play are role in requirements quality: The requirements author, the requirements reviewer and the QA-Engineer. Each of them has different tasks and work differently with the requirements. In order to support them in keeping requirements quality high, the need special tooling. The Qualicen tools support each of the three roles: The author, by providing instand feedback right in the authoring tool, the reviewer by showing findings of the whole specification and by providing filtering mechanisms. And finally the QA-Engineering with freely configurable dashboards, giving the the birds-eye perspective on the requirements quality.
