CMMI and Understanding Requirements

We have recently been involved in a LinkedIn discussion about understanding requirements.  We have had several quick blog posts on requirements over the years.  For example, we have written about the connection of requirements and project management. We have also discussed how requirements grow over the course of the development of the product.  We have also reviewed the connection between requirements and testing of the product.  There is more to testing than to requirements, but at least a portion of the testing should compare the product against the requirements.  Those blog posts were just a quick demonstration to help show project managers how this process area and the specific organizations capability can help or hinder the project progress.  Not only hinder but put the project at risk altogether of being able to achieve the objectives of the project.

Disparaging Requirements is NOT the Road to Success

The LinkedIn conversation spoke of requirements in a disparaging way.  My experience of  generating and handling are not quite so negative.  Gathering and understanding the requirements can take time but it is time well spent. The alternative is to not take this time to develop an understanding which will lead to constant rewriting and reworking, important items missing and trivial items added to the requirements documentation.  It is often not possible to understand the entire scope of the product needs in the beginning.  That is why we prioritize those aspects of the product that are most prized by the customer.  To that end, we must know the significant players or mechanisms from which we will get the product information we need.  This is important for the initial exploration of the product  as well as throughout the product development and is a significant input for the project manager.  We will also need to know when we have a something that bears sufficient weight to be defined as a requirement.  In general, we will produce such work items as[1]:

1. Lists of criteria for distinguishing appropriate providers
2. Criteria for evaluation and acceptance of requirements
3. Results of analysis against criteria
4. An agreed to set of requirements

Requirements Understanding

At the end of this collecting, understanding, and vetting, we will have some agreed to set of requirements from which we can begin our work.  This is not the end of the requirements work that will be performed.  This is just the first sets of steps in our requirements work.  At no point in the CMMI documentation does it suggest that the requirements gathering and documentation a single point event.  As we document and build an instantiation of the product we can expect to learn about the product and our way of working that will influence the next iteration of the product.  We will then use what was learned to update the requirements documentation in a controlled way.  More on that in a future post.