Using CMMI for software requirements testing in system design & development

Brian Hooper

September 23, 2009

Brian Hooper

Requirements-Driven Development
The CMMI Technical Solution (TS) dictates that solutions are constructed according to requirements. The development team must determine if all requirements are going to be implemented at once or if it's better to focus on a few requirements at a time and construct a solution incrementally.

CMMI does not address these issues. It is up to the project team to adopt development practices and processes which guide project progress while also meeting the goals of CMMI.

Following a "waterfall" development model has many disadvantages and led to the rise of alternative models such as the Unified Process and Agile methodologies.

Latter day methodologies typically place strong emphasis on the management of requirements as well as the organization of requirements as a driver for downstream development. A couple of key principles shared by the majority of methodologies may be summed up as follows:

1. Straightforward, user-focused formulations of requirements are preferred to long lists of individual features or constraints. Variously called "Use Cases" or "User Stories", they enable better collaboration with the end user as well as placing focus on the value or benefits that the solution should deliver.

2. Requirements change over the life of the project. This is natural and inescapable, whether due to the end user changing their vision of the solution or the project redefining its scope. Projects therefore should be organised and managed to accept and embrace change.

Use Cases are formally defined in the Unified Modelling Language (UML) while User Stories are an element of Extreme Programming; however the concept behind each is roughly the same " to partition the system with a coarser granularity than a list of requirements, while at the same time considering what the system delivers to the end user rather than simply what it does.

For example, an engine management subsystem specified as a bullet-point list of requirements inevitably inspires thoughts of implementation whereas the focus at this stage needs to be on what the subsystem delivers to the other subsystems to which it connects. User Stories are typically written on small paper cards or even Post-It notes, enabling easy collaboration and discussion by project teams.

Use Cases can be formulated in the same way or created with a UML tool, as illustrated in Figure 2, below. Some key points to note on this Use Case Diagram are that the system boundary is clearly marked, the Use Cases themselves sit within the system boundary and all Actors (note that the stickman representation does not imply that an Actor must be a human being) are outside the system.

Figure 2. Use Case Diagram

Each Use Case or User Story comprises several scenarios. The first scenario is always the "basic path" or "sunny day scenario" in which the actor and system interact in a normal, error-free way.

Returning to the engine management subsystem example, a scenario may cover idling during which the fuel supply remains constant and the temperature stays within limits. Then alternative and exception scenarios need to be considered in which the system handles problems or failures, such as fuel cut-out.

The end user must be fully involved in the development of scenarios and, as each is completed, a priority is assigned to enable the complete set of scenarios to be ranked. As illustrated in Figure 3 below, the project team needs a priority-ordered list of scenarios to plan each iteration and select which portion of the system will be implemented.

Figure 3. Extreme Programming Workflow

Once verification of an iteration is complete progress metrics may be derived. The team needs to ask, "Were all selected scenarios implemented and tested? Was any regression seen in previously completed iterations?" Through regular analysis of progress, the calculated "Velocity" can be used to plan future iterations.

Meanwhile, during development, the end user may have changed or updated their requirements resulting in modifications to the priority-ordered list of scenarios. An iterative approach allows projects to be flexible to both an end user's changing demands as well as development progress.