Requirements Review in Software Quality Assurance

In Chapter 1, we briefly presented an example of software quality for aircraft engine manufacturer Rolls-Royce. Below is a concrete example of the application of code inspections at Rolls-Royce. Conclusion: The requirements verification analysis may decide or discontinue the ongoing software development. The fact that checking requirements requires a lot of back and forth. This can be a troubling job, but not if done right. Table 5.5 is an example of a support matrix for selecting a verification type. The Document Review column displays a list of products to review. The Complexity column specifies the classification criteria and the type of validation to use. In this example, the level of complexity is measured as low, medium, and high. Complexity is defined as the difficulty of understanding and verifying a document. A low level of complexity indicates that a document can be reviewed easily or easily, while the high level of complexity is set for a product that is difficult to verify.

Table 5.5 is just one example. The selection criteria for the type of review and product to be reviewed should be documented in the project plan or CEAP. Figure 5.5 Error Detection During the Software Development Lifecycle [RAD 02]. A checklist serves as a reminder. A checklist contains a list of criteria for checking the quality of a product. It also ensures consistency and completeness in the development of a task. A sample checklist is a list that makes it easier to classify a bug in a software product (for example. B, an oversight, an objection, an omission). Basili et al. (1996) [BAS 96] published the first controlled experiments that captured experiments. This approach, called Experience Factory, which brings together experience from software development projects, is packaged and stored in an experience database. Packaging refers to the generalization, adaptation and formalization of the experience until it can be easily reused.

In this approach, the experience is distinct from the organization responsible for capturing the experience. In my team, we work according to the agile methodology and at the end of each sprint we have a review session where each member determines what they think is good or not so good during the sprint. We identify the list of things that need to be improved and that each member really wants to consider. After that, the items with the most votes are inserted into the backlog according to their priority. “The purpose of a walkthrough is to evaluate a software product. An inspection can also be performed to create discussions for a software product” [IEE 08b]. The main objectives of the walkthrough procedure are [IEE 08b]: In this chapter we present two types of controls as defined in the IEEE 1028 standard [IEE 08b]: inspection and inspection. Professor Laporte contributed to the recent revision of this standard. We will also describe two assessments that are not defined in the standard: personal review and documentary audit.

These exams are the least formal of all types of assessments. They are included here because they are easy and inexpensive to use. They can also help organizations that do not conduct formal reviews understand the importance and usefulness of exams in general and implement more formal reviews. We know that SQA activities must be recorded during a software project. These records serve as evidence that the project has completed the activities and can provide these records upon request. Exam results and completed exam checklists can be a good source of evidence. Therefore, it is recommended that project teams record meeting minutes for all technical and management reviews they conduct. LG 2 (RELEVANT). All information must be relevant to the software product. An organization that has just started implementing formal reviews, such as inspections. B, could review documents at a higher rate than the inspection rates proposed by IEEE 1028.

When more reliable metrics are collected, such as.B. error detection rate and troubleshooting efficiency, the organization may decide to reduce the review rate to achieve higher detection rates and thus reduce the error escape rate. Section 5.8 contains measurements and an example of how to calculate the error detection rate. During the course of the audit, SQA members should use the Rolls-Royce SQA Exam Checklist developed the following table to describe the effectiveness of authors and reviewers. The left side shows data on the error injection rate for developers A through F. For example, Developer A typically inserts 0.5 errors per 1000 lines of code and developer F 18 errors. The right side of the table shows the effectiveness of detecting evaluators A to F. Note that evaluator A has a recognition rate of 75% and evaluator F has a rate of 30%. “If you`ve just started performing inspections, you should notice about 50% of the defects in your software product (this number ranges from at least 20% to 90-95%).