Introduction

The requirements development process area, a process area at maturity level 2, aims at producing and analyzing customer, product and product components requirements. CMMI states that requirements start as customer requirements (stakeholders expectations are expressed here) and are later refined into product and product components requirements (expressed in a more technical fashion) with the input of the technical members after analysis and design is performed.

Below are the specific goals and practices:

SG 1 Develop Customer Requirements

SP 1.1 Elicit Needs

SP 1.2 Develop the Customer Requirements

SG 2 Develop Product Requirements

SP 2.1 Establish Product and Product Component Requirements

SP 2.2 Allocate Product Component Requirements

SP 2.3 Identify Interface Requirements

SG 3 Analyze and Validate Requirements

SP 3.1 Establish Operational Concepts and Scenarios

SP 3.2 Establish a Definition of Required Functionality

SP 3.3 Analyze Requirements

SP 3.4 Analyze Requirements to Achieve Balance

SP 3.5 Validate Requirements

Is it Compatible?

CMMI states that stakeholders needs, expectations, constraints and limitations may be difficult to obtain and therefore it suggests an iterative process (very much like Agile). It also states the importance of having a customer surrogate, role that very much resembles that of the Product Owner. However, it also talks about refinement and allocation. I have 2 concerns about those.

Is there really the need to express requirements in a technical fashion? Is it advantageous?

Requirements in a software development project represent the common area of understanding between technical and business people. Refinement of Customer Requirements into Product Requirements implies having 2 sets of requirements and therefore the integrity of both have to be assured (i.e. assure that all customer requirements have been address in the product requirements, which if they are written technically will be inaccessible to business folks). This is not to say that requirements should not be refined. I believe they should, but the end result should be one set of requirements that all members of the project can understand. Some people could say that Customer Requirements may be expressed in a business language too difficult to understand for developers. However, is it possible to build a software system without the developers understanding the business logic of what they are building. I don’t think so. There is another issue that worries me about this refinement. All Agile requirements (User Stories) have some business value associated with them. Although sometimes it can get difficult to slice functionality small enough to enter into an iteration, the advantages of building tangible, visible functionality are many. Although CMMI doesn’t state anything about the business value of any type of requirements, I am afraid that this type of requirements may result in technical requirements without visible value. In any case, stating that all requirements introduce some new business value to the system is really important.

Is there really the need to allocate requirements to technical components?

Who is this useful for? When is it done? Requirements should express what needs to be done. They shouldn’t express how it is supposed to do it. Otherwise, the requirement is biasing the implementation. Traceability is one of the reasons that CMMI states for performing this allocation. However, as I said before I am not sure about the benefits of having this traceability that assures that requirements have been addressed, but not that they have been full filled. Besides, I reckon that this traceability may be too heavy to keep up to date. Instead, I believe that automated tests expressed in the business language provide the certainty that the requirement have been full filled while being always up to date.

Conclusion

Although requirements in Agile should be refined (user stories start as a point of conversation and grow afterwards), the common shared place of understanding is always the product backlog, which is unique set of requirements. Translating customer requirements brings more disadvantages than advantages in my opinion. Same with the allocation of requirements to technical components. Something that really caught my attention is that the CMMI doesn’t say anything about ordering requirements by priority. In Agile, this is a top of the shelf matter, vital to the success of the project.

Other Areas

- Is the Configuration Management Process Area compatible with Agile?

- Is the Process and Product Quality Assurance Area compatible with Agile?

- Is the Measurement and Analysis Process Area compatible with Agile?

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