Review¶
Preparation¶
Reviews are systematic techniques that can be applied to documents. Any written material can be the subject of a review, such as a requirements specification, system design, user manual, developer documentation, etc.
The activities related to reviews are guided by the ISO/IEC 20246 standard. The methods described there should be applied according to the specific task and the organization’s regulations and expectations.
The following figure provides an overview of typical activities:
A review meeting is convened to summarize the results of the review. This meeting is optional for walkthroughs and technical reviews, but mandatory for inspections. If a review meeting is held, preparation for it is required in the case of technical reviews and inspections, while in other cases it is optional.
Roles that can be defined during the review:
- Author: Creates and corrects the work product under review. At the walkthrough level, the author leads the review meeting; however, at higher levels, it is recommended to appoint a moderator, and in the case of inspections, this is mandatory.
- Moderator: Ensures the effective management of review meetings, including mediation, time management, and providing a safe review environment where everyone can speak freely. At the inspection level, a trained moderator is mandatory and must not be the same person as the author.
- Review leader: Has general responsibility for the review, makes decisions, assigns participants, and organizes when and where the review will take place.
- Reviewers: Carry out the review activities. A reviewer can be someone working on the project, a subject-matter expert, or any other stakeholder.
- Recorder (scribe): Collects anomalies from reviewers and records review information such as decisions and newly found anomalies during the review meeting. A recorder is required starting from the walkthrough level for methods requiring higher formality.
- Manager: Determines what should be reviewed and provides resources, such as personnel and time, for conducting the review.
Note: The ISO/IEC 20246 standard defines additional roles as well.
The type of review depends on the project goals, the regulatory environment affecting the system, and the current stage of development.
Possible types of reviews are shown in the figure below:
Several techniques can be used during a review.
Possible techniques:
- Ad hoc: In an ad hoc review, reviewers receive little or no guidance on how to perform the task.
- Checklist: The checklist-based review is a systematic technique where reviewers identify problems using checklists distributed at the start of the review (for example, by the moderator).
- Scenarios and dry tests: In a scenario-based review, reviewers are given structured guidance on how to read through the work product. This method supports reviewers in performing dry tests (theoretical executions) of the document based on its intended use (provided the work product is documented appropriately, e.g., as use cases).
- Role-based: In a role-based review, reviewers evaluate the work product from the perspective of various stakeholder roles. Typical roles include specific end-user types (experienced, inexperienced, elderly, child, etc.) and organization-specific roles (user, administrator, system administrator, performance tester, etc.).
- Perspective-based: In a perspective-based review—similar to a role-based one—reviewers consider the viewpoints of various stakeholders during individual reviews. Typical perspectives include end-user, marketing, designer, tester, or operator viewpoints. Using different stakeholder perspectives provides deeper understanding during individual reviews and reduces duplication of findings among reviewers.
Perspective-based and role-based testing
Perspective-based testing is an approach that focuses on the viewpoints or perspectives of different stakeholders involved in the software development process. Its goal is to ensure that the software or documentation meets the needs and expectations of these stakeholders. The key perspectives typically considered in this approach are:
- User perspective: Focuses on how end users will interact with the software and whether it meets their usability and functionality requirements.
- Business perspective: Evaluates whether the software aligns with business goals and objectives, including cost efficiency and return on investment.
- Regulatory perspective: Examines whether the software complies with applicable regulations, standards, and industry requirements.
- Performance perspective: Evaluates and assesses the software’s performance, scalability, and reliability.
- Security perspective: Assesses the software’s security features and vulnerabilities to ensure protection against threats and risks.
The purpose of perspective-based testing is to ensure that the software provides value from the viewpoint of various stakeholders.
Role-based testing focuses on the roles and responsibilities of the different individuals involved in the software development process. Its goal is to verify that the software or associated documentation meets the expectations and requirements of these roles. Common roles considered in this approach include:
- Developer: Ensures that the software is tested from the developer’s perspective, including unit testing and code quality assessments.
- Tester: Focuses on evaluating the software’s functionality, performance, and other quality characteristics to identify defects and ensure compliance with specified requirements.
- Business analyst: Evaluates whether the software meets business and user requirements, including both functional and non-functional aspects.
- Project manager: Focuses on the project’s schedule, budget, and resource constraints to ensure that software development proceeds within these boundaries.
The goal of role-based testing is to verify that the expectations and responsibilities of each role are met throughout the software development process.
In summary, perspective-based testing considers the viewpoints of various stakeholders, while role-based testing focuses on the expectations and responsibilities of individuals participating in software development. These approaches complement each other and are often used together to ensure comprehensive testing and validation of software products.
During the review of documents, we typically encounter documentation written in natural language. The use of natural languages inherently poses risks regarding clarity and accuracy. In addition, reviewers must consider that certain terms may have different meanings in different business contexts. If available, it is advisable to use the organization’s corporate glossary to clarify possible conceptual discrepancies.
Issues related to using natural-language documentation are presented in the following document.
A significant portion of documents under review are requirements specifications. The quality expectations for such specification documents are presented in the following document.
Exercises¶
User Manual Review
Perform a review of the following User Manual. Use a checklist during the review!
Requirements Specification Review
Choose one of the following requirements specifications:
Select a review criterion and conduct the review based on the chosen criterion.