INCOSE Presentation San Francisco Chapter 13 October 2009 Mapping CMMI to Systems Engineering Adrienne Friedman

Mapping the Capability Maturity Model Integration (CMMI) for Development, V 1.2 to System Engineering Requirements

Agenda n Working definitions l What is the CMMI? l What is INCOSE? l What is Systems Engineering? n CMMI Process categories n CMMI-DEV V1.2 Process Areas Handout n INCOSE Process Categories n INCOSE Handbook 3.1 SE Overview n CMMI Requirements Management (REQM) compared to INCOSE Requirements Analysis n CMMI Requirements Development (RD) compared to INCOSE Requirements Definition n Stakeholder benefits: Requirements n Summary

What is the CMMI? n CMMI is a process improvement approach that provides organizations with the essential elements of effective processes that ultimately improve their performance. n CMMI can be used to guide process improvement across a project, a division, or an entire organization. l Integrates traditionally separate organizational functions l Sets process improvement goals and priorities l Provide guidance for quality processes l Provides a point of reference for appraising current processes.

Purpose of INCOSE n To define the discipline and practice of Systems Engineering (SE) for student and practicing professional alike n To provide an authoritative reference to understand the discipline of SE in terms of content and practice

Definition of Systems Engineering n Systems engineering is a discipline that concentrates on the design and application of the whole (system) as distinct from the parts. It involves looking at a problem in its entirety, taking into account all the facets and all the variables and relating the social to the technical aspect. (Ramo) n Systems engineering is an iterative process of top-down synthesis, development, and operation of a real-world system that satisfies, in a near optimal manner, the full range of requirements for the system. (Eisner) n Systems engineering is an interdisciplinary approach and means to enable the realization of successful systems. (INCOSE) Systems thinking focuses on awareness of wholes and how the parts within those wholes interrelate.

CMMI Process categories PROCESS MANAGEMENT (PCM) ENGINEERING (ENG) PROJECT MANAGEMENT (PJM) SUPPORT (SUP)

CMMI-DEV V1.2 Process Areas by Category Presentation focus area

INCOSE SE Process categories Enterprise Processes Technical Processes PROJECT Processes Agreement Processes PROCESS MANAGEMENT (PCM) ENGINEERING (ENG) PROJECT MANAGEMENT (PJM) SUPPORT (SUP)

Figure 1-1 System Life Cycle Processes Overview per ISO/IEC INCOSE Handbook SE Overview ENTERPRISE PROCESSES Enterprise Environment Management Investment Management Resource Management Quality Management Acquisition Supply AGREEMENT PROCESSES Enterprise Environment Management Investment Management Resource Management Quality Management Enterprise Environment Management Investment Management Investment Management Resource Management Resource Management Quality Management Quality Management Risk Management Configuration Management Information Management PlanningAssessmentControl Decision-making Risk Management Configuration Management Information Management PlanningAssessmentControl Decision-making Risk Management Risk Management Configuration Management Configuration Management Information Management Information Management Planning Assessment Control Decision-making Decision - Making Disposal Maintenance Operation Validation TransitionVerification Requirements Analysis Architectural Design Stakeholder Requirements Definition ImplementationIntegration Disposal Maintenance Operation Maintenance Operation Validation TransitionVerification Validation Transition Verification Requirements Analysis Architectural Design Stakeholder Requirements Definition Requirements Analysis Requirements Analysis Architectural Design Architectural Design Stakeholder Requirements Definition Stakeholder Requirements Definition Implementation Integration Implementation Integration TECHNICAL PROCESSES PROJECT PROCESSES Acquisition Supply System Life Cycle Processes Management System Life Cycle Processes Management System Life Cycle Processes Management Process Guidelines Presentation Focus Area

Process Areas CMMI Engineering ENGINEERING (ENG) Requirements Management (REQM) Requirements Development (RD) Technical Solution (TS) => Product Integration (PI) Verification (VER) Validation (VAL) <= Presentation Focus Engineering portion of CMMI Systems Engineering approach to Requirements Management and Requirements Development CMMI Systems Engineering

PPQA 2 MA 2 CM 2 DAR 3 CAR 5 OPF 3 OPD 3 OT 3 TS 3 PI 3 VER 3 VAL 3 SAM 2 OPP 4 OID 5 REQM 2 PP 2 PMC 2 IPM 3 RSKM 3 QPM 4 RD 3 Process Areas and Specific Goals in Engineering Requirements Management (REQM) Requirements Management (REQM) SG1Requirements are managed and inconsistencies with project plans and work products are identified. Requirements Management (REQM) SG1Requirements are managed and inconsistencies with project plans and work products are identified.

CMMI Requirements Development (REQM) CMMI SectionSpecific Goal Description Specific Processes SG1 Manage Requirements Requirements are managed and inconsistencies with project plans and work products are identified SP 1.1 Obtain an understanding of Requirements SP 1.2 Obtain Commitment to requirements SP 1.3 Manage requirements creep SP 1.4 Maintain Bi-directional traceability of requirements SP 1.5 Identify inconsistencies between Project Plans and the work products and requirements Controlling changes ensures that project members and customers have a clear and shared understanding of the requirements It is important to identify when requirements volatility occurs so appropriate action can be taken. High volatility makes it difficult for projects to progress. Plans must be adjusted accordingly Bi-directional traceability can cover traces to work products & demonstrates where & how each requirement is met

Requirements Analysis Process 14 Figure 4-3 Context Diagram for Requirements Analysis Process Controls - Natural and societal laws - Project procedures & processes - Define functional boundary - Define performance requirements - Identify architectural constraints - Define non-functional requirements - Maintain traceability and baseline integrity Activities Outputs - Functional and non- functional Requirements - Performance Requirements - Architectural constraints - Updated RVTM - Verification strategy and criteria - Stakeholder requirements - System Solution Constraints - Requirements Verification & Traceability Matrix (RVTM) Inputs Enablers - Enterprise Infrastructure - Enterprise Policies, Processes, & Standards

PPQA 2 MA 2 CM 2 DAR 3 CAR 5 OPF 3 OPD 3 OT 3 TS 3 PI 3 VER 3 VAL 3 SAM 2 OPP 4 OID 5 REQM 2 PP 2 PMC 2 IPM 3 RSKM 3 QPM 4 RD 3 Engineering Requirements Development (RD) SG1Stakeholder needs, expectations, constraints, and interfaces are collected and translated into customer requirements. SG2Customer requirements are refined and elaborated to develop product and product-component requirements. SG3The requirements are analyzed and validated, and a definition of required functionality is developed. Requirements Development (RD) SG1Stakeholder needs, expectations, constraints, and interfaces are collected and translated into customer requirements. SG2Customer requirements are refined and elaborated to develop product and product-component requirements. SG3The requirements are analyzed and validated, and a definition of required functionality is developed. Process Areas and Specific Goals in Engineering Requirements Development (RD)

CMMI Requirements Development (RD) CMMI SectionSpecific Goal Description Specific Processes SG1 Develop Customer Requirements Stakeholder needs, expectations, constraints, and interfaces are collected and translated into customer requirements. SP 1.1 Elicit Needs SP 1.2 Develop customer Requirements SG2 Develop Product Requirements Customer requirements are refined and elaborated to develop product and product- component requirements. SP 2.1 Establish Product and Product Component Requirement SP 2.2 Allocate Product Component Requirements SP 2.3 Identify Interface Requirements SG3 Analyze and Validate Requirements The requirements are analyzed and validated, and a definition of required functionality is developed. SP 3.1 Establish Operational Concepts and Scenarios SP 3.2 Establish Definition of Required Functionality SP 3.3 Analyze Requirements SP 3.4 Analyze Requirements to achieve balance SP 3.5 Validate Requirements Customer needs are communicated informally in documents, conversations and meetings and must be translated into agreed upon requirements Product component requirements are developed recursively in parallel with recursive product development Requirements must be analyzed to ensure they are necessary and sufficient. Resulting products must perform in the users environment

Stakeholder Requirements Definition Process 17 Enablers - Enterprise Infrastructure - Enterprise Policies, Processes, & Standards - System solution constraints -Traceability Matrix -Validation criteria -Concept documents Outputs - System solution constraints - Requirements Verification & Traceability Matrix - Validation criteria - Concept documents - Stakeholders needs - Project Constraints Inputs Activities - Identify legitimate stakeholders - Elicit requirements - Define constraints - Build scenarios and concept documents - Resolve requirements problems - Confirm and record requirements - Establish and maintain traceability - Agreements - Project procedures & processes Controls Figure 4-2 Context Diagram for Stakeholder Requirements Definition Process

Stakeholder benefits: Requirements Dion, DIO1 McConnell, MCC1 Davis, DAV1, Novorita, NOV1 - 66% to 55% TYPES OF REQ'TS ERRORS Incorrect fact49% Omission31% Inconsistency13% Ambiguity5% Misplaced2% Hooks, HOO3 To fix requirements errors after deployment: 50x to 200x cost factor McConnell, MCC1 55% or more of the... failures discovered by end users and system testers are caused by problems with requirements. The most probable causes are: Ambiguous words and phrases Incomplete statements Inconsistent functions Untestable functions Untraceable functions Undesirable design impositions Robert M. Poston, Generating Test Cases from Use Cases Automatically

In conclusion n CMMI is a process improvement model that maps well to current System Engineering processes n It provides a yardstick to ensure that current best practices for SE and for companies as a whole are implemented