NI LabVIEW and CMMI-Compliant Requirements Management

This article is part of a series on software engineering practices and tools for large application development in LabVIEW. Click here to view the list of other articles

LabVIEW developers continue to develop increasingly complex applications that must meet ever shorter deadlines while maintaining quality standards. Quality standard for software development are especially stringent in regulated industries such as medical device manufacturing, aerospace, and defense. Of all the different software development quality standards used in these industries, CMMI has become increasingly popular because of its comprehensiveness and cross-industry application. To achieve different levels of CMMI compliance, the development process of a LabVIEW application must meet a set of development guidelines grouped into process areas. CMMI defines 22 process areas, of which requirements management is one of the most important. Requirements management takes place throughout development and therefore, has far-reaching effects throughout the project. In this paper we will discuss CMMI and explain how to implement the requirements management CMMI process area for LabVIEW applications.

What is CMMI?

In the early 1980s, the U.S. Department of Defense (DOD) led an initiative to improve the quality of the software developed by its contractors. To execute on this initiative, DOD created the Software Engineering Institute at Carnegie Mellon University, which in response developed the Software Capability Maturity Model (CMM®). Other CMMs were released to meet the needs of other areas, such as systems engineers, creating many different models with overlapping functionality. To create a unified development model, the DOD asked Carnegie Mellon to create the Capability Maturity Model Integration (CMMI), which combined three of the most popular existing models into a comprehensive set of development guidelines.

Staged and Continuous Representations of CMMI

CMMI can be used to validate the software development processes for a whole organization, or validate just one process area. The Continuous Representation of CMMI validates an organization’s development processes in one particular process area such as risk management or project planning. In contrast, the Staged Representation of CMMI validates the organization’s overall development process. The Staged Representation has been adopted by many organizations because they can use it to certify their software at a certain CMMI level. Reaching CMMI Level 1, 2, 3, 4, or 5 is a requirement for bidding on and being selected for contracts, especially in the area of defense.

CMMI Maturity Levels

Many of the organizations that seek out CMMI certification look to achieve a certain maturity level across the organizations. The Staged Representation of CMMI consists of five incremental maturity levels. CMMI Level 1 assumes that no formalized process is in place for software development. If there is a process, it is very ad hoc and is not used across different projects. Companies at this level can achieve success in particular projects but at the expense of countless unnecessary hours of work and cost overruns.

CMMI Level 2 seeks to begin the standardization of development process in particular projects. Processes such as requirements management, configuration management, and project planning are implemented in Level 2.  The processes in CMMI Level 2 are the foundation for all subsequent levels and therefore consist mostly of the tactical guidelines for development. Moving on to CMMI Levels 3, 4, and 5, the focus is standardizing the organization on common processes to increase repeatability of success. After processes are standardized, measurement metrics are developed to understand and control the development process more effectively and to facilitate continuous improvement.

CMMI Process Areas

Each of the CMMI maturity levels is reached once all of the process areas for that level are implemented. Process areas are a set of goals and subpractices related under a common category. CMMI Level 2 consists of seven process areas.

1. Requirements Management
2. Configuration Management
3. Measurement and Analysis
4. Project Monitoring and Control
5. Project Planning
6. Process and Product Quality Assurance
7. Supplier Agreement Management

Of these seven process areas, requirements management is set apart because it is important across all stages of a development project and has far-reaching impact if performed incorrectly. Defining the requirements for a LabVIEW application or system can be one of the most challenging parts of the project. Studies have shown that 60 percent of system errors can be attributed to inadequate requirements and design. Furthermore, the Software Engineering Institute who developed CMMI concluded in a research study that the top two factors that contribute to the failure of system development contracts to meet schedules and costs were inadequate requirement specifications and changes in requirements.

To learn more about CMMI and LabVIEW read the whitepaper on  Using LabVIEW in Projects Requiring CMMI Compliance.

LabVIEW Requirements Management for CMMI

The requirements management process area focuses on seeking agreement and understanding on the content of requirements. The process area also seeks to keep track of requirements and their relationships. Being able to meet these goals will be influenced heavily by the format selected for requirement documentation. Small LabVIEW projects might be able to document requirements using text, Microsoft Word, or Adobe Acrobat documents. On the other hand, larger projects should consider requirements management systems such as Telelogic DOORS or IBM Rational RequisitePro. Furthermore, tools for requirement traceability, management, and reporting designed for LabVIEW such as NI Requirements Gateway, will be able to complement the features of all the previously mentioned requirements documentation formats.

CMMI process areas define multiple goals that must be met before the process area is accomplished. The following is a description of the five goals that make up requirements management and how to accomplish them in a LabVIEW development project.

Obtain an Understanding of Requirements

Understanding the meaning of requirements is necessary to guarantee that the specifications defined for a LabVIEW project match what the customer needs. In order to develop requirements that are easy to understand and to avoid requirement creep, the team must establish criteria for the acceptance of requirements. For example, the requirement acceptance criteria could specify requirements to be clearly stated, complete, uniquely identified, and traceable. The list of criteria can be defined by each organization based on their own needs. Once criteria are defined, each new requirement should be tested against the criteria before it is added to the project.

Increased understanding should also come from engaging the requirement providers directly and documenting the requirements with their assistance. The documentation of requirements should also refer to the requirement provider in case any questions arise on the requirement in the future. For example, Figure 1 shows a requirements document where each requirement is clearly documented, allocated to a requirement provider and assigned a unique ID.

[+] Enlarge Image

Figure 1: Correctly formatted and documented requirement document

Maintain Bidirectional Traceability of Requirements

Understanding the relationships between requirements and work products is very important for tracking the implementation of requirements and making informed decisions throughout the project. Requirements are defined at different hierarchical levels. For example, customers might define high-level requirements that are further specified by LabVIEW developers as functional requirements. These functional requirements are used to generate test requirements. If we can maintain bidirectional traceability between requirements, we can understand the significance of a test requirement by navigating to the high-level customer requirement it was meant to cover.

Requirement management products such as Telelogic DOORS and IBM Rational RequisitePro include features that make it easy to maintain traceability between requirements. Requirement traceability can also be accomplished if you are using Word or text files with the use of NI Requirements Gateway.

On the other hand, it is not possible for any of these requirement documentation formats to perform traceability directly to LabVIEW VIs. Tracing requirements to their implementation in LabVIEW is critical to understanding how requirements were implemented and facilitates the generation of requirement coverage documentation such as requirements traceability matrices. NI Requirements Gateway is able to trace requirements stored in many different requirement documentation formats to LabVIEW and other NI software as seen in Figure 2.

Figure 2: NI Requirements Gateway can display traceability between requirements and features in a VI

To evaluate NI Requirements Gateway  Download your FREE NI Requirements Gateway Evaluation Software.

Identify Inconsistencies between Project Work and Requirements

One of the biggest benefits of maintaining bidirectional traceability between requirements and work products is that it helps find inconsistencies between project work and requirements. A LabVIEW application can be robust, scalable, and work perfectly but not meet any of the customer’s requirements. Of course this is an extreme example, but brought to a more realistic level, certain functionality in a LabVIEW application can execute without any errors but still not be what the customer is looking for. For this reason, it’s important to find these inconsistencies between LabVIEW applications and requirements, document the rationale for the inconsistency, and initiate corrective action as part of requirement management.

Identifying inconsistencies between project work and requirements can prove to be very time-consuming. You will need to evaluate all requirements and, with the help of all developers, determine when and where the requirements are implemented. On the other hand, you can document your LabVIEW code to describe which requirements are covered by each VI, control, indicator, etc. NI Requirements Gateway can read this requirement coverage information and trace it to requirements, facilitating the process of finding these inconsistencies through coverage analysis.  Figure 3 demonstrates the coverage analysis feature in NI Requirements Gateway which facilitates determining how requirements are implemented.

[+] Enlarge Image

Figure 3: NI Requirements Gateway Coverage Analysis View demonstrating how requirements are implemented

For more information on NI Requirements Gateway read the whitepaper  NI Requirements Gateway for Test, Measurement, and Control Applications.

Manage Requirements Changes

Identifying inconsistencies between requirements and LabVIEW code can be even more challenging if your requirements are a constantly moving target. Keeping track of changes to requirements is critical to guaranteeing that project work is consistent with specifications and understanding the progress of a project.  The first step before we even change a requirement is to evaluate the impact on the project stakeholders.  Requirement traceability provides a useful framework for understanding the impact of a requirement change.  If a requirement needs to be changed we can use traceability relationships to understand what high level requirements will be affected and what work products will need to change.  The Impact Analysis View in NI Requirements Gateway can trace multiple levels, facilitating the understanding of the impact of a requirement change.

Requirements traceability also facilitates understanding the impact of a requirement changes by helping you identity who stakeholders are.  Stakeholders may be more than just the developers or managers in the project. To effectively understand the impact of a requirement change, you should look at its effect on customers, suppliers, and other parties related to the project.  These different parties should be documented as sources of requirements in the requirements documentation which can navigated with requirement management tools.

After understanding the impact of a requirement change, all changes must be documented along with the rationale for each of these changes. This information should be communicated to all participants in the project so that time is not wasted working on features that have been changed or removed from the project specifications.

Obtain Commitment to Requirements

While managing requirement changes focuses on effectively understanding and communicating changes to the all parties in the project, obtaining commitment to requirements deals with achieving the buy-in of these parties. As requirements are generated at the beginning of a project or changed during the projects execution, all parties need to commit to their implementation. Commitment is achieved by involving as many people as necessary in the definition of requirements. If participants see that their feedback and ideas are part of the project they will feel more ownership over the specifications. Furthermore, by being involved in the discussions for the requirements, project participants better understand the rationale behind each requirement. Once requirements are defined and accepted, ownership of each requirement should be assigned to a project member. This ownership should be clearly documented for future reference.

Summary

CMMI was originally developed by DOD to increase the quality of software developed by its contractors. CMMI maturity levels are accomplished once all process areas at a particular level are implemented. CMMI Level 2 sets the foundation for all the rest of the maturity levels and therefore needs to be implemented first. Of all the process areas in CMMI Level 2, requirements management is one of the most important because of its influence throughout the whole project. CMMI requirements management can be accomplished for LabVIEW applications and streamlined with the help of requirement management and traceability tools such as NI Requirements Gateway.

For more information on requirements management and NI Requirements Gateway view the webcast  Requirements Management and Traceability with LabVIEW and NI Requirements Gateway.

Reader Comments | Submit a comment »