Using CMMI for software requirements testing in system design & development
Requirements-based testing, and its inherent process of requirements traceability and verification, is widely viewed as a best practice according to corporate standards such as the Capability Maturity Model Integration.
CMMI can guide process improvement across a project, a division or an entire organisation with benefits established for critical as well as non-critical software. CMMI for Development v1.2 contains 22 process areas, amongst them Verification (VER) and Validation (VAL) which confirm that the requirements are properly reflected and that the delivered product fulfils its intended use.
As illustrated by the CMMI Engineering process category in Figure 1 below, the foundation for construction comprises the Requirements Management (REQM) and Requirements Development (RD) process areas.
The Technical Solution (TS) involves designing and developing solution components according to the requirements. Product Integration (PI) sees the solution components assembled to form an end product ready for delivery. The Verification process area (VER) ensures that each solution component meets its specified requirements, while Validation (VAL) demonstrates that a product fulfills the end user's needs.
|Figure 1. CMMI Engineering Process Areas|
Verification and validation are often confused or considered as a single process area, understandable considering that both are concerned with testing according to requirements.
The principle difference is that Verification proves that components have been built to the specifications developed in RD, implying bottom-up reviewing and testing, while Validation confirms that a product addresses the end user's feature set, implying top-down system testing.
Through adopting CMMI, the specific practices associated with each process area construct a framework of best practices for the project. For example, requirements stipulates the need to manage change of the requirements through the life of the project as well as maintaining bidirectional traceability of requirements to downstream artifacts, while verification states that peer reviews should be carried out for all components.
Furthermore, the process areas interact and must stay synchronized as the project progresses. For example, component requirements developed in requirements development must be managed with the same discipline as the end user's requirement set, meanwhile verification and validation contribute tests and test results to the requirements traceability repository.
The development of a CMMI-inspired process framework is certainly a good start. The needs and goals for a project will now be fairly clear. But how are these needs and goals achieved? What workflow processes will drive the requirements through design, implementation and test? Which tools will automate, support and optimise tasks such as requirements managements and component verification?