A project iteration starts with Requirements Analysis phase. In this phase, the requirements are gathered from various stakeholders of the project. A requirement defines the work that needs to be carried out in a project. Though most of the requirements being implemented by the project are finalized within this phase they are subject to change.
Some of the factors that can influence a requirement change in a project are as follows:
- Change in the stakeholders needs
- Change in government policy or any rule and regulation which should be followed by the project
- Changes in technology – introduction of better hardware or software in the market, deprecation of a hardware or software and cease of its support from its provider
- Expiry of a software license, increase in cost of a software license
Thus, requirements engineering is an ongoing process. Dr. Karl Wiegers in his book Software Requirements, has classified Requirements Engineering into the following two processes:
- Requirements Development
- Requirements Elicitation – Gathering requirements from project stakeholders
- Requirements Analysis – Decomposition of a requirement into low level requirements and doing feasibility study. Prioritizing requirements and identifying their scope.
- Requirements Specification – Documenting the requirement
- Requirements Verification – Ensuring the validity of a requirement
- Requirements Management – Ensuring that a requirement change does not negatively impact the project scope and schedule through impact analysis
Requirements Engineering is often called as Requirements Management in the literature of Rational software.
The Gartner survey done in June 2012 on why the projects fail, gives the following top 4 reasons of their failure in small, medium and large IT projects:
- Functionality issues
- Substantially late
- High cost variance
- Poor quality
From my experience of working on small projects, I feel that following are some of the causes which lead to a project failure:
- No/Inadequate documentation
- Inadequate requirement analysis and planning
- Inefficient change management
- Lack of processes or they are not followed diligently
The importance of documentation
Small IT projects have low budgets and people often make a mistake of not investing time and resources in adequate documentation on the pretext of saving costs. Though documentation is not the primary outcome of any software project, the accuracy of documents such as System Requirements Specification (SRS), use cases, Internal Design Documents, Architecture Description Documents, project’s vision and scope, list of processes and standards to be followed are very crucial for a project’s success. Many small software companies do not follow the CMMI standard set of practices or they are not followed for small projects. As a result of no documentation or inadequate documentation or inadequate processes for documentation, there is always a risk of ambiguity or missing a functional or non-functional requirement. When the scope of such a project having insufficient documentation increases or a requirement changes, the probability of introduction of gaps in the impact analysis which can lead to a project failure is higher.
Developing key skills for Requirements Management
A Rational Software white paper on Requirements Management with use cases has suggested developing the following key skills for effective requirements management:
- Analyze the problem – Find “the problem behind the problem”.
- Understand stakeholders’ needs – Use requirements elicitation techniques such as interviews, brainstorming, conceptual prototyping, questionnaires etc. to identify the stakeholders’ needs and their priority.
- Define the system – Describe the system to be built using text and graphics.
- Manage the scope of the system – Identifying the requirements based on their priority and risk that can be implemented in the project with the available resources.
- Refine system definition – Creating detailed high level system definition.
- Manage changing requirements
Requirement Change Management
As the accurate documentation of requirements is important, tracking changes in the requirement is also equally important. A change in a requirement can occur during any phase of a project life cycle. It can be an addition of a new feature or modification in the existing requirement, introduction of a completely new requirement, change request to modify an existing functionality implemented in the system or a request to fix a defect in the existing system.
Since the request for change can come through many channels, a Change Control Board (CCB) constituting the various stakeholders of a project can be set up to consider which requirements should be incorporated in a project depending on their priority, risk and impact analysis. All change requests should be routed only through this board. Since a project’s requirements can change throughout its life cycle, the impact analysis of each change request should be made and if it is feasible to implement it within the project scope and schedule then only it should be incorporated in the immediate release or it should be scheduled for later releases.
Sometimes a high priority change which can delay the project’s schedule needs to be implemented immediately for e.g. change in government policy. In these cases, the Project Manager can decide to meet the project schedule by adding more resources and thus increasing the budget of the project. These things are taken care in the impact analysis.
Requirements Version Control
To identify the difference between various versions of a requirement, a version number can be associated with each requirement change. Dr. Wiegers has suggested the use of the requirement status to maintain the changes in the requirements. Typical requirement statuses are given below:
- Draft – The requirement is being drafted.
- Accepted – The requirement is being analyzed.
- In Review – The requirement is ready for review
- Approved – The requirement is accepted and will be assigned to a release
- Deferred – The requirement will be implemented in later release
- Rejected – The requirement will not be implemented.
Since there are many stakeholders who can request a requirement change, only few should be authorized to make changes in the requirement documents.
Using Requirement Management Tools
Use of tools such as Rational RequisitePro or HP Quality Center for requirements management, requirements change management and version control can help in maintaining the requirements traceability and identification of impacting use cases and related requirements when a requirement changes. The possibility of missing a use case or a related requirement is less with the help of such automated tools unlike when the requirements are managed as Word or Excel documents.
A requirement’s traceability helps in identification of:
- Requirement description
- Related requirements
- Use cases
- Related Software design documents
- Test cases
Usually small organizations are unwilling to invest in such tools due to their high license fees. However, investment in such tools can help an organization in the long run by reducing the failure rate of projects which can occur due to improper requirements management.
Some organizations use Version Control software for managing the requirement documents. However, these tools do not provide automated traceability with use cases and related requirements and it needs to be manually maintained. There is a risk of missing a use case or a related requirement while evaluating impact of a requirement change. Time sensitive requirements or high priority requirements cannot be easily searched by using only version control software and there is also a risk of missing such type of requirements.
Use of requirement management tools can also help in identifying the requirements deferred for later releases or requirements with a certain priority or risk with ease. There is no mechanism to identify such requirements based on their status or priority or risk factor when only version control software is used for requirements management. Chances of missing a requirement is high in the latter case.
A requirements management tool also helps in identifying the estimated and actual effort for implementing a requirement. This data can help in effort estimation of a similar requirement in future.
A requirements management tool can also send automated notification mails to the owner of the requirement and its relevant stakeholders when it is changed or its status changes.
Conclusion
Efficient requirements management can certainly help in reducing the failure rate of IT projects.
