CMMI^® Maturity Level 2: Managed

The first two articles in this series discussed and described a process, and looked more closely at the content and implementation of the CMMI^® model. The first addressed the importance of understanding the reasons and objectives for starting with a process definition and the value of process implementation, and the second explained that the CMMI^® model comprises different maturity levels, each of which contains process areas that need to be addressed.

This article continues by starting to discuss Maturity Level 2 and its applicable process areas.

The Maturity Level 2 Process Areas

The CMMI^® Level 2 maturity process areas consist of:

• Requirements Management.
• Project Planning.
• Project Monitoring and Control.
• Supplier Agreement Management.
• Measurements and Analysis.
• Process and Product Quality Assurance.
• Configuration Management.

This article focuses specifically on Requirements Management.

It is important to remember that although process areas are repeated across many of the maturity levels, the specific and generic goals to be achieved in each will differ. Let's look in more detail at the Level 2 process areas, and attempt to make them relevant to a testing organisation.

Requirements Management Level 2

We could define requirements management as knowing what it is that the customer needs, and making sure the product meets those needs. Requirements Management aims to manage the project's requirements, and identify and highlight differences between these and the test project plan and work products, e.g. the differences between the test strategy and the actual project requirements. 

Specific goals of Requirements Management Level 2

• Obtain understanding of requirements

  Critical to any testing project is the clear and detailed understanding of all the requirements related to the target of the test. This would include both functional and non-functional requirements. It is important that the test team plan this activity in a manner that will best fit the project. A possible list of outputs in this area would typically be:

  • A document detailing the sources of the appropriate requirements.
  • A plan that details how an understanding will be achieved; this may include detailed steps and checklists.
  • A score allocated for provided test requirements measured against a check list.
  • An agreement that the requirements provided are sufficient for the test team to commit.

  Criteria against which a typical test requirement could be measured would normally include Testability, Completeness and Traceability.

• Obtain commitment to requirements

  To manage testing projects in today's large and complicated business environments, it is important to get all the project stakeholders to buy into, and commit to, the requirements of the project. The structure of modern project teams is complicated and includes participants from various areas within the organisation. The commitment of these participants to the project requirements is critical to the success of the testing project, and the project in totality.

  The following should be considered when contemplating committing to test requirements.

  • We need to understand how committing to these requirements will impact our current workload. Will we be able to deliver if we commit to these new requirements?
  • We need to understand how, once we have committed to these test requirements, we will deal with changes, and commitment to these changes.
  • The testing organisation needs to detail how to formally document their commitment to the requirements.

  All the testing team members should be included in discussions before committing to any test requirements, keeping in mind that committing to requirements includes timelines and deliverables.

• Manage requirements changes

  As anyone that has been part of a testing project knows, requirements change. The way in which we manage these changes, and their impact, is critical to the success of the project. The origin and the rationale behind these changes must be understood.

  The CMMI^® model suggests looking into the following deliverables as a way of managing changes to requirements.

  • Assign and track requirements status. Examples of this could be to group all of the signed-off requirements separately from new and revised requirements.
  • Maintain a database of all requirements, which will provide some basic search and grouping functionality.

  The test team will be required to maintain a change history of requirements for a specific project. This will provide an indication of the stability of the project, which indirectly may indicate the quality of the project. The changes to requirements further directly impact the timelines of the project, and replanning and communicating these changes to the large project team is thus important.

• Maintain bi-directional traceability

  As a test team we should be able to trace any test product (which could include both test cases and test results) back to the original business requirements. For one, this practice would enable confirmation that the product requirements were addressed fully; but, more importantly enable the immediate assessment of the impact on requirements changes to the testing effort and deliverables.

  The CMMI^® model suggests the following artefacts to aid bi-directional traceability:

  • The use of a requirements traceability matrix that allows us to see, at a glance, the relationships between business requirements, test cases and results.
  • The implementation of a system that would automatically maintain these bi-directional relationships.

  The added benefit of this approach is the ability to de-scope based on the priority of the product requirements.

• Identify inconsistencies between project work and requirements

  It is important to use all of the requirements management information available. The test project manager should be able to identify any highlighted differences between the client's requirements and the output provided by the test team. 

  It is important to document these inconsistencies and identify the reasons why misalignment exists. There must be a plan to address these differences, and this plan must be executed.

  The next article looks at the next process area in Level 2, namely Project Planning.

  Mike Snyman

  References:

  CMMI^® for Systems Engineering /Software Engineering/Integrated Product and Process Development, Version 1.02: CMMI^®-SE/SW/IPPD, V1.02 (Staged Representation)

  ^®       Capability Maturity Model, Capability Maturity Modelling, Carnegie Mellon, CMM, and CMMI are registered in the U.S. Patent and Trademark Office by Carnegie Mellon University.