Is the Requirements Management Process Area compatible with Agile

 Introduction

The requirements management process area, a process area at maturity 2, deals with managing all requirements related to the project throughout its life.

Below are the specific goals and practices:

SG 1 Manage Requirements

SP 1.1 Obtain an Understanding of Requirements

SP 1.2 Obtain Commitment to Requirements

SP 1.3 Manage Requirements Changes

SP 1.4 Maintain Bidirectional Traceability of Requirements

SP 1.5 Identify Inconsistencies Between Project Work and Requirements

SG 1 Manage Requirements

The only objective in this process area states that requirements should be managed by doing the following:

• Managing all changes to the requirements
• Maintaining the relationships among the requirements, the project plans, and the work products
• Identifying inconsistencies among the requirements, the project plans, and the work products
• Taking corrective action

All of this is completely true in an agile environment. However, the practices recommended to get there is very different. Let’s analyze each of the practices.

CMMI lists the following as the recommended practices to manage requirements:

1. Obtain an understanding of the requirements. When and how complete? Well, the objective states that “The project maintains a current and approved set of requirements” so my assumption is this understanding is complete.
2. Obtaining commitment to Requirements. From those “who have to carry out the activities necessary to implement the requirements.”
3. Manage Requirements Changes. Analyze impact and document rationale.
4. Maintain Bidirectional Traceability of Requirements. From requirements to source code and vice-versa. This traceability helps determine requirements have been completely addressed.
5. Identify Inconsistencies Between Project Work and Requirements.

Requirements are managed differently in Agile. Let’s see how the practices would change:

1. The project backlog doesn’t represent a current approved set of requirements. Requirements in a backlog have different levels of understanding and approval. Requirements live their life in the backlog with different levels of understanding and approval. They are born as ideas, “topics of conversation” and grow their understanding and approval, even after they are implemented. The driver in this understanding is their priority. More important requirements need to be understood/approved first. There could be phases in the form of releases in the backlog that will determine the understanding and approval of a set of requirements.
2. It is important the Agile recommendation of having cross-functional teams. A jelled team which contains all the necessary expertise represents the easiest path for full commitment.
3. Changes in the backlog should be managed lightly, but continually. In fact, I am not even sure that they should be named changes. As previously mentioned in point 1, a requirement grows in the backlog, perhaps changing its status, form and priority. This doesn’t mean that Agile embraces high volatility or churn. All stakeholders should be aware of the impact of the changes. A change may be important, but is never free. The Product Owner, responsible for the ROI is the one to make the trade-off.
4. Maintaining traceability could be very time consuming and only helps determine that requirements have been addressed. Acceptance Tests are less time consuming are help determine that requirements have been fulfilled.
5. Again, automated acceptance tests are the recommended practice to detect and fix inconsistencies in an Agile project. Doing this manually would be too time and mind consuming. Computers should maintain all this knowledge gained and detect the inconsistencies for us. The second recommended practice is to involve the customer through all the project. Customers are the best persons to detect inconsistencies (should we call them inconsistencies?)

What is missing in the recommended practices?

Prioritization: One of the most important aspects in managing requirements in an agile environment is managing priorities. Prioritization works starts at project inception and follows throughout the project. Of course, this is a very difficult task as it involves not only understanding the business value that different requirements add but also making trade-offs based on technical feedback and measures of effort.

Requirements live and Requirements light: One of the most difficult and time consuming tasks during a project is to maintain requirements up to date. If doing this is too time consuming, agility suffers. Many agilists suggest that the best way of maintaining them is through maintaining them as executable requirements (or executable specifications, examples, etc.). An executable requirement must be maintained and it always up to date. Being able to execute/debug this requirements allows to easily trace requirements with source code.

Conclusion

I believe the only goal of this process area is entirely applicable in an agile environment, but the path to get there goes in a complete opposite direction. The CMMI recommendation is to get a complete approved set of requirements, which is maintained and traced to the source code (and viceversa) throughout the life of the project. The agile recommendation is to maintain a prioritized executable specification at all times. The later mechanism is lighter, assures is up to date and automated.


Other Process Areas

- Is the Project Monitoring and Control Process Area compatible with Agile
- Is the Project Planning Process Area compatible with Agile?