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.

Rework effort in SELC

Rework is an ongoing problem in software development. As per SEI (Software Engineering Institute) report it has been indicated that 60-80% of the cost of software development is rework effort. This effort is used to correct defects associated with base-lined work-products. Unfortunately, the reason is a gap between the state of the art and the state of the practice of software engineering.

In SELC (Software Engineering Life Cycle) all out put is treated as work-product. E.g. Project Plan Document, Requirement Specification Document, Source Code, Test Specification, Test Report, Release Note etc. And when a work-product is approved or validated by the relevant stakeholders for using next level users than it called base-lining.

Common causes of re-works in SELC:

1. Requirement Analysis Gap (main root case of rework)
2. Wrong Software design (e.g. performance issue not considered in the design)
3. Poor Code development (e.g. features not developed as is software design)
4. Inadequate Test Case development (e.g. insufficient test cases for each requirement)

Despite successes in reducing rework, it is generally accepted that rework cannot be eliminated entirely. However, rework effort can be reduced by taking process improvement. For example:

• Introduce or improve the formal review process in requirement, design and coding phases. [If formal review is implemented then defect will be identified from the earlier stage of SELC, it will reduce rework significantly.]
• Integrate test cases with requirements [if each test case is mapped with requirements then it will be easier to measure that sufficient test cases is developed/not to test that requirement]
• Conduct Inspection [periodical inspection on work-products and processes implementation helps to identify defects as well as increase the consciousness of project team members to develop quality work-products and follow the processes]

Therefore, to reduce the rework effort it is required the use of disciplined engineering practices by skilled software engineers.