Section 6.8. Engineering Process Areas

6.8. Engineering Process Areas

The following sections detail the Process Areas specific to engineering.

6.8.1. Requirements Management

If the IT industry as a whole were asked to isolate one activity that led to more problems than any other, it would probably be requirements management. Poor requirementsincomplete, inconsistent, ill-expressedhave been known to derail a project faster than almost anything else. Without sound requirements, a project operates in an amorphous world where nothing can be fixed, where no quality mark can be set. Therefore, sound requirementsat least a baseline of sound requirementsshould be in place before you embark on any development effort.^[*] It's a critical path item for project success. It's not hard to see why. If your project team has no methods or tools for managing requirements, no degree of effective oversight or engineering talent will keep a project on its rails. The tracks have been greased for slipperiness from start to finish. Requirements Management then is an essential characteristic of any quality model.

^[*] The term requirements can refer to any form of scope definition. Here we most often think of the functional requirements that stipulate how a system should operate. But before that, there had to be some form of requirements to generate those requirementsperhaps module descriptions. And before that, there needed to be requirements for what modules an application of a certain kind should possessperhaps a business vision. The point is, a reliable starting marksomething that describes what the end should look likeis always needed to reach that end.

At its core, Requirements Management is a control technique that should be adopted as early as possible in a project's life cycle. Because it recognizes that people change their minds, that business rules fluctuate, that no one thinks of everything at once, requirements management serves as a facility to handle change in a manner that promotes the clean intake of requirements, their smooth integration into project plans, and their eventual evolution across project phases.

6.8.1.1. One specific goal

CMMI defines one basic goal for Requirements Management: that requirements are managed. By this, the spec implies five common practices, each one leading from and building on the other:

1. The engineering team should have the opportunity to review the requirements prior to adopting them. In other words, the team should get the chance to understand the requirements before committing to their implementation.

2. The project team, including relevant stakeholders, should formally approve the agreed-upon requirements as a group, establishing a common base of understanding.

3. Once approved, the requirements should be tracked and monitored to maintain their consistency with project plans and work products across the life of the project.

4. Traceability should be established in order to verify that the proper requirements have been incorporated into the proper functioning components and work products of the system.

5. If inconsistencies are discovered between the requirements and their work products, corrective action should be taken to realign the two.

6.8.1.2. Core Requirements Management actions

The team agrees to a core set of requirements and then actively tracks and monitors their evolution across every phase of the project.

Applies to Engineering:

• Systems Engineering

• Software Engineering

• Integrated Product and Process Development

Figure 6-7 illustrates the Requirements Management PA.

Figure 6-7. Requirements Management is focused on how requirements are reviewed, approved, and baselined for project work. This includes obtaining an understanding of the requirements, obtaining commitment to the requirements prior to work, tracking changes to requirements, and keeping requirements and work products consistent with each other.

6.8.2. Requirements Development

Requirements Development is the logical "pre-extension" of Requirements Management. It deepens Requirements Management, a technology-engineering task, by linking it with a primary systems-engineering task, the development of the requirements. In the CMMI model, Requirements Development is concerned with producing requirements through interactions with customers and then analyzing those requirements to validate their completeness.

Developing requirements is a big job any way you look at it. And CMMI doesn't describe in detail just how the job should be done. It outlines at a high level the tasks of stakeholder coordination, elicitation, documentation, verification, and communication. Its main concern is that requirements development is conducted through a set process, a process composed of defined steps. The use of process is especially important here: requirements development is a notoriously intuitive regimen. By its nature, it's in the business of translation, and translation is always open to misinterpretation and missing detail. A process won't make the regimen perfect, but it will give your people an arena to operate in that promotes consistency and thoroughness, and it will foster mechanisms for feedback and review. With those kinds of elements in place, your Requirements Development effort should become cleaner and cleaner over time.

6.8.2.1. Three specific goals

CMMI identifies three goals within the Requirements Development Process Area:

1. Develop customer requirements. Customer requirements are those requirements that define the customers' (and relevant stakeholders') expectations of the system. These requirements usually deal with fulfilling specific business and performance needs. The job of your analystsand usually this is an iterative jobis to elicit these needs and then document the customer requirements based on them.

2. Develop product requirements. Product requirements are usually a finer, more detailed set of requirements that work to realize the customer requirements through more technical descriptions. This step includes defining the product makeup and its constituent components and then allocating requirements to these components and their linking interfaces.

3. Analyze and validate the requirements. This step calls for your analysts to organize the documented requirements into operational concepts and scenarios, extract and map the resulting functionality, prioritize the functionality, and then validate that this functionality meets the business and performance expectations of the customer.

6.8.2.2. Core Requirements Development actions

Your business analysts work with customers and other selected stakeholders to elicit and document customer requirements and product requirements. These requirements are then analyzed for completeness, suitability, and viability.

Applies to Engineering:

• Systems Engineering

• Software Engineering

• Integrated Product and Process Development

Figure 6-8 illustrates the Requirements Development PA.

Figure 6-8. Requirements Development deals with the elicitation, composition, and analysis of requirements. The activities provide structure for tasks to develop customer requirements, develop product component requirements and any interfaces needed to link the components, and develop methods for prioritizing and balancing requirements across the project life cycle.

6.8.3. Technical Solution

Technical Solution is designed to provide the organization with guidelines for determining the technical direction of a project, then organizing and implementing an appropriate design. This Process Area is in many ways an extension of the two Requirements Process Areas: Requirements Management and Requirements Development. Those Process Areas provide means for eliciting, documenting, and managing the requirements that form the basis of a development project. They can be thought of (if you prefer to think of these Engineering PAs in a traditional SDLC order) as the first two Process Areas of CMMI. The Technical Solution PA moves you from requirements to design.

Here the model makes recommendations for evaluating, organizing, and implementing an appropriate design for the project. The focus is on finding the right technical solution, one that makes sense based on the needs of the project as a whole and on the different subcomponents of the project.

6.8.3.1. Three specific goals

This Process Area comes with three specific goals:

1. Select the right product-component solution (or solutions). This first goal provides guidelines for investigating the best architectural path to apply to the project. This involves developing alternate solutions against criteria of the performance and technical capabilities of the organization, and then examining the requirements to determine which available solution fits best. Many IT organizations are tempted to simply apply a solution that fits their current strengths, such as "We're a .NET shop" or "We do Java better than anyone" or "MQ Series can handle anything." The practice specified here encourages a more considered approach. It gives you and your development team a mechanism to formally hunt for the best technical solution for the project.

2. Develop the designs for the solution. This goal sets guidelines for creating the overall design (and any necessary subcomponent designs) based on the architectural solution established through Goal 1. This includes establishing the technical tools and resources needed, defining the product components in detail, and defining and detailing any interfaces that will be needed to link the components together.

3. Implement the designs across the project. This third goal carries out the defined activity in Goal 2. You create the design according to the specifications you defined for it and implement it in an appropriate way (i.e., coding the solution). In addition, the team develops the supporting documentation (here called a technical data package) required to support the implementation of the design.

6.8.3.2. Core Technical Solution actions

The project team uses the requirements as a base for determining and implementing an appropriate product design, one that accounts for all product components and interfaces. This is based on evaluations of viable alternatives, as well as on the technical capabilities of the organization. The designs are then implemented.

Applies to Engineering:

• Systems Engineering

• Software Engineering

• Integrated Product and Process Development

Figure 6-9 illustrates the Technical Solution PA.

Figure 6-9. Technical Solution contains practices for deriving the right technical solution for a project, and then implementing an appropriate design based on the solution. This Process Area also includes implementing the design (through coding, construction, etc.) and establishing a technical data package to support the design.

6.8.4. Product Integration

Product Integration is concerned with the gradual, prescribed assembly and delivery of the developed product along with its accompanying materials. This Process Area is related to Configuration Management (discussed later under "Support Process Areas") in that it deals with how configured components are linked, compiled, and assembled for delivery. It is also related to Validation (discussed later in this section), in that what are being validated are the final integrated components. The purpose of Product Integration is to ensure that a method is in place that provides for the orderly assembly of what can often be many product subcomponents, often at different life-cycle phases. Additionally, Product Integration exists to provide a mechanism to determine whether the assembled subcomponents function properly before they are released as an integrated whole. In general, the process of Product Integration is one of planning, confirming, assembling, andfinallydelivering.

6.8.4.1. Three specific goals

CMMI provides three goals for Product Integration:

1. Prepare for Product Integration. This is a planning and documentation process, one that deals with how you'll plan and define the process that maps out how the product components fit together. Here the engineering staff defines the product's components, the sequence in which they should be integrated, the configuration of the integration environment (what's needed to fit the pieces together), and the criteria to use to determine if the assembly (the integration) has been successful.

2. Ensure interface compatibility. This goal is designed to account for the various interfaces that link project components into an integrated whole. This part of the integration process should include a definition of the interfaces and how they fit together. This is important because interfaces have a tendency to be overlooked from time to time, the focus being on the major product parts. But interfacesbecause they too can change and evolve over time as the product developsneed to be given the same attention and focus on integration.

3. Assemble the defined components and deliver the product. This step includes confirming that the components are ready to be integratedthat they have reached that final phase of developmentthen assembling the components using the criteria and procedures you have developed, verifying that the resulting product is operational, and then delivering the assembled product with relevant supporting material to the customer.

6.8.4.2. Core Product Integration actions

The engineering team devises a coordinated method for linking all components and interfaces of a product into an integrated whole, one suitable for delivery to the customer. The team then assembles the product following this method and delivers the product to the customer.

Applies to Engineering:

• Systems Engineering

• Software Engineering

• Integrated Product and Process Development

Figure 6-10 illustrates the Product Integration PA.

Figure 6-10. Product Integration is often seen as the next step following Technical Solution. The practices contained in this Process Area focus on defining how the product components should be assembled, what the integration environment should be, and what the assembly procedures should address. Interface management is another aspect of Product Integration. Interfaces should be regularly managed to be kept current with the components being assembled.

6.8.5. Verification

The purpose of this Process Area is to ensure that selected work products produced across the project life cycle have been developed according to appropriate requirements, standards, and formats. Verification can be thought of as an extension of the Process and Product Quality Assurance Process Area (discussed later under "Support Process Areas"). But (as you'll see) while PPQA is an independent, "external" quality-compliance component, Verification is internal to the project team. Verification is typically implemented in phases across the project, usually at selected milestones and in the form of quality gates. This Process Area serves its most effective use as a means for accomplishing the smooth transition of work products from one team to another, on through product delivery. We typically think of Verification in terms of peer reviews and functional tests. Here, peer groups are organized to conduct product inspections, comment on their quality and completeness, and approve their downstream transition. And like teams are formed to put product components through tests to verify compliance with requirements.

6.8.5.1. Three specific goals

The Verification Process Area has three goals under CMMI:

1. Prepare for Verification. This is the planning phase for this Process Area. It usually occurs (and probably should occur) prior to project execution. Here you definefor the full length of the projectwhat work products will be subject to the verification process. Then you define what inspection criteria you'll use to verify these key work products and product components. For example, you might define the format, structure, and contents of what you'd expect to see in an acceptable design document. This will then serve as the basis for evaluating that document later in the project.

2. Perform peer reviews. This is an oversight facet of the verification process. Peer reviews are an exercise in which members of the project teams inspect and evaluate each other's work to ensure that it is ready to move on in the production process. For this goal, material is organized for each peer review, peer teams are identified, inspections are conducted, and resulting recommendations are analyzed for any further actions deemed appropriate.

3. Verify the selected work products. This is the closing step of Verification. Here, selected follow-up recommendations that arose out of the peer review may be acted on. Additionally, major work products and product components are subjected to the robust verification evaluations planned for in Goal 1. (The classic form of this is system and regression testing.) The result should be products that pass verification criteria and are ready to move on into further project activity, or perhaps on to Product Integration actions.

6.8.5.2. Core Verification actions

The project team inspects selected work products based on preset criteria (i.e., appropriate requirements, content, format, and standards). Products that fall outside of these criteria are reworked before moving along the project life cycle.

Applies to Engineering:

• Systems Engineering

• Software Engineering

• Integrated Product and Process Development

Figure 6-11 illustrates the Verification PA.

Figure 6-11. Verification is often thought of as "test," but it includes more than that. It contains activities that help ensure that the product components truly reflect the requirements given to the project team. This involves establishing verification environments and procedures, performing peer reviews, and then executing verification activities as planned.

6.8.6. Validation

The Validation Process Area presents a method for ensuring that a developed product operates in its intended environment according to performance expectations. This Process Area is related to Verification and might be seen as the end point in the Verification line. Validation is concerned with the delivery and deployment of the product, but it should take place well before deployment. The process of validation works best when conducted using, as close as possible, the operational environment intended for the product in the field. The overall intention of validation is to confirm that the product will work in the field as the customer first envisioned.

6.8.6.1. Two specific goals

Two goals exist for Validation. The structure is very similar to that of Verification.

1. Prepare for Validation. This is the planning phase for this Process Area. Here the team selects the products that will be put through validation exercises. Then the team identifies the proper configuration that will be needed to replicate the field environment and, based on that, defines what tests and exercises will be required to confirm that the product operates in the intended environment in the intended way.

2. Validate the product and its product components. Here the validation plan is executed, and the results are analyzed. Based on this analysis, the product may be deemed suitable for production, or it (or some of its components) may be returned to the engineering process for refinement.

6.8.6.2. Core Validation actions

Selected products (or components) are exercised and evaluated in production-like environments to ensure that they meet operational and performance field expectations.

Applies to Engineering:

• Systems Engineering

• Software Engineering

• Integrated Product and Process Development

Figure 6-12 illustrates the Validation PA.

Figure 6-12. Validation sets into place activities to help ensure that the product built by the project team will operate properly in its intended environment. The activities defined here include defining the validation environment, establishing validation procedures and criteria, performing validation tasks as defined, and analyzing the results of the validation activities.

Quick Take

Engineering Process Areas

The Process Areas (PAs) that deal with engineering under CMMI are focused on establishing workable requirements, developing appropriate solutions, assembling components into an integrated whole, verifying product features, and validating product performance. Here's a brief recount of the six Process Areas:

For Maturity Level 2:

Requirements Management (REQM)

This Process Area has one goal: manage requirements in a way that ensures consistency and control, and then allows for tracking and tracing over the life of the project.

For Maturity Level 3:

Requirements Development (RD)

Three goals are defined here: elicit customer requirements, develop appropriate product requirements based on the customer requirements, and analyze and validate the requirements to establish order, relationships, and priorities.

Technical Solution (TS)

Three goals are defined for this PA: evaluate alternatives to select the best technical solution for the project, develop a design that accounts for the proper product components and interfaces, and implement the solution based on the technical approach and the design.

Product Integration (PI)

Product Integration has three goals: prepare for Product Integration by defining how the product components and interfaces will need to be assembled, ensure that interface specifications and versions remain compatible as product components evolve, and assemble and deliver the product according to the criteria and instructions you've developed.

Verification (VER)

Three goals define this PA: prepare for Verification by defining inspection criteria for the different work products you will need to verify, perform peer reviews on selected work products as they move through the production process, and perform verification on key work products prior to integrating them into deliverable components.

Validation (VAL)

Validation has two goals: prepare for Validation by establishing validation procedures and defining the proper validation environment; and perform validation based on the procedures and the predefined environment configuration.