Requirement Quality Measurement

Requirements engineering deal with elicitation, analysis, communication and validation of the requirements. As early as errors are identified it is easy to fix them compared to later identification of errors. It is obvious that the cost of fixing these errors in initial stages is lower than fixing them in later stages of software development. In order to eliminate errors there should be some measurement. Metrics provide a quantitative measurement of certain attributes.

We know the main quality parameters of requirements are: Understandability, Completeness, Testability and Volatility. Metrics of these parameters can give us a quantitative measurement of requirement's quality:

1. Understandability: % of requirements is readable or understandable by the reviewers or next level users. Metrics is (Number of understood requirements) / (Total number of requirements). E.g. if total number of requirement is 40 and 30 requirements are understandable by the stakeholders then understandability of those requirement is 75%.

2. Completeness: % of requirements is complete (no item left to the requirement specification). Metrics is (Number of complete requirements) / (Total number of requirements). E.g. if total number of requirement is 40 and 35 requirements are complete then completeness of those requirement is 87.5%.

3. Testability: % of requirement is testable. Metrics is (Number of testable requirements) / (Total number of requirements). E.g. if total number of requirement is 40 and 38 requirements are testable then testability of those requirement is 95%.

4. Volatility: % of requirement changes. Metrics is (Number of changed requirement) / (Total number of requirements). E.g. if total number of requirement is 42 and 5 requirements are changed then volatility of those requirement is 11.9%.
Note: Change requirement = Modified requirements + New requirements.

Other requirement metrics can be developed as per the company need. GQM (Goal, Question, Metrics) is a popular method for metrics development.

Benefits of Defect Ratio Analysis

Measurement and Analysis is the key of process improvement or taking any decision. And Metrics is the most useful tool for Measurement and Analysis. A single Metrics can give us lot of information for decision making. In this post I have tried to explain the benefits of Defect Ratio analysis.

Defect Ratio is a measure as well as a metrics of defects against product size. If your product size is 500 Use Case Point and total number of defects are 200 then Defect Ratio is (200/500) = 0.4. We can analyze the defect ratios by calculating the defect ratio in different time period of a project.

Lets, one of an objective of our processes is to ensure that our defect ratio will be less then 0.45 and variation of the defect ratios will not be more then 0.1. Then in a project we have used those processes, calculated the defect ratios in different time period and plotted the following graph.

From the graph we can say:

1. The Process is not good enough to achieve the objective of ensuring the defect ratio <= 0.45


2. The Process is not stable or matured enough. Because, the variation of the defect ratio is more then 0.1 (0.54-0.35 = .19)


3. Project team is not skilled enough to make sure the defect ratio <0.45

We can also take decision from the graph to improve our processes or increase the skill level of our project team.