1 Lecture 2.3: SE Process (SEF Ch 3) Dr. John MacCarthy UMBC CMSC 615 Fall, 2006

2 The Scope of Systems Engineering Per DSMC SEF Guide Part 1: Introduction Ch. 1Introduction to SE Management Ch. 2Systems Engineering Management in DoD Acquisition Part 2: SE Process Ch. 3Systems Engineering Process Overview Ch. 4: Requirements Analysis (Wk 4) Ch. 5: Functional Analysis (Wk 5-10) Ch. 6: Design Synthesis (Wk 5-7, & 12) Ch. 7: Verification (Wk 12) Ch. 8: Systems Engineering Process Outputs (Wk 3-11) Part 3: System Analysis and Control Ch. 9: Work Breakdown Structure (Wk 3) Ch. 10: Configuration Management (Wk 10) Ch. 11: Technical Reviews and Audits (Today) Ch. 12: Trade Studies (Wk 11) Ch. 13: Modeling and Simulation (Wk 11) Ch. 14: Metrics (Wk 11) Ch. 15: Risk Management (Wk 11) Part 4: Planning, Organizing, & Managing Ch. 16: Systems Engineering Planning (Wk 3) Ch. 17: Product Improvement Strategies (Wk 2) Ch. 18: Organizing and Integrating System Development (Wk 3) Ch 19: Contractual Considerations (Today) Ch 20: Management Considerations and Summary

3 SE Process (Ch 3) Activities: Requirements Analysis Functional Analysis Design Synthesis Verification System Analysis and Control Inputs: Customer Needs, Objectives, Requirements Higher-Level Requirements Constraining Specifications and Standards Technology Base Constraints Decision Requirements Outputs: Specification & Other Baselines System/Configuration Item Architecture Decision Data Base Note: Classically the SE Process is repeated in three design phases: Conceptual, Preliminary and Final Note: SEF uses IDEF0 model to describe the SE Process Note: The SE Process is essentially the Waterfall

4 The SE Process (3.1) [1] The SE Process: Comprehensive, iterative and recursive problem solving process applied sequentially top-down by integrated teams Operational Requirements/Operational Architecture System Requirements/Conceptual Design Design Requirements/Preliminary Design Final Design Transforms needs and requirements into a set of system product and process descriptions Generates information for decision makers Provides input for the next level of development

5 Systems Engineering Process (3.1) [2] Requirements Analysis: Discover customer requirements (and “desirements”) Transform these into functional (what) and performance (how well) requirements for the system Identify design constraints Functional Analysis: Develop the “Functional Architecture” Decompose higher-level functions requirements Decompose performance requirements Allocate performance requirements to functions. Note this generally includes control and data flows, as well as conceptual data structures Requirements Loop: Establish up and down trace to ensure all parent requirements have been addressed and that all derived requirements have parents (to prevent scope creep or gold plating) Discovery of “missing” requirements

6 Systems Engineering Process (3.1) [3] Design Synthesis: Develop the “Physical/ Software Architecture” Define the product in terms of its physical and/or software elements/ components Each component meets one or more (“leaf-node”) functional requirement CI components serve as the basis for generating allocated specifications and design packages Allocate functions to components to serve as basis for allocated specifications (or design) Develop data models Design Loop: Establishing traceability between design (Physical/SW Architecture) and requirements (Functional Architecture) Sometimes results in modification of the requirements and/or functional architecture Verification: Examination, Demonstration, Analysis, and/or Testing of the design/product to verify that it meets its requirements Formal T&E of product Consider impact of Legacy systems/components

7 Systems Engineering Process (3.1): Systems Analysis and Control [4] Aspects of Systems Analysis and Control Technical Management Analysis: trade(-off) studies, (cost-) effectiveness studies, design analyses, performance analysis Evaluate alternative approaches Demonstrate expected performance (risk mitigation) Risk Management Configuration Management Data Management Performance Measurement (EV & TPMs) Technical Reviews Purpose of Systems Analysis and Control: Solution decisions are made only after evaluating impact on system effectiveness, live cycle resources, risk, and customer requirements Technical decisions and specification requirements are based on SE outputs Traceability is maintained Schedules are mutually supportive Technical disciplines are integrated into the SE effort Functional and performance requirements are examined for validity, consistency, desirability, and attainability Identification & prioritization of conflicting customer (technical) requirements and environmental and programmatic (cost/ schedule) constraints Product & process design requirements are directly traceable to functional and performance requirements they were designed to fulfill (and vice versa)

8 Summary Points (3.2) The SE Process is the engine that drives balanced development of system products and processes applied to each level of development Process provides increasing level of descriptive detail with each SE process application. The output of on application is the input to the next