Requirements Management

Requirements

Either it is for an Applications and Services organization or for a Products Development organization, requirements are the drivers to successful completion of the projects that develop these applications, services or products. The significance of the requirements is so significant because requirements provide the basis for all of the follow-on activities in the project. Surprisingly, the requirements management is still one of the areas in software engineering that draws least attention in the entire development cycle. Considering that requirements errors are the largest category of errors in a project justifies spending more time and effort on the requirements management process.

Progression

There is a difference in the life-cycles of a typical application development and a product development cycle. In case of an application development, the requirements come from a customer (external to the organization or internal, within). The project manager is identified, the project is chartered, project team is formulated and the solution is developed and shipped to the customer. The product development cycle extends further in the sense that the requirements collection process continues even after the product has been released and these are incorporated in the next version of the product. In either case, the project manager and/or a business analyst goes through the requirements, interpret them and come out with a set of specifications that define how each requirements would be addressed by the development team.

Issues arising due to poor requirements

Therein lies the real problem. Studies have shown that the involvement of the customer at this stage of requirements analysis is less than what it should be; and often leads to most requirements related issues. These are some of the major reasons why requirements can be real project-killers:

- Requirements are not clearly stated or are incorrectly stated
- Missing requirements
- Requirements are not interpreted correctly
- Customers change the requirements too frequently

Also, according to Dr. Ralph Young, the author of The Requirements Engineering Handbook, there is a huge difference between customer’s real needs and the stated needs. The customers all over do not have a history of expressing their needs and requirements in a clear form and unfortunately this is not going to change over time. It is the challenge for the project manager (or a specialist requirements analyst) to extract the requirements in the customer’s mind and convert them into a compatible form, so that they can be developed to meet the business needs of the customer. The fact that there could be too many such stakeholders feeding the requirements makes it even more complex. Real challenge, isn’t it?

Benefits of good requirements

There are obvious benefits of effective management of requirements. Good requirements management leads to:

- reduced time to finish the development process
- no cost overruns
- less rework
- better quality control

For products companies who operate in a competitive environment, these benefits mean a distinct advantage over the competition as the product can be shipped on time and within budgets.

Best practices for requirements management

What would ensure that a good requirements practice is established? According to Dr. Young, following processes would help in creating such a practice:

1. An atmosphere of cooperation and collegial problem solving among the project stakeholders is to be created at the beginning of the project and maintained throughout its performance period.

2. Create a joint team of people possessing knowledge of the customer requirements with the authority to make decisions concerning requirements on behalf of the project.

3. Identify the real customer needs as against the stated needs.

4. Establish a documented requirements process, always use it and continuously improve it

5. Iterate the requirements throughout the life of the project cycle, since they are never finalized and typically, there are extensive refinements and changes to the requirements as development proceeds.

6. Put in place an effective change management process that has been agreed upon by all stakeholders. Verify all requirement changes.

7. Communicate the consequences of a requirements change to all stakeholders.

8. Use best practices of project management proven across the industry, organization and projects.

9. Allocate a certain percent of the total project cost (typically 8 – 14%) to requirements management.

10. Ensure that there is a buy-in from the senior management to the process and it allocates the necessary resources to support it.

These steps would ensure that the project follows a proven, efficient process to keep requirements despondency in control and lead to a successful project and meets the triple constraints of the development – cost, time and scope – and maintaining the overall quality as committed by the organization in its policies.


References

1. The Requirements Engineering Handbook by Dr. Ralph R. Young.

2. Requirements – Pandora’s Box for Project Managers By Frank P. Saladis, PMP

Posted by Sameer Iyer