Procedure for Managing Requirements
From Requirements Management School
However complete your SRS is, it was only complete at that moment in time. There are many reasons why requirements might change during the lifecycle of a project none of which you can do anything about. Even if some of the change requests can be denied as being outside scope, they still need to be analyzed first to determine this. They must also be recorded. In the end all you can do is have a robust process in place for managing the requirements after the baseline is set.
Areas Within Requirements Management Process
There are four distinct areas that fall within the requirements management process, these are:
Change Control – A proper process for receiving, managing and communicating changes is critical. There are several issues that can arise from the lack of a robust process in this area. Some of these are; change requests falling through the gaps; scope creep; miscommunication of changes leading to all sorts of problems down the line. A robust change control process should include the following steps:
- Logging of request
- Analysis and assessment of requests
- Prioritization and authorization (or not) of request
- Negotiation for resources
- Implementation of request
- Documentation and dissemination of the change in a timely manner.
Version Control – Requirements are not static and neither is the business environment. This means that once the baseline document is in place you will then need to adopt strict version control for all the documents. Every change that is made needs to be reflected in all the documentation and then all the documents need to be re-issued so that all the stakeholders are working from the same set of documents. The best practice is to adopt whatever conventions are used within your organization. The version control conventions should be applied consistently. Both of these should help to mitigate any confusion.
Requirements Status Tracking – You need to be able to monitor the progress being made throughout the lifecycle of the project. You will need to define a set of status codes for the lifecycle of the project for instance code for, a requirement that has been implemented; a defective requirement; a new requirement that is awaiting authorization and so on. These codes need to be updated in a timely manner.
Requirements Tracing – Bidirectional traceability is a key control and compliance issue on any software engineering project. By ensuring that each requirement can be traced to its origins, use cases, test cases, source code and design, you mitigate unnecessary development. It is also the only way to make sure that no requirements are dropped in error or that new ones creep in without approval.
