The application of knowledge, skills, tools and techniques to project activities to meet project requiremrnts (PMBOK)
What is Requirements Management?
Put simply, Requirements Management is “the Process of Managing Change to a System’s Requirements”. Requirements are often not clearly stated. There are many reasons why requirements change, for example:
- Customer/user knowledge of the system that evolves as the requirements are understood or developed
- Technical, cost or scheduling problems that result in requirements being dropped or reduced in scope
- Errors in understanding customer or user requirements
- Changes in the environment, such as changes in legislation, regulation, company take-over or reorganisation
Lack of a requirements management process greatly increases the risk of scope creep, project delays and spiralling costs.
The types of requirements that are most likely to change are:
- Mutable Requirements – these are requirements that are affected by external influences eg a change in tax laws. These requirements usually can’t be influenced by the organisation, but have to be taken into account.
- Emergent Requirements – requirements that become more apparent as the system becomes better understood.
- Consequential Requirements – these requirements are affected by the way a system is to be used. For example, a certain set of commands in a safety-critical system, such as a life support medical system, may cause the equipment to malfunction and could result in injury.
- Compatibility Requirements – requirements that are related to hardware or other software. An example could be an upgrade to an operating system, database software or a new version of hardware.
Managing Changing Requirements
Organisations that have a structured process for handling changing requirements have the following features:
- A management process for handling changes to requirements
- A body (usually called a Change Control Board or CCB) that considers the proposed changes
- Templates, tools or other support for the change management process
Each of these features is described in more detail, below.
Change Management Process
A typical requirements change management process consists of a number of steps. The requirement may be a new requirement or a change to an existing requirement. The CCB which includes the project’s relevant stakeholders are involved in the execution of the process.
- Initiation / kick-off, usually through a change request that describes the requirement, the reason for the requirement change and a unique id. It may also include information such as any other related requirements that are affected by the change, cost of implementation etc. The change may be initiated by a customer/user, business analyst or any other stakeholder involved in defining the requirement.
- The proposed requirement change is analysed in terms of cost, time or impact on the overall schedule.
- Based on this analysis, the CCB decides whether or not it will implement the change; the decision will be based on factors such as: the severity of the change; cost vs benefit or can it be handled in the project’s schedule
- If the CCB decides that the change is to be implemented, it is communicated to any stakeholders eg user/customer, project manager, project team etc. that are affected by that change
- The change is then implemented and verified.
- If successful, the change is closed off.
Change Control Board
The Change Control Board (CCB) is responsible for considering any changes in requirements. The roles on the CCB include:
- Chair – responsible for chairing the CCB meeting and has the casting vote. The chair represents the interests of the user / customer and the interests of the development team.
- Originator – responsible for raising the change request and is a stakeholder from the project
- Evaluator – takes primary control for evaluating the request
- Verifier – ensures that the change request is implemented and verified.
Depending on the size of the project, these roles can be combined, or if a large project, a particular role may be fulfilled by several people.
Impact Analysis
A key part of the change control process is to carry out an impact analysis of the proposed new or modified requirement. The impact analysis involves estimating the time, effort and cost of implementing the change. This will involve tallying the cost through the project’s life-cycle and any additional support costs. Any other requirements that are affected by the change are also considered.
The impact analysis will include the relevance and importance of the requirement and the potential business benefit, if implemented.
Common Problems with a Change Control Process
Some common problems with a requirements change control process include:
- Too complex for the size of organisation or project, thus introduces an unnecessary overhead.
- Lack of management buy-in to the process
- Ability of the CCB to meet in a timely fashion, thus possibly introducing delays to the project or lack of a decision being made
- All changes, including very small changes, having to be reviewed by the CCB. In many organisations, a project budget contingency is allowed so that the Project Manager or other relevant stakeholder can decide whether a change can be made.
Conclusion
In summary, you design your change control process to suit the needs of your organisation. It is important to balance the overhead of implementing a requirements change control process with the risks of not having one in place.
Templates are available on the web for implementing a change control process that manages changing requirements. For example, Karl Weigers has a number of templates that are available for download. For more information, see:
http://www.processimpact.com/goodies.shtml#reqs