# Presentation: 352906

## Program/Project ManagementGovernment Specific Course II 

- 	Government Specific Course II

- Program/Project ManagementGovernment Specific Course II

- 	Government Specific Course II

- 1-

- Module 4 – Technical Process

- 	Government Specific Course II

- 1-

- Topic 1- Introduction/Objectives

## Systems Engineering 

- 	Government Specific Course II

- 1-

- Systems Engineering

- The ultimate goal of Systems Engineering is the creation of End Products and Enabling Products that provide an integrated and total life cycle balanced set of system, people, and process solutions satisfying customer needs.

- Systems Engineering Technical Processes can be divided into two complementary, related sets

## Systems Engineering 

- 	Government Specific Course II

- 1-

- Systems Engineering

- Processes are used repeatedly at each layer of the system structure
**Top-Down Design:**  These processes include: Requirements Development, Logical Analysis and Design Solution.
**Bottom-Up Realization:  **These processes include: Implementation, Integration, Verification, Validation and Transition.

## Learning Objectives

- 	Government Specific Course II

- 1-

- At the end of this module, you will be able to:

- Describe the different Technical Processes that enables Systems Engineering to create End Products and Enabling Products that provide an integrated and total life cycle balanced set of system, people, and process solutions satisfying customer needs.

## Learning Objectives (cont.)

- 	Government Specific Course II

- 1-

- Discuss how each of these Technical Processes play into the Acquisition Framework.

- 	Government Specific Course II

- 1-

## Top-Down Design 

- 	Government Specific Course II

- 1-

- Top-Down Design

- Here is an overview illustration of the various Technical Processes used as part of the Systems Engineering **top-down** system design process.
- Arranged in the context of their uses in determining requirements, analyzing them, and defining the design.

## Top-Down Design (cont.)

- 	Government Specific Course II

- 1-

- Although shown in a linear sequence here for display purposes, on a typical complex program, these various Technical Processes will be applied simultaneously, recursively, and iteratively over time.

## Bottom-Up Realization 

- 	Government Specific Course II

- 1-

- Bottom-Up Realization

- Processes are arranged in the context of their uses in
- Implementing low-level items
- Integrating them by incorporation into higher-level system elements

## Bottom-Up Realization (cont.)

- 	Government Specific Course II

- 1-

- Processes are arranged in the context of their uses in (continued):
- Implementing low-level items
- Integrating them by incorporation into higher-level system elements

## Bottom-Up Realization (cont.)

- 	Government Specific Course II

- 1-

- Verifying that they conform to design-to or build-to specifications
- Validating conformance to Stakeholder Requirements
- Transitioning system components, ultimately to the end user

## Key Roles 

- 	Government Specific Course II

- 1-

- Key Roles

- Both have similar goals in product development
- Both share key Systems Engineering Technical Processes
- With different emphasis, depending on the phase of development
- Traditionally, industry is the developer and the government is the acquirer for contracted programs.
- For in-house development work, government plays both roles.

- An important realization is that key different roles are played
- by industry and the government.

##  Technical Processes

- 	Government Specific Course II

- 1-

-  Technical Processes

- Objectives of defining capabilities and requirements, establishing constraints and developing key top-level plans that will guide the actual later development of the system
- "Front-end" Systems Engineering-like activities include defining architectures and capabilities and conducting functional analyses
- Planners usually complete these activities before a program is initiated

- In the early stages of the acquisition life cycle, many
- Technical Processes are performed by the government.

##  Technical Processes (cont.)

- 	Government Specific Course II

- 1-

-  Technical Processes (cont.)

- In some cases the government is assisted by contractors with particular expertise in these areas
- As the acquisition life cycle processes through its various phases, contracts are awarded
- Developers begin the task of creating, designing and implementing a system using these same Technical Processes

## Systems Engineering Plan 

- 	Government Specific Course II

- 1-

- Systems Engineering Plan

- No matter who actually does them, the basic Systems Engineering Technical Processes apply.
**Systems Engineering Plan (SEP)** plays a key role in orchestrating these various government and industry processes and ensuring that they are coherently applied.

## Systems Engineering Plan (cont.) 

- 	Government Specific Course II

- 1-

- Systems Engineering Plan (cont.)

- Program managers and project chief systems engineers should establish the SEP early in program formulation and update it at each subsequent milestone, or as required.
- It is intended to be a living document which is tailored to the program.

- The Systems Engineering Plan is a detailed formulation of actions that should guide all technical aspects of an acquisition program.

## Systems Engineering Plan (cont.) 

- 	Government Specific Course II

- 1-

- Systems Engineering Plan (cont.)

- It is a roadmap that supports program management by defining comprehensive systems engineering activities, addressing both government and contractor technical activities and responsibilities.

## Process Presentation Convention

- 	Government Specific Course II

- 1-

- Convention includes a graphic with several key parts.
- The parts illustrate:
- The major inputs and outputs
- The preceding processes providing inputs
- The destination processes using or receiving the outputs
- Outlines the various key activities involved in implementing a particular Technical Process.

## Example from Validation 

- 	Government Specific Course II

- 1-

- Example from Validation

- Details include the illustrative tasks making up the phases of the process and, the expected outcomes of each when it has been successfully applied

## Example from Validation (cont.)

- 	Government Specific Course II

- 1-

- Each Technical Process usually starts with a 'Prepare for...' or 'Plan for...' activity
- Describes the tasks to be done to lay the foundation for the successful application of the particular process being described

## Example from Validation (cont.)

- 	Government Specific Course II

- 1-

- Task listings and outcomes associated with each Technical Process activity are not mandated by specific policies
- They represent a consensus by recognized experts in Systems Engineering of those activities and illustrative tasks that make up a robust, effective process

## Example from Validation (cont.)

- 	Government Specific Course II

- 1-

- They are a template of ‘Best Practices’ that can be tailored and used to perform or oversee Systems Engineering activities.

- 	Government Specific Course II

- 1-

- Topic 3- Requirements Development Process

## Requirements Development Process 

- 	Government Specific Course II

- 1-

- Requirements Development Process

- Part 1:  Deals with Stakeholder Requirements that reflect the needs of a customer and other interested parties. These requirements are used to establish stakeholder satisfaction with a delivered system model End Product.
- Part 2:  Deals with Technical Requirements, which are quantified Stakeholder Requirements stated as shall requirements. These are used ultimately to develop design solutions to satisfy Stakeholder Requirements.

- There are two parts to the **Requirements Development Process**:

## Requirements

- 	Government Specific Course II

- 1-

- There are a wide variety of different ‘user’ communities
- Each community has a different perspective on what constitutes an ‘important’ requirement

- Perspectives on Requirements:

## Example

- 	Government Specific Course II

- 1-

- End users will focus mainly on capabilities and performance
- Production engineers will be concerned with ease of productability
- Maintainers will bring inputs on reliability and maintainability
- Logisticians' requirements will include maintenance approaches, skill levels required to operate and maintain the system, and numbers and types of spares required

## Example (cont.)

- 	Government Specific Course II

- 1-

- Disposal engineers will bring inputs concerning the use and location of hazardous materials
- Everyone is interested in controlling costs

## Requirements Development Process 

- 	Government Specific Course II

- 1-

- Requirements Development Process

- The use of Integrated Product and Process Development (IPPD) and system Integrated Product Teams (IPTs), coupled with the Requirements Development Process, are ideal mechanisms to ensure all these life cycle Stakeholders Requirements are appropriately considered.

- The Requirements Development Process takes all inputs from relevant stakeholders and ultimately translates them into Technical Requirements

- This process complements the follow-up Logical Analysis and Design Solution technical processes

## ‘Capabilities’ vs. Requirements

- 	Government Specific Course II

- 1-

- ‘Capabilities’ vs. Requirements

- Systems Engineers primarily respond to the JCIDS that identifies capability gaps
- JCIDS formally documents stakeholder needs in terms of capabilities via a series of progressively more detailed documents

## ‘Capabilities’ vs. Reqs. (cont.)

- 	Government Specific Course II

- 1-

- ‘Capabilities’ vs. Reqs. (cont.)

- Key JCIDS capability documents include:
- Initial Capability Document (ICD):  required at Milestone A
- Capability Development Document (CDD):  required at Milestone B
- Capability Production Document (CPD):  required an Milestone C

## Technical System Design Processes 

- 	Government Specific Course II

- 1-

- Technical System Design Processes

- Requirements Development Process is the first step in arriving at a design solution for a system model
- System design processes (Requirements Development, Logical Analysis and Design Solution) are used in defining the design solution of a system, its End Products and their subsystems

## Technical System Design Processes (cont.)  

- 	Government Specific Course II

- 1-

- Technical System Design Processes (cont.)

- Is also used for establishing the requirements for Enabling Products that support an End Product over its life cycle.
- These three processes are iterated at each level of the system structure and then applied recursively to lower levels of the physical architecture throughout development.

## Technical System Design Processes (cont.)  

- 	Government Specific Course II

- 1-

- Technical System Design Processes (cont.)

- Illustration shows that Requirements Development is tightly linked to the Technical Processes of Logical Analysis and Design Solution.

- This linkage is important since some requirements will become fully defined only through system decomposition at later stages of development.

## Requirements

- 	Government Specific Course II

- 1-

- Some explicitly stated while others are generated as outcomes from various Technical Processes
- Understanding of the ‘family’ of requirement terms associated with a system model is crucial
- Family members include:
- Stakeholders Requirements
- Acquirer Requirements
- Other Interested Party Requirements

## Requirements (cont.)

- 	Government Specific Course II

- 1-

- Derived Requirements
- Technical Requirements
- Derived Technical Requirements
- Solution-Specified Requirements

## Stakeholders’ Requirements

- 	Government Specific Course II

- 1-

**Stakeholders’ Requirements**:
- Represent what stakeholders of a system need or expect of system products
- Includes both Acquirer Requirements and Other Interested Party Requirements (also called Local Requirements or External Requirements)
- Affects the system model for the program End Products, or the system model for lower-layer project end products
- Used for validating realized products
- Ultimately flow down to each layer in the system model

## Derived Requirements

- 	Government Specific Course II

- 1-

**Derived Requirements are**:
- Not explicitly stated in the set of Stakeholder Requirements yet required to satisfy one or more specific Stakeholder Requirements
- Addressed, most of the time, as part of the Requirements Development Process

## Technical Requirements

- 	Government Specific Course II

- 1-

**Technical Requirements are**:
- Translated from analysis of Stakeholder Requirements
- Expressed in confirmed and quantitative 'shall' statements
- An input to Logical Analysis resulting in Derived Technical Requirements

## Derived Technical Requirements 

- 	Government Specific Course II

- 1-

- Derived Technical Requirements

**Derived Technical Requirements are:**
- Those that result from allocation of Technical Requirements to logical models formed by the Logical Analysis Process or from analysis of alternative solutions done as part of the Design Solution Process.
- The ‘design-to’ requirements for the Design Solution Process.

## Solution-Specified Requirements 

- 	Government Specific Course II

- 1-

- Solution-Specified Requirements

**Solution-Specified Requirements can be:**
- Specifications and drawings that describe the end product Design Solution that are used as input to the Implementation Process or Integration Process
- Enabling Product requirements that are used for developing or acquiring Enabling Products
- Initial subsystem requirements that are flowed down to the next lower layer of the system models.
- End Product specified requirements that are used for verifying that the realized product has been Implemented or Integrated correctly

## Requirements Development Process 

- 	Government Specific Course II

- 1-

- Requirements Development Process

- Used to establish stakeholder satisfaction with a delivered system model End Product.

- As stated before, there are two parts to the Requirements Development Process:
**Part 1**: deals with Stakeholder Requirements that reflect the needs and expectations of the acquirer and other interested parties.

## Requirements Development Process (cont.) 

- 	Government Specific Course II

- 1-

- Requirements Development Process (cont.)

- Used to develop design solutions for the system model products intended to satisfy Stakeholder Requirements.

**Part 2**: deals with Technical Requirements.

- Part one of the Requirements Development process:

- Acquirer Requirements and Other Interested Party Requirements are collected and combined, yielding Stakeholder Requirements
- These are ultimately transformed into Technical Requirements

## Part One 

- 	Government Specific Course II

- 1-

- Part One

**The Purpose**
- Stakeholder Requirements Development activities are used to establish the capabilities that a set of system products and services for a system model must provide.

## Part One (cont.)

- 	Government Specific Course II

- 1-

**The Purpose**
- The resulting set of Stakeholder Requirements must take into full account the capability, needs, expectations, competencies and the working environment of the operators and users.

## Part One (cont.)

- 	Government Specific Course II

- 1-

**The Outcome**
- Establishes the Stakeholder (Acquirer and Other Interested Party) Requirements for the “system” box of the system model illustrated here.

## Part One (cont.)

- 	Government Specific Course II

- 1-

- Capability Needs
- Customer Requirements
- Other Interested Party Requirements

- Key Inputs

- Key Outputs

- Baselined Operations Concept
- Baselined Enabling Product Support Service Strategies
- Baselined Stakeholder Requirements

## Part One (cont.)

- 	Government Specific Course II

- 1-

- Initial process input is from the Technical Planning Process, an output of which is identification of required capabilities
- As development proceeds, recursive applications of the Design Solution Process identifies requirements for lower levels (e.g., subsystems, etc.) in the system, which become inputs to additional Requirements Development done at lower levels in the system structure.
- Additionally, the work products produced by process activities are recorded in the program's technical data management database.

## Stakeholder Requirements Development

- 	Government Specific Course II

- 1-

- Identify Stakeholders
- Elicit Stakeholder Requirements
- Establish Operational Scenarios and Concepts
- Write Stakeholder Requirements in an Acceptable Manner

- Typical activities involved in Stakeholder Requirements Development are:

## Stakeholder Requirements Development (cont.)

- 	Government Specific Course II

- 1-

- 5.  Analyze Requirements for Measures of Effectiveness (MOEs)
- 6.  Get Stakeholder Commitments
- 7.  Baseline Stakeholder Requirements

- Typical activities involved in Stakeholder Requirements Development are: (continued)

##  ‘Stakeholders’ 

- 	Government Specific Course II

- 1-

-  ‘Stakeholders’

- Any party that has an interest in the outcome of the project
- Customer is a stakeholder
- What needs to be done
- Identify Customers
- Acquirers, users, operators or others that will have input requirements to the operational capabilities and requirements for the system model

##  ‘Stakeholders’ (cont.)

- 	Government Specific Course II

- 1-

-  ‘Stakeholders’ (cont.)

- Identify other Stakeholders
- Other interested parties that will be impacted by or will impact the development and use of the system's life cycle support enabling products

##  ‘Stakeholders’ (cont.)

- 	Government Specific Course II

- 1-

-  ‘Stakeholders’ (cont.)

- Expected outcomes of this task include:
- Identification of known sources of requirements affecting the system model products
- Identification of individuals and groups of individuals (e.g. users, operators, acquirers) that will directly impact the requirements for development of the operational End Products

##  ‘Stakeholders’ (cont.)

- 	Government Specific Course II

- 1-

-  ‘Stakeholders’ (cont.)

- Identification of individuals and groups that will have requirements with respect to providing life cycle services (via Enabling Products) to support the End Products during development, test, manufacturing, deployment, training, operations, operational support, maintenance, and disposal
- Identification of individuals and groups that will impose constraints

##  ‘Stakeholders’ (cont.)

- 	Government Specific Course II

- 1-

-  ‘Stakeholders’ (cont.)

- What do Stakeholders Want?
- Depending on who they are, the 'wants' of stakeholder can vary considerably. These 'wants' encompass both:
- Acquirer Requirements
- Other Interested Party Requirements

## Acquirer Requirements

- 	Government Specific Course II

- 1-

- What do Stakeholders Want?
- Acquirers are one of the key 'customers' of a system.
- Acquirer Requirements govern the logical and physical characteristics of the system.
- Important Acquirer Requirements come from the end users of the system.

## Acquirer Requirements (cont.)

- 	Government Specific Course II

- 1-

- Acquirer Requirements typically encompass:
**Operational Profiles:**  Planned usage
**Accomplishments:**  Function and Performance
**Environment:**  Where and under what conditions
**Characteristics:**  Desired characteristics
**Constraints:**  Product and design process limitations
**Measures of Effectiveness:**  The basis of stakeholder satisfaction

## Acquirer Requirements (cont.)

- 	Government Specific Course II

- 1-

- Most of the Acquirer Requirements for a system model will come from the end user's capabilities needs.
- The end user decides how the system End Products will be employed, what capabilities they must have and how well the system must perform its mission
- Acquirer Requirements also include life cycle support requirements as well.
- Other stakeholders who are not end users will have important additional requirements as well

## Example

- 	Government Specific Course II

- 1-

- The Test and  Evaluation (T&E) community, by law the user’s representative, will formally determine if the system is effective and suitable for its intended purpose using various systems-level validation process activities.
- T&E Community is only one of many ‘Other Interested Parties’.

## Other Interested Party Requirements

- 	Government Specific Course II

- 1-

- Sometimes called ‘Local Requirements’ or  ‘external Requirements’
- Derived in part from the many laws, regulations, treaties, policies, etc., which may affect the system products
- Requirements can be difficult to define adequately
- Certifications of various types may be required before the system can be Transitioned to the end user

##  Elicit Stakeholder Requirements 

- 	Government Specific Course II

- 1-

-  Elicit Stakeholder Requirements

- The tasks for this step include:
- Elicit Customer Requirements and Identify:
- Desired capabilities, needs, wants, desires and expectations products must satisfy
- Critical requirements affecting system safety, security, reliability, availability, and maintainability
- Elicit Customer Requirements and Identify:
- Requirements for development and integration, production, test, operations and logistics

##  Elicit Stakeholder Requirements (cont.)

- 	Government Specific Course II

- 1-

-  Elicit Stakeholder Requirements (cont.)

- Elicit Other Interested Party Requirements to identify: (continued)
- Requirements that can constrain the development or utilization of End Products
- Program/project constraints
- Organizational constraints

##  Elicit Stakeholder Requirements (cont.)

- 	Government Specific Course II

- 1-

-  Elicit Stakeholder Requirements (cont.)

- Expected Outcomes for this Task
- Desired capabilities
- What the acquirer wants the End Products of the system model to accomplish and how well
- Environments in which End Products must operate or be used and design constraints
- Requirements pertaining to availability, spectrum compatibility, health and human factors, interoperability, maintainability, reliability, safety and security, etc

##  Elicit Stakeholder Requirements (cont.)

- 	Government Specific Course II

- 1-

-  Elicit Stakeholder Requirements (cont.)

- Expected Outcomes for this Task
- An understanding of the interest and involvement of stakeholders, other than users or operators
- Enabling Product requirements associated with development and integration, manufacturing, production, test, operations and logistics processes

## Concept of Operations 

- 	Government Specific Course II

- 1-

- Concept of Operations

- Concept of Operations (CONOPS)
- Developed after Stakeholder Requirements and Other Interested Party Requirements have been elicited
- Should describe what activities need to be done
- Also where, when, by whom, and under what conditions they will be done

## Concept of Operations (cont.)

- 	Government Specific Course II

- 1-

- Concept of Operations (cont.)

**CONOPS creation involves:**
- Determining uses and operational profiles
- Documenting the steps involved
- Both textual descriptions and diagrams

## Concept of Operations (cont.)

- 	Government Specific Course II

- 1-

- Concept of Operations (cont.)

**In addition, a CONOPS is useful to:**
- Facilitate completeness of requirements
- Aid in identification of interface issues (human, physical, environment)
- Provide a basis for establishing requirements traceability
- Provide a foundation for End Product validation

## Value of a CONOPS 

- 	Government Specific Course II

- 1-

- Value of a CONOPS

- The Value of a CONOPS is significant:
- Doing CONOPS as a team effort helps resolve requirement debates and facilitates completeness of requirements
- Key user interface issues can be identified
- A complete CONOPS provides an early basis for ensuring the completeness and consistency of stakeholder requirements

## Value of a CONOPS (cont.) 

- 	Government Specific Course II

- 1-

- Value of a CONOPS (cont.)

- The Value of a CONOPS is significant: (continued)
- CONOPS effectively communicates with system developers and customers alike by bridging technical language barriers
- Finally, the CONOPS forms the foundation for the developing of the system’s Operational Architecture.

## Example

- 	Government Specific Course II

- 1-

- Protects the mail man/woman from adverse conditions
- Can maneuver and get around easily in bad conditions (snow, mud, etc.)
- Gets more than 25 miles a gallon
- Has enough storage space for 10 full bags of mail
- Can be driven easily by typical users

- A CONOPS is based around Stakeholder Requirements.  Here are some for a new four-wheel drive mail truck designed to deliver mail in terrible weather conditions. A new Truck is needed that:

##  Establish Operational Scenarios

- 	Government Specific Course II

- 1-

-  Establish Operational Scenarios

- Tasks associated with this step include:
- Usage:  Identify, analyze, clarify and prioritize End Product uses, operational profiles, scenarios and the concept of operation (CONOPS)
- Users:  Analyze and clarify the users or operators of the system products, their roles and characteristics (for example, skill levels, physical capabilities, etc)

##  Establish Operational Scenarios (cont.)

- 	Government Specific Course II

- 1-

-  Establish Operational Scenarios (cont.)

- Tasks associated with this step include: (continued)
- Performance Envelopes:  Determine the system performance envelope
- Enabling Product Strategies:** ** Identify strategies for development and integration, production, test, operations and logistics. Identify, analyze and clarify acquirer constraints resulting from these strategies

## Expected Outcomes for Step 3

- 	Government Specific Course II

- 1-

- The expected Outcomes of this step include:
- Concept of Operations (CONOPS)
- End Product operational limits (operational envelope)
- User and/or operator tasks, capabilities, capacities and work environment
- Enabling life cycle service strategies/concepts
- Other 'interested party' influences that could affect system product and service design and utilization

## ‘Acceptable Requirement’ 

- 	Government Specific Course II

- 1-

- ‘Acceptable Requirement’

- One of the key outcomes of the Requirements Development Process are the generation of ‘acceptable’ or quality requirements
- Bad requirements will doom system development from the starting gate!
**An ‘Acceptable Requirement’ must be:**
- Achievable
- Verifiable
- Unambiguous

## ‘Acceptable Requirement’ (cont.)

- 	Government Specific Course II

- 1-

- ‘Acceptable Requirement’ (cont.)

**An ‘Acceptable Requirement’ must be: (continued)**
- Necessary and sufficient
- Complete
- Expressed in terms of need
- Consistent
- Appropriate

## Writing the Stakeholder Requirements 

- 	Government Specific Course II

- 1-

- Writing the Stakeholder Requirements

- The tasks that are part of this step include:
- Understand:  Analyze, clarify and prioritize acquirer needs and expectations The CONOPS should be the basis for these as well as other source documents
- Write:  Stakeholder Requirements
- Examine:  Analyze and compare Stakeholder Requirement statements
- ID Conflicts:  Identify conflicts between Stakeholder Requirement statements

## Writing the Stakeholder Requirements (cont.) 

- 	Government Specific Course II

- 1-

- Writing the Stakeholder Requirements (cont.)

- The tasks that are part of this step include: (continued)
- ID Problems:  Identify contradictory, ambiguous, inconsistent and non-testable requirements
- Fix:  Resolve identified conflicts using the Decision Analysis Process

**Decision Analysis Process:**  provide the basis for evaluating and selecting alternatives when decisions need to be made

##  Expected Outcomes 

- 	Government Specific Course II

- 1-

-  Expected Outcomes

- Set of acceptable Stakeholder Requirement statements
- Conflicting Stakeholder Requirements are resolved to include acceptance from the stakeholders of action taken
- Bi-directional traceability has been established

- The Expected Outcomes that are associated with this step include:

## Systems Engineering Measures 

- 	Government Specific Course II

- 1-

- Systems Engineering Measures

- The key technical measures to be used for a program or project are identified in plans generated by the Technical Planning Process
- Defined during the Requirements Development Process
- Evaluated during the Verification, Validation and Technical Assessment Processes

- Systems Engineering Measures play a significant role in Systems Engineering activities

## Systems Engineering Measures (cont.)

- 	Government Specific Course II

- 1-

- Within the government, there are specific measurement terminology usages that are important to understand.
- These terms have both technical process and programmatic impacts which cannot be totally separated.
- Since these terms are used in both the Stakeholder Requirements Development Process being described here as well as the Technical Requirement Development Process, an overview will be provided now

## Measures of Interest

- 	Government Specific Course II

- 1-

**Key Performance Parameters (KPPs)**:
- A program-level measure identified by operational stakeholders and included as a required part of JCIDS capability documents
- Appear verbatim in the** Acquisition Program Baseline (APB)** where their objectives and threshold values establish programmatic trade space

## Measures of Interest (cont.)

- 	Government Specific Course II

- 1-

**Acquisition Program Baseline (APB): ** a required programmatic document that prescribes the key cost, schedule, and performance constraints to be achieved in a particular Defense Acquisition Framework phase of development.
**Trade Space:**  the set of program and system parameters, attributes and characteristics required to satisfy some aspect of system performance. Decision-makers define and refine the development system by making trade-offs with regard to cost, schedule, risk and performance---all of which fall within the "trade space."

## Measures of Interest (cont.)

- 	Government Specific Course II

- 1-

-    Used to establish program system model test objectives
-     These in turn can be used to generate MOEs and MOSs.

**Critical Operational Issues (COIs)**:

## Measures of Interest (cont.)

- 	Government Specific Course II

- 1-

**Measures of Effectiveness (MOEs)**:

- Critical performance expectations of the customer or user that if not satisfied will cause the delivered end product to be considered unacceptable; they are broadly defined
- Special form of KPPs for the technical effort
- Impact a number of Derived Requirements throughout the system as well as being the foundation for measures that are later used to assess success of a delivered End Product

## Measures of Interest (cont.)

- 	Government Specific Course II

- 1-

**Measures of Suitability (MOSs):**

- Measures the degree to which an End Product is appropriate for its intended use and/or to the degree that the life cycle services for that End Product will provide required levels of supportability

## Measures of Interest (cont.)

- 	Government Specific Course II

- 1-

**Measures of Performance (MOPs):**
- Specific Technical Requirements derived from MOEs and MOSs
- There are generally several MOPs for each MOE or MOS
- MOPs are determined from analysis of the MOEs and MOSs as  Technical Requirements Development activity

## Measures of Interest (cont.)

- 	Government Specific Course II

- 1-

**Critical Technical Parameters (CTPs):**
- Not Stakeholder Requirements, but, instead, are technical measures derived from desired capabilities
**Technical Performance Measures:**
- A critical system performance parameter that is formally tracked over the life cycle via the Technical Assessment Technical Management Process

## Technical Assessment 

- 	Government Specific Course II

- 1-

- Technical Assessment

- EVM
- Technical Reviews

- A Technical Assessment is a Systems Engineering Technical Management Process that measures technical progress and the effectiveness of various technical plans and requirements and monitors progress against those plans.
- The key tools of Technical Assessment are:

## Technical Assessment (cont.) 

- 	Government Specific Course II

- 1-

- Technical Assessment (cont.)

- Technical Performance Measurement (TPM)
- Technical Performance Measurement (TPM) is the process of comparing actual versus planned technical development and design
- Subset of the MOPs and CTPs defined during Technical Requirements Development

## Analyze Requirements for MOEs

- 	Government Specific Course II

- 1-

- The tasks that are included in this step are:
**ID MOEs**: Identify from the customer/acquirer requirements Measures of Effectiveness (MOEs) by which the program or project system model End Product performance can be measured and assessed
- Identify and prioritize the significance of the system to other interested parties and identify additional MOEs, if any
- Analyze MOE statements to clarify technical feasibility and schedule attainment

## Analyze Requirements (cont.)

- 	Government Specific Course II

- 1-

- Outcomes of this step include:
- Measures of Effectiveness that reflect overall expectations against which customer satisfaction will be determined

## Stakeholder Commitments 

- 	Government Specific Course II

- 1-

- Stakeholder Commitments

- In order to complete this task, you must:
**Review**: The Stakeholder Requirements. This review, part of the Technical Assessment Process, could be part of the **Systems Requirements Review (SRR)**

**Systems Requirements Review (SRR):  **A multi-functional technical review to ensure that all system and performance requirements derived from the Capability Development Document are defined and consistent with cost (budget), schedule (program schedule), risk, and other system constraints.  It ensures consistency between the system requirements and the preferred system solution and available technologies.

## Stakeholder Commitments (cont.) 

- 	Government Specific Course II

- 1-

- Stakeholder Commitments (cont.)

**Understand:** Assure stakeholders understand the set of Stakeholder Requirements
**Commit**: Obtain commitments that the set of Stakeholder Requirements is adequate

## Stakeholder Commitments (cont.) 

- 	Government Specific Course II

- 1-

- Stakeholder Commitments (cont.)

- The expected outcomes for this step are:
- Agreement by stakeholders as to their understanding of their requirements
- Commitment by stakeholders to the resulting set of Stakeholder Requirements

## Baseline Stakeholder Requirements

- 	Government Specific Course II

- 1-

- The tasks associated with this step are:
**Capture Work Products**: Capture the set of Stakeholder Requirements and any associated rationale and assumptions
**Record Outcomes**: Record Stakeholder Requirements Definition Process outputs and related work products in the established technical data management database
**Lessons Learned**: In the established technical data management database, capture and record lessons learned from defining Stakeholder Requirements

## Baseline Stakeholder Requirements (cont.)

- 	Government Specific Course II

- 1-

- The expected outcomes for this step are:
- Procedures, outcomes, assumptions, corrective actions, lessons learned, etc
- Basis for establishing the user, operator and Other Interested Party aspects of the Stakeholder Requirements for the system model

## Baseline Stakeholder Requirements (cont.)

- 	Government Specific Course II

- 1-

- The expected outcomes for this step are: (continued)
- Basis for managing Stakeholder Requirement traceability and change control
- Basis for establishing the acceptability of the system End Products and life cycle services to be supplied for the program/project system model according to the agreement with the acquirer

## Question

- 	Government Specific Course II

- 1-

- Why is it important to Baseline Stakeholder Requirements as the last activity of the Requirements Development Process?

## Part Two

- 	Government Specific Course II

- 1-

- Quantified Stakeholder Requirements stated as **shall requirements  **(mandatory requirements for the design or realization of an end product)
- Used to develop design solutions for the system model products intended to satisfy Stakeholder Requirements

- Part two of the Requirements Development Process Deals with Technical Requirements

## Translation of Stakeholder Needs

- 	Government Specific Course II

- 1-

- Translation of Stakeholder Needs into Technical Requirements is a critical step in the Requirements Development Process.
- Errors will compound and multiply as Derived Technical Requirements are developed during the follow-up Logical Analysis Process and Design Solution Process activities.
- Starting with a good set of Technical Requirements is a critical step for a successful development.

## Technical Requirements Development

- 	Government Specific Course II

- 1-

**Purpose:**  Transform the defined Stakeholder Requirements (Acquirer Requirements and Other Interested Party Requirements) into a set of base lined quantitative Technical Requirements (shall statements)
**Objective:**  To transform the baselined Stakeholder Requirements into Technical Requirements and allocate the system Technical Requirements to the respective products at the second level of the system model
- The System Technical Requirements, End Product Technical Requirements and Enabling Product Technical Requirements all are inputs to the follow-up Logical Analysis Process.

## Key Inputs 

- 	Government Specific Course II

- 1-

- Key Inputs

- The outputs of Stakeholder Requirement Development:
- Baselined Stakeholder Requirements
- Baselined Operations Concept
- Measures of Effectiveness

- Key inputs of Technical Requirements Development

## Key Inputs (cont.)

- 	Government Specific Course II

- 1-

- Key Inputs (cont.)

- The outputs of Stakeholder Requirement Development: (continued)
- Baselined Enabling
- Support Strategies

## Key Outputs

- 	Government Specific Course II

- 1-

**Outputs**:
- Baselined Technical Requirements that will be inputs to the Logical Analysis Process
- Baselined TPMs that will be used by the Technical Assessment Process
- Work products produced by process activities are recorded in the technical management database and used by various Technical Management Processes

## Key Activities 

- 	Government Specific Course II

- 1-

- Key Activities

- Analyze the scope of the technical problem to be solved
- Define the Requirements in technical terms
- Write 'acceptable' Technical Requirement statements
- Define Technical Requirement measures
- Baseline Technical Requirements

- Key activities involved in Technical Requirements Development include:

## Analyze

- 	Government Specific Course II

- 1-

- The first step in Technical Requirements Development is to _Analyze the scope of Technical Effort Required Driving Design Solution._
- The tasks for this step include:

**Review**: Review Stakeholder Requirements and identify and define:
- Required rules, priorities, inputs, outputs, states and modes of operation and configurations
- Critical requirements for system model products and services such as safety, security, context of use by humans, reliability, etc

## Analyze (cont.)

- 	Government Specific Course II

- 1-

**Analyze**: Analyze Stakeholder Requirements and:
- Break down all compound requirements into separate ones
- Resolve acquirer and other Stakeholder Requirements that are of questionable utility or that have an unacceptable risk of satisfaction

## Analyze (cont.)

- 	Government Specific Course II

- 1-

- Define external physical and functional interfaces
- Establish which aspects of the problem defined above can be changed based on tradeoff analysis

- Define the expected interactions among system functions

## Analyze (cont.)

- 	Government Specific Course II

- 1-

- Required capacities (e.g. memory, storage and flows) of system products and timing of events, states, modes and functions for each operational profile
- Aspects of the problem that will influence and affect the other tasks for design of system model products and services
- What part of the system model the project controls from a design perspective and what part it only can influence, at best
- Critical requirements for system products and services

- The expected Outcomes for this step include:

## Define Requirements 

- 	Government Specific Course II

- 1-

- Define Requirements

**3.   Define** Requirements in Technical Terms

- The next step in the Technical Requirements Development Process is:

## Define Requirements (cont.)

- 	Government Specific Course II

- 1-

- Tasks include:

- Constraints:  Define requirements that will be a constraint on the design solution or how the system products will be able to be used Specifically:
- Establish which requirements (functional, behavioral, context of use, human limitations, external work environment, interfaces, product physical characteristics, etc.) cannot be changed by trade-off analysis
- Determine the impact on system model design solutions

## Define Requirements (cont.)

- 	Government Specific Course II

- 1-

- 2.  **Requirements**: Define a set of requirements in technical terms for the range of anticipated uses of the system products and services, as identified, e.g., in the concept of operations. For example:
- Identify what system products must be able to do (functions) and how they are to react to stimuli (behavior) and functional and behavioral conflicts
- Identify functions and behaviors that can be changed by trade-off analyses
- Identify, resolve constraint, functional and behavioral requirement conflicts

## Define Requirements (cont.)

- 	Government Specific Course II

- 1-

- 3.  **Performance**: Defines the performance requirements associated with each defined functional and behavioral requirement :
- Quantify how well functions must be accomplished and expected behavioral responses to input
- Identify and resolve performance requirement conflicts

## Define Requirements (cont.)

- 	Government Specific Course II

- 1-

- The expected outcomes for this step include:
- Identification of constraints that will limit use of technologies; operator workspace, work loads, interfaces, safety, health, etc.; product design physical characteristics; enabling product choices; and residual risks from constraints
- What system model products and services must be able to accomplish (functional requirements) to satisfy customer requirements; events to which end products must respond; physical and functional interfaces, and how often and cycle time that the end products will be used

## Define Requirements (cont.)

- 	Government Specific Course II

- 1-

- The expected outcomes for this step include: (continued)
- Performance expectations for each functional requirement; and functional and performance testability approach for each requirement statement

## Define Requirements (cont.)

- 	Government Specific Course II

- 1-

- When writing the performance parameters of a requirement, the requirement should be stated in terms of a **threshold** and an **objective**

**Threshold Value:  **the minimum acceptable operational value below which the utility of the system becomes questionable
**Objective:**  the level of performance the user desires and beyond which any gain in utility does not warrant additional expenditure

## Define Requirements (cont.)

- 	Government Specific Course II

- 1-

- Specifying capabilities and performance in this way provides the system designer with a larger ‘trade space’ in which to investigate alternative designs.

## Write

- 	Government Specific Course II

- 1-

- 3.  Write Technical Requirements Statements in an Acceptable Manner
- Quantify how well functions must be accomplished and expected behavioral responses to input

- The next step is:

## Write (cont.)

- 	Government Specific Course II

- 1-

- 1.   **Shalls**: Write each defined Technical Requirement as a 'shall' statement in an appropriate subject, verb, object, and 'how well and when' format
- Identify and resolve conflicts within the set of Technical Requirements
- Check that Technical Requirement statements, individually, in pairs and in sets are stated in an 'acceptable' manner
- Rewrite unacceptable Technical Requirement statements

- The Tasks associated with this step include:

## Write (cont.)

- 	Government Specific Course II

- 1-

- 2.  **Validity of Requirements**: Assure that a validated set of Technical Requirements is established:
- Identify and resolve requirements that have questionable utility or pose an unacceptable risk
- Analyze the consistency and accuracy of assumptions made in converting stakeholder requirement statements to technical requirement statements

## Write (cont.)

- 	Government Specific Course II

- 1-

- 2.  **Validity of Requirements**: Assure that a validated set of Technical Requirements is established: (continued)
- Analyze and determine whether the requirements that are derived are essential to and consistent with subsequent DoD Acquisition Framework phases, as well as to system products and services being developed

## Write (cont.)

- 	Government Specific Course II

- 1-

- The Expected Outcomes associated with this step are:

- Bi-directional traceability exhibited with the Technical Requirements and the Baselined Stakeholder Requirements
- Conflicts are resolved among combinations of technical requirements as well as within any defined subset of technical requirements
- Confirmation that assumptions and Derived Requirements are valid and consistent with the system or system products and services being developed

## Write (cont.)

- 	Government Specific Course II

- 1-

- Resolution of identified voids, variances and conflicts including:
- Confirmation that appropriate action has been taken when the set of defined Technical Requirements is not 'necessary and sufficient‘
- Proof that revalidation of the set of Technical Requirements has been done when a change is needed to Stakeholder Requirements

## Write (cont.)

- 	Government Specific Course II

- 1-

- Statements should be complete and constructed in subject-verb-object formats to include ‘how and when or where’ the function must be performed

- It is important to know how to write Government Requirements in terms of performance-based language

## Write (cont.)

- 	Government Specific Course II

- 1-

- Should specify:

**Functions**: What the system has to do, in terms of thresholds and goals if possible
**Performance**: How well and when the functions have to be performed
**Interfaces**: Environment in which the system will perform, other systems with which it must operate (external interfaces) and any other requirements or constraints

## Define Needed Technical Measures

- 	Government Specific Course II

- 1-

- MOPs: Define Measures of Performance (MOPs) for each previously-identified Measure of Effectiveness (MOE) and Measure of Suitability (MOS)
- Identify the set of MOPs for identified MOEs from Stakeholder Requirements definition and the MOSs identified from programmatic documents
- Analyze the MOPs to ensure that the MOE or MOS is adequately quantified and that each MOP can be verified by testing, inspection, analysis or demonstration

- The tasks associated with this process are:

## Define Needed Technical Measures (cont.)

- 	Government Specific Course II

- 1-

**Define Parameters**: Define a set of Technical Performance Measures
- Select from the set of defined system model Measures of Performance (MOPs) or Critical Technical Parameters (CTPs) a sub-set of Technical Performance Measurement parameters

## Define Needed Technical Measures (cont.)

- 	Government Specific Course II

- 1-

- Establish the expected profile change of the technical parameter as a function of development time based on expected technology advancements and design solution maturity; establish expected points when status will be evaluated by; establish limits of the expected profile as a function of time; establish threshold values which if not met will cause cancellation or redirection of the program/project
- Prepare contingency plans in the event an upper or lower parameter limit is breached or if the threshold parameter value will not be attained

## Define Needed Technical Measures (cont.)

- 	Government Specific Course II

- 1-

- Set of measures of performance (MOPs) made up of the functional and performance requirement combinations associated with each MOE/MOS
- Critical parameters selected from the MOPs and CTPs that will be key indicators of system product or overall system performance and if not met, will cause the associated MOE/MOS to not be satisfied and thus put the program/project in cost, schedule, or performance risk

- The Outcomes associated with this step are:

## Define Needed Technical Measures (cont.)

- 	Government Specific Course II

- 1-

- Contingency plans to follow if established parameter tolerance limits are exceeded or if an unacceptable risk of the threshold not being met is projected

- The Outcomes associated with this step are: (continued)

## Baseline the Technical Requirements

- 	Government Specific Course II

- 1-

**Capture**: Capture the set of Technical Requirements and any associated rationale, decisions and assumptions
**Record**: Record work products and Technical Requirements in the established technical data management database that permits traceability to Stakeholder Requirements and Design Solutions
**Lessons Learned**: Capture and record lessons learned from applying the Technical Requirements Development activities in the established technical data management database

- The tasks associated with this step are:

## Baseline the Technical Requirements (cont.)

- 	Government Specific Course II

- 1-

- Validated set of requirements stated in technical terms and in an acceptable manner and that represents a reasonably complete description of the technical problem that must be solved
- Procedures, outcomes, assumptions, corrective actions, lessons learned, etc

- The Expected Outcomes for this step include:

## Baseline the Technical Requirements (cont.)

- 	Government Specific Course II

- 1-

- Basis for establishing the design solution for the system model products and services of the system structure being developed
- Basis for managing Technical Requirements traceability and change control

- The Expected Outcomes for this step include: (continued)

## Question

- 	Government Specific Course II

- 1-

- Why is the last activity in the Requirements Development Process for Technical Requirements so important?

- 	Government Specific Course II

- 1-

## Logical Analysis Process

- 	Government Specific Course II

- 1-

- Logical Analysis Process

- The Logical Analysis Process

- The process that obtains sets of logical solutions so as to improve understanding of the defined system Technical Requirements and the relationships among them
- Performance parameters and constraints are allocated to these logical solutions
- Candidate functional architectures are developed
- Derived Technical Requirements to be later used for the system design are defined

## Question

- 	Government Specific Course II

- 1-

- What is Logic?  Why is it necessary to use it in this context?

## Logical Analysis Process

- 	Government Specific Course II

- 1-

- Outcomes of the Requirements Development Process include a base lined set of Technical Requirements, which establish the basis for system development for a system
- Technical Requirements are not enough to develop a design solution
- Logical Analysis provides a more detailed understanding of the problem at hand

## Logical Analysis Process (cont.)

- 	Government Specific Course II

- 1-

- Transformed the set of Baselined Technical Requirements into
- Logical Models that define and help understanding of the relationships among the functions, behaviors, data flows, attributes, services, and states and modes of the Technical Requirements
- Derived Technical Requirements that are formed from Logical Model(s) analysis and then allocated to system model elements

## Logical Models 

- 	Government Specific Course II

- 1-

- Logical Models

- Logical Models are outputs of the Logical Analysis Process
- Representation of the relationship of Technical Requirement attributes required to be satisfied by the physical solution.
- Each attribute can be represented by a model.

## Example

- 	Government Specific Course II

- 1-

- Functional (functional flow or logic diagrams)
- B behavioral (response diagrams)
- Temporal (time-based sequencing)
- Product states and modes (transition diagrams)
- Data (data flows)
- Controls (control flows)
- Failure modes (functional failure modes and effects) and information (information flows)

- Attributes and their associated models (shown in parentheses) can be:

## Requirements

- 	Government Specific Course II

- 1-

- Some requirements are not explicitly stated in a higher-level set of requirements yet must be satisfied in order to provide a complete system solution
- Types of these include:
**Derived Requirements:**
- Not explicitly stated in the set of Stakeholder Requirements yet required to satisfy one or more specific stakeholder requirements.
- Many of these are addressed as part of the Requirements Development Process.

## Requirements (cont.)

- 	Government Specific Course II

- 1-

**Derived Technical Requirements:**
- Results from allocation of Technical Requirements to logical models or from analysis of alternative solutions.
- A 'design-to' requirement for the Design Solution Process

## Requirements (cont.)

- 	Government Specific Course II

- 1-

- Stakeholder Requirements can flow to either Acquirer Requirements or Other Interested Party Requirements
- Both of these flow to Technical Requirements, then are assigned to Logical Analysis Models

## Requirements (cont.)

- 	Government Specific Course II

- 1-

- These can then flow either to Derived Technical Requirements or Design Alternatives
- Design Alternatives are a source of Design Solution specified by Solution Specified Requirements

## Question

- 	Government Specific Course II

- 1-

- What types of requirements are not explicitly stated in a higher-level set of requirements but still must be satisfied to provide a complete solution?

## Logical Analysis 

- 	Government Specific Course II

- 1-

- Logical Analysis

- The Purpose of Logical Analysis
- Establish relationships among the base lined Technical Requirements established by the Requirements Development Process
- Thus improve 'design-to' requirements which are inputs to the Design Solution Process

## Logical Analysis (cont.)

- 	Government Specific Course II

- 1-

- Outcomes for Logical Analysis
- A set of logical models showing relationships among the behavioral, functional, temporal (time), data flow, etc., attributes of the base lined Technical Requirements
- A set of 'design-to' Derived Technical Requirements

## Logical Analysis (cont.)

- 	Government Specific Course II

- 1-

- Focus of Logical Analysis
- Encompasses the formation of models, the allocation of Technical Requirements to them and using results of the analysis process to develop Derived Technical Requirements

## Logical Analysis (cont.)

- 	Government Specific Course II

- 1-

- Partitions a system into self-contained, cohesive, logical groupings of interchangeable and adaptable elements to enable ease of change, achieve technology transparency and mitigate the risk of obsolescence; and
- Uses rigorous and disciplined definitions of interfaces and, where appropriate, defines the Key Interfaces within a system using widely supported, open system standards

- The design approach resulting from the Logical Analysis Process:

## Key Inputs and Outputs

- 	Government Specific Course II

- 1-

**Key inputs for this process are:**  Technical Requirements from the Requirements Development Process
**Key Outputs are**: Logical Analysis Models and Derived Technical Requirements that are inputs to the Design Solution Process
- In addition the various work products produced by process activities are recorded in the Technical Data Management database

## Key Inputs and Outputs (cont.)

- 	Government Specific Course II

- 1-

- Work Products can for this process include:  Functional flow block diagrams, Logic flow diagrams, Time lines, Context diagrams, State and mode transitions.  Structured analyses algorithms, Data flows, Services and attributes, Behavioral diagrams and responses, Requirements allocation sheets

## Key Activities

- 	Government Specific Course II

- 1-

**Define**: One or more logical analysis models
**Allocate**: Technical Requirements to logical analysis models to form Derived Technical Requirements
**Resolve**: Derived Technical Requirement conflicts with each logical analysis model and among logical analysis models

- Key activities that make up the Logical Analysis Process:

## Key Activities (cont.)

- 	Government Specific Course II

- 1-

**4.   Assure**: Derived Technical Requirements are necessary and sufficient
**5.   Baseline**: The logical analysis models and Derived Technical Requirements with rationale, decisions and assumptions

- Key activities that make up the Logical Analysis Process: (continued)

## Tasks

- 	Government Specific Course II

- 1-

- Establish logical models for the defined Technical Requirements by doing trade-off studies against cost, schedule, performance and risk using the **Decision Analysis Process**

- The tasks associated with the first activity are:

**Decision Analysis Process:**  provides the basis for evaluating and selecting alternatives when decisions need to be made

- 2.   Perform functional analysis to understand the sub-functions and their logical flows

## Tasks (cont.)

- 	Government Specific Course II

- 1-

- Establish logical models for the defined Technical Requirements by doing trade-off studies against cost, schedule, performance and risk using the **Decision Analysis Process**

- The tasks associated with the first activity are:

**Decision Analysis Process:**  provides the basis for evaluating and selecting alternatives when decisions need to be made

- 2.   Perform functional analysis to understand the sub-functions and their logical flows

## Expected Outcomes

- 	Government Specific Course II

- 1-

- The expected Outcomes for this process are Logical Analysis Models, which include:

- Functional flow, timelines, behaviors, data and control flows, states and modes, functional failure modes and effects
- Model data and functions with algorithms used to decompose functions while explicitly showing the data needed for each function
- Data structures with their functions and processing flows

## Considerations

- 	Government Specific Course II

- 1-

- Considerations for creating Logical Analysis Models

- One or more of the following analysis tools can be used to create models to help understand the relationships among functions and other attributes embedded in Technical Requirements.
- Trade studies should be conducted to determine the most useful models from a cost/performance perspective.

## Considerations (cont.)

- 	Government Specific Course II

- 1-

- One key consideration is the best way to partition the logical models representing the system
- Common rule:  Maximize cohesion and minimize coupling

- Coupling: Minimize dependent interfaces
- Cohesion: Encapsulate only similar functions

- Such considerations are important enablers for later successful use of an Open System design approach

## Open System 

- 	Government Specific Course II

- 1-

- Open System

**Open System:**  One that implements specifications maintained by an open, public consensus process for interfaces, services, and support formats, to enable properly engineered components to be utilized across a wide range of systems with minimal change, to interoperate with other components on local and remote systems, and to interact with users in a manner that facilitates portability.
- If done properly, it can reduce development costs, allow for graceful technology insertion over the life of the system and reduce lifecycle costs.

## Functional Analysis

- 	Government Specific Course II

- 1-

- Using a Functional Analysis

- Can be accomplished by arranging system functions in logical sequences, then decomposing higher-level functions into their constituent sub-functions
- Ultimate output is a set of system-level functions that are to be performed by the system's End Products, sequenced by time

- This will detail the complete set of functions to be performed along with their relationships.  (represents the functional architecture of the system)

## Functional Flow Block Diagram 

- 	Government Specific Course II

- 1-

- Functional Flow Block Diagram

- A basic technique used in functional analysis is the Functional Flow Block Diagram (FFBD)

- Individual function statements are used that represent the discrete actions (described initially by subject-verb-object statements) that an end product of a system model must perform
- These are then ultimately reduced to a verb that best expresses the action needed for functional analysis and FFBD work.

## ‘Functional Decomposition’

- 	Government Specific Course II

- 1-

- ‘Functional Decomposition’

- One of the key activities in creating the FFBD is ‘functional decomposition’.

- Activities are broken down into sub-functions
- Purpose is to determine the 'best' ordering of sub-functions that must be done to accomplish the system function
- Concept of Operation (CONOPS) or other customer requirements would not typically determine such an optimal ordering

## ‘Functional Decomposition’ (cont.)

- 	Government Specific Course II

- 1-

- ‘Functional Decomposition’ (cont.)

- This determination is part of the Logical Analysis Process’
- Domain expertise of IPT members is especially critical for effective and credible functional decomposition.

## Timeline Analysis

- 	Government Specific Course II

- 1-

- Ultimate output of a functional approach is a set of all functions that is to be performed by the system or product
- These must also be sequenced by time
- Timeline analysis can help with that sequencing
- It defines the duration and sequence of various time critical functions

- 	Government Specific Course II

- 1-

- Topic 5- Review

## Learning Objectives Review

- 	Government Specific Course II

- 1-

- Discuss how each of these Technical Processes play into the Acquisition Framework.
- Describe the different Technical Processes that enables Systems Engineering to create End Products and Enabling Products that provide an integrated and total life cycle balanced set of system, people and process solutions satisfying customer needs.

## Key Points

- 	Government Specific Course II

- 1-

- Systems Engineering Technical processes can be divided into two complementary, related sets
- Processes are used repeatedly at each layer of the system structure
**Top-Down Design:**  These processes include: Requirements Development, Logical Analysis and Design Solution.
**Bottom-Up Realization:  **These processes include: Implementation, Integration, Verification, Validation and Transition.

## Key Points (cont.)

- 	Government Specific Course II

- 1-

- Part 1:  Deals with Stakeholder Requirements that reflect the needs of a customer and other interested parties.  These requirements are used to establish stakeholder satisfaction with a delivered system model End Product.
- Part 2:  Deals with Technical Requirements, which are quantified Stakeholder Requirements stated as shall requirements.  These are used ultimately to develop design solutions to satisfy Stakeholder Requirements.

- There are two parts to the Requirements Development Process:

## Key Points (cont.)

- 	Government Specific Course II

- 1-

- Requirements Development Process is the first step in arriving at a design solution for a system model.
- System design processes (Requirements Development, Logical Analysis and Design Solution) are used in defining the design solution of a system, its End Products and their subsystems

## Key Points (cont.)

- 	Government Specific Course II

- 1-

- This is also used for establishing the requirements for Enabling Products that support an End Product over its life cycle.
- These three processes are iterated at each level of the system structure and then applied recursively to lower levels of the physical architecture throughout development.

## Key Points (cont.)

- 	Government Specific Course II

- 1-

- The illustration shows that Requirements Development is tightly linked to the Technical Processes of Logical Analysis and Design Solution.

- This linkage is important since some requirements will become fully defined only through system decomposition at later stages of development.

## Key Points (cont.)

- 	Government Specific Course II

- 1-

- Stakeholders Requirements
- Derived Requirements
- Technical Requirements
- Derived Technical Requirements
- Solution-Specified Requirements

## Key Points (cont.)

- 	Government Specific Course II

- 1-

- Developed after Stakeholder Requirements and Other Interested Party Requirements have been elicited
- Should describe what activities need to be done
- Also where, when, by whom, and under what conditions they will be done

## Key Points (cont.)

- 	Government Specific Course II

- 1-

- Determining uses and operational profiles
- Documenting the steps involved
- Both textual descriptions and diagrams

## Key Points (cont.)

- 	Government Specific Course II

- 1-

- Key Performance Parameters (KPPs)
- Acquisition Program Baseline (APB)
- Trade Space
- Critical Operational Issues (COIs)
- Measures of Effectiveness (MOEs)
- Measures of Suitability (MOSs)

## Key Points (cont.)

- 	Government Specific Course II

- 1-

- Measures of Performance (MOPs)
- Critical Technical Parameters (CTPs)
- Technical Performance Measures

##  Key Points (cont.)

- 	Government Specific Course II

- 1-

-  Key Points (cont.)

- Performance parameters and constraints are allocated to these logical solutions
- Candidate functional architectures are developed
- Derived Technical Requirements to be later used for the system design are defined

- Definition: The process that obtains sets of logical solutions so as to improve understanding of the defined system Technical Requirements and the relationships among them

## Key Points (cont.)

- 	Government Specific Course II

- 1-

- Representation of the relationship of Technical Requirement attributes required to be satisfied by the physical solution
- Each attribute can be represented by a model.