J.E.D.I
3.6 Requirements Metrics
Measuring requirements usually focuses on three areas: process, product and resources. The requirements work products can be evaluated by looking first at the number of
requirements. As the number grows, it gives an indication how large the software project is. Requirement size can be a good input for estimating software development effort.
Also, as the software development progresses, the requirement size can be tracked down. As design and development occur, we would have a deeper understanding of the
problem and solution which could lead to uncovering requirements that were not apparent during the requirements engineering process.
Similarly, one can measure the number of times that the requirements have changed. A large number of changes indicates some instability and uncertainty in our understanding
of what the system should do or how it should behave. In such a case, a thorough understanding of the requirements should be done; possibly, iterate back to the
requirements engineering phase.
Requirements can be used by the designers and testers. It can be used to determine if the requirements are ready to be turned over to them. The Requirements Profile Test
is a technique employed to determine the readiness to turn over requirements to the designers or testers
3
. For the designers, they are asked to rate each requirement on a scale of 1 to 5 based on
a system as specified in Table 14.
3 Pfleeger, Software Engineering Theory and Practice, pp. 178-179
Software Engineering 116
J.E.D.I
System Designer
Rate Description
1 It means that the designer understands this
requirement completely, and that he has designed a requirement similar to this one
from previous projects. He wont have any problems designing this one.
2 It means that there are aspects of the
requirement that are new to the designer; however, they are not radically different from
requirements that he has successfully designed in previous projects.
3 It means that there are aspects of the
requirement that are very different from requirement the designer has designed
before; however, he understands it and is confident that he can develop a good design.
4 It means that there are parts of this
requirement that he does not understand; he is not confident that he can develop a good
design.
5 It means he does not understand this
requirement at all and he cannot develop a design for it.
Table 15 System Designer Scale Description
For testers, they are asked to rate each requirement on a scale of 1 to 5 based on the a system as specified in Table 15.
Software Engineering 117
J.E.D.I
System Tester
Rate Description
1 It means that he understands the
requirement completely, and that he has tested similar requirements in previous
projects; he is confident that he will have no trouble testing the code against the
requirement.
2 It means that there are aspects of the
requirement that is new to him; however, they are not radically different from
requirements that he has successfully tested in previous projects.
3 It means that there are aspects of the
requirement that are very different from requirements he has tested before;
however, he understands it and is confident that he can test it.
4 It means that there are aspects of the
requirement that he does not understand; he is not confident that he can devise a test to
address this requirement.
5 It means that he does not understand this
requirement at all, and he cannot develop a test to address it.
Table 16 System Tester Scale Description
If the result of the requirements profile resulted with 1s and 2s, the requirements can be passed on the designers and testers. Otherwise, requirements need to be reassessed
and rewritten. You need to iterate back to the requirement engineering phase.
Assessment is subjective. However, the scores can provide useful information that encourages you to improve the quality of the requirements before design proceeds.
Software Engineering 118
J.E.D.I
3.7 Exercises
Kategori