Requirement Breakdown Structure (RBS)

We know that to completely and clearly document requirements at the beginning of a project has never really happened. The problem is not with the process. The problem is that the world and our brain are not static. It never has been and never will be. There must be better ways. And there are! So, requirements should be developed such a way that are changeable and manageable. In this post I’ll try to share requirement development technique or Requirement Breakdown Structure, the foundation of all great project management.

Basically in requirement phase we do the following activities:

• Identify the source of requirements
• Take preparation for requirement collection
• Collect the requirements
• Develop the requirements
• Verify and validate the requirements

Requirement breakdown is the part of requirement development activity. But this is a challenge for ensuring that requirement breakdown is good enough or understandable and manageable, because breakdown of the requirements vary person to person.

In my opinion the best way to break the requirements is, keep it small, define the acceptance criteria of each requirement, define the relationship between requirements and then encourage the users to correct, improve and baseline them. Acceptance criterion is the key technique here. Try to write the acceptance criteria for each of the requirement then you will see requirement will be automatically small, understandable and manageable.

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.