How to use CMMI for Systems Engineering

CMMI as an organisational model was created at Carnegie Mellon University by a group of specialists from the Software Engineering Institute.  

Systems Engineering is one of the 4 areas supported in the Capability Maturity Model Integration (CMMI). The domain covers designing and developing complete systems that may or may not include software and focuses on translating the initial requirements into product solutions and makes sure that these solutions are supported throughout the whole development process.  

The following 6 process areas are used for Engineering, including Systems Engineering: 

Requirements Management 

If there are any inconsistencies in between the product requirements and the project workflow and roadmap, these can be reassessed and settled at the Requirements Management stage. This includes both technical and non-technical requirements.  

This stage is not a one-off activity – with the requirements changing throughout the product development process, it may be necessary to regularly check how they interact with other elements of the project and adjust them accordingly. 

The process area of CMMI also has one specific goal and a few generic goals as follows: 

SG 1: Manage Requirements 

‘Requirements are managed and inconsistencies with project plans and work products are identified.’ 

GG 1: Achieve specific goals 

‘The process supports and enables achievement of the specific goals of the process area by transforming identifiable input work products to produce identifiable output work products.’ 

GG 2: Institutionalize a Managed Process  

‘The process is institutionalized as a managed process.’ 

GG 3: Institutionalize a Defined Process  

‘The process is institutionalized as a defined process.’ 

GG 4: Institutionalize a Quantitatively Managed Process  

‘The process is institutionalized as a quantitatively managed process.’  

GG 5: Institutionalize an Optimizing Process  

‘The process is institutionalized as an optimizing process.’  

The CMMI then lists steps for achieving all of these goals – check this ebook for more information. 

Requirements Development 

Here’s where the requirements collected in the previous phase are analysed and developed. There are 3 groups of practices focused on these activities.  

The first group will be used as a basis for product design and is as follows: 

• collection and coordination of stakeholder needs,
  development of the life-cycle requirements of the product, 

• establishment of the customer requirements, 
• establishment of initial product and product component requirements consistent with customer requirements, 
• elicitation, analysis, and communication of customer needs,
  expectations, and constraints to obtain customer requirements that
  constitute an understanding of what will satisfy stakeholders. 

Then there’s the second group centred around analysing the requirements, especially the customer requirements. This list of actions includes: 

• analysis of needs and requirements, 

• development of an operational concept, 
• definition of the required functionality, 
• development of manufacturing and support concepts to address
  cost and affordability. 

This segment of activities is strongly connected with the third group where results of the analysis are presented as a list of: 

• constraints of various types, 
• technological limitations, 
• cost and cost drivers, 
• time constraints and schedule drivers, 
• risks, 
• consideration of issues implied but not explicitly stated by the
  customer or end-user, 
• factors introduced by the developer’s unique business
  considerations, regulations and laws. 

The Requirements Development phase also has its list of 3 specific goals and generic goals with step-by-step descriptions on how to achieve these. These lists of goals include: 

SG 1: Develop Customer Requirements  

‘Stakeholder needs, expectations, constraints, and interfaces are collected and translated into customer requirements.’ 

SG 2: Develop Product Requirements  

‘Customer requirements are refined and elaborated to develop product and product component requirements for the product life cycle.’  

SG 3: Analyze and Validate Requirements  

‘The requirements are analyzed and validated, and a definition of required functionality is developed.’  

GG1: Achieve Specific Goals  

‘The process supports and enables achievement of the specific goals of the process area by transforming identifiable input work products to produce identifiable output work products.’ 

GG 2: Institutionalize a Managed Process 

‘The process is institutionalized as a managed process.’ 

GG 3: Institutionalize a Defined Process 

‘The process is institutionalized as a defined process.’ 

GG 4: Institutionalize a Quantitatively Managed Process 

‘The process is institutionalized as a quantitatively managed process.’ 

GG 5: Institutionalize an Optimizing Process 

‘The process is institutionalized as an optimizing process.’ 

Technical Solution 

Next stage of the process is all about designing, developing and implementing solutions to the requirements established in the last 2 phases. It’s important to remember that the design, development and implementation are connected, and they may impact each other directly or indirectly. On an organisational level, the requirements may change over time – this will also mean that further iterations of the already implemented solutions may be necessary. 

Thanks to the traceability of the requirements established in the previous stage, any of these iterations will be easy to track and document. 

As it was with the last two stages, this stage also has specific and generic goals and step-by-step instructions on how to achieve these >>> CMMI Process Areas. 

SG 1: Select Product Component Solutions 

‘Product or product component solutions, including applicable product related processes, are selected from alternative solutions.’ 

SG 2: Develop the Design 

‘Product or product component designs are developed.’ 

SG 3: Implement the Product Design 

‘Product components, and associated support documentation, are implemented from their designs.’ 

GG 1: Achieve Specific Goals 

‘The process supports and enables achievement of the specific goals of the process area by transforming identifiable input work products to produce identifiable output work products.’ 

GG 2: Institutionalize a Managed Process 

‘The process is institutionalized as a managed process.’ 

GG 3: Institutionalize a Defined Process 

‘The process is institutionalized as a defined process.’ 

GG 4: Institutionalize a Quantitatively Managed Process 

The process is institutionalized as a quantitatively managed process. 

GG 5: Institutionalize an Optimizing Process 

‘The process is institutionalized as an optimizing process.’ 

Product Integration 

After the designs and solutions are ready, it’s time to assembly the product from the existing components and fill any gaps that have not been covered by the requirements and the solutions. This is also where the product is tested and assessed as integrated and fully functional. With these steps completed, the product can be then delivered to any stakeholders, including the customers. 

If you operate in the Systems Engineering domain, your final product will be a system, with all of its elements included, tested and released. Your responsibility will also be ensuring the consistency of all designs.  

Please note that the product integration stage can be completed iteratively and is not – in any case – a one-off process of assembling all assets. Work with prototypes and make sure that they get more advanced as you approach the release. 

As always, in the CMMI this stage is also completed with 2 list of goals (specific and generic). 

SG 1: Prepare for Product Integration 

‘The strategy for conducting product integration is established and maintained.’ 

SG 2: Ensure Interface Compatibility 

‘The product component interfaces, both internal and external, are compatible.’ 

SG 3: Assemble Product Components and Deliver the Product 

‘Verified product components are assembled and integrated, verified, and validated product is delivered.’ 

GG 1: Achieve Specific Goals 

‘The process supports and enables achievement of the specific goals of the process area by transforming identifiable input work products to produce identifiable output work products.’ 

GG 2: Institutionalize a Managed Process 

‘The process is institutionalized as a managed process.’ 

GG 3: Institutionalize a Defined Process 

‘The process is institutionalized as a defined process.’ 

GG 4: Institutionalize a Quantitatively Managed Process 

‘The process is institutionalized as a quantitatively managed process.’ 

GG 5: Institutionalize an Optimizing Process 

‘The process is institutionalized as an optimizing process.’

Verification 

Once the product or system is deployed, you need to move to the verification stage. The purpose of this phase is to ensure that the final result meets the specified requirements from both project and customer side. You may also need to take any corrective actions if the verification turns out to be unsatisfactory.  

While on the surface, verification and validation (see the next stage) may seem similar, there are – in fact – two different activities. Verifying the product assess whether it’s viable and complete from the requirements point of view. Validating it is all about ensuring that the product will fullfil its function and is in fact, what was necessary for a particular task. 

Check below for a list of specific and general goals and follow the link for more information on how to reach them.

SG 1: Assemble Product Components and Deliver the Product 

‘Verified product components are assembled and the integrated, verified, and
validated product is delivered’.

GG 1: Achieve Specific Goals 

‘The process supports and enables achievement of the specific goals of the process area by transforming identifiable input work products to produce identifiable output work products.’ 

GG 2: Institutionalize a Managed Process 

‘The process is institutionalized as a managed process.’ 

GG 3: Institutionalize a Defined Process 

‘The process is institutionalized as a defined process.’ 

GG 4: Institutionalize a Quantitatively Managed Process 

‘The process is institutionalized as a quantitatively managed process.’ 

GG 5: Institutionalize an Optimizing Process 

‘The process is institutionalized as an optimizing process.’ 

Validation 

As mentioned above, the validation process focuses on whether the product can address its intended use – in short, whether it will do what it was created to do. What is important in this phase is that this full functionality needs to be achieved in the intended environment. 

As it is with the verification, the validation also follows through on i.a. testing, analysis and simulation, so these two processes may be using the same environment or even be conducted in parallel, at the same time. Any issues that will be discovered at this stage need to be addressed accordingly with corrective actions taken immediately. 

Here’s a list of specific and generic goals for this stage below: 

SG 1: Prepare for Verification 

‘Preparation for verification is conducted.’ 

SG 2: Perform Peer Reviews 

‘Peer reviews are performed on selected work products.’ 

SG 3: Verify Selected Work Products 

‘Selected work products are verified against their specified requirements.’ 

GG 1: Achieve Specific Goals 

‘The process supports and enables achievement of the specific goals of the process area by transforming identifiable input work products to produce identifiable output work products.’ 

GG 2: Institutionalize a Managed Process 

‘The process is institutionalized as a managed process.’ 

GG 3: Institutionalize a Defined Process 

‘The process is institutionalized as a defined process.’ 

GG 4: Institutionalize a Quantitatively Managed Process 

‘The process is institutionalized as a quantitatively managed process.’ 

GG 5: Institutionalize an Optimizing Process 

‘The process is institutionalized as an optimizing process.’ 

Read this ebook about CMMI process areas for more information.

Using the CMMI model for systems engineering 

Traditionally, the systems engineering domain is heavily based on the V-model with certain processes grouped into 3 categories:  

• Primary Life Cycle Processes (Acquisition Process Group, Supply Process Group, System Engineering Process Group, Software Engineering Process Group, Cybersecurity Engineering Process Group),  
• Organisational Life Cycle Processes (Management Process Group, Reuse Process Group, Process Improvement Process Group), 
• Supporting Life Cycle Processes (Supporting Process Group). 

While this model of work is still viable when using CMMI, the workflow itself is managed differently and on an organisational rather than a process level. Where in the V-model includes elements such as ‘system architecture’, ‘system requirements’, ‘structure architecture’ and ‘structure requirements’, in the CMMI there’s ‘high-level design’ and ‘low-level design’.  

This will be especially important if you need to combine the CMMI with any other processes and model that your organisation may already be using, including the V-model mentioned above and ASPICE. 

Check this article to find out how V-model and ASPICE can be used in conjunction to strengthen the cybersecurity efforts >>> Cybersecurity as a plugin into ASPICE and V-model

Over to you 

If you need any support when introducing the CMMI model/workflow to your organisation, then please do not hesitate to contact our Automotive team for more information >>> Automotive Safety at Spyrosoft