1. 1 Lecture 5.2a: SEF Ch 8 SE Outputs Dr. John MacCarthy UMBC CMSC 615 Fall, 2006

2. 2 Agenda Requirements Background Documenting Requirements and Design (8.1) Specification Levels and Specification Trees Specification Generation Decision Database Programmatic and Configuration Baselines Documents Specifications for Specifications Policy and Practice (8.2) Summary (8.3)

3. 3 Requirements Background Definitions: Requirement: Something the user needs the system to do An attribute or property the user needs the system to have Constraint: Something that places a limit (constraint) on the design of the system Examples: Use of legacy components Use of legacy communications infrastructure or protocols Use of a specific hosting platform, operating system, or other HW or SW Use of a specific language Levels of Requirements: Operational/User System (Subsystem/Element) Component (CI) (Major) Software Component (CSCI) Design Parentage: Stated Requirements Derived Requirements – Child (Decomposed) Derived Requirements - Implied Types of Requirements Functional A statement of an activity the system must perform Specified as a verb phrase Eg., “Register a student” or “Verify User” Non-Functional - Performance: A specification of how well the system (component) must perform a function (e.g., “X shall complete registration in less than 1 min.” or “The probability of correct verification shall be greater than 0.999”) A quantitative measure of a required attribute (e.g., “X shall weigh less that 100 kg”) Non-Functional – Interface: The specification of an external system (or human) with which the system must interact The specification of the data, protocols, and/or communications media that are to be used to provide an interface There can also be internal interface requirements between CIs Non-Functional – Specialty: Reliability, Availability, Maintainability Information Assurance, Security, Safety Integrated Logistics Support Training Transportability Disposal …

4. 4 Documenting Requirements and Design (8.1) System Architecture: Describes entire system: Prime Item Physical Architecture (to CIs/SCSI level) + Allocated Functional Architecture: DoDAF SVs Enabling Products and Services for life cycle employment, support, & management Outlined in WBS (per MIL-HDBK- 881) 1 st three levels by customer Lower levels by Contractor Specifications: Purpose Clearly & accurately describe the essential technical requirements for the system Guide Design Basis for Testing Avoid duplication and inconsistency Basis for estimating work/resources Basis for negotiations (customer/ contractor and with user) Levels CDD (Operational Baseline) System Requirements (Functional Baseline) Item Performance Specification (Allocated Baseline) Design Baseline

5. 5 System Architecture & Levels of Specifications System Architecture (in WBS): System Specification for the PMP Item (Software) Specs for the CIs (CSCIs) Levels of Requirements Specifications:

6. 6 Levels of Specifications and Specification Trees System (Functional) Specifications Generally there is one System Specification Identifies System Level: Functional Requirements Performance Requirements Interface Requirements Constraints Other Requirements Item/Software (Allocated) Specifications Generally there are N Item/SW specifications (one for each CI/CSCI) System Specification Identifies Item-Level Requirements and Constraints Design/Detailed (Product) Specification Generally there are N Item/SW specifications (one for each CI/CSCI) System Specification Provides detailed description of product Spec Tree: Shows Traceability relationships between Specifications (& Interface Control Documentation)

7. 7 Specification Generation, Architecture Generation, and the Development Life Cycle Requirements Analysis Stage: Ends with SRR Capabilities List Concept of Operations Draft System Spec Draft Operational Architecture System Requirements Stage Ends with SFR System Specification System Interface Specification Requirements Trace to/from CDD Operational Architecture System-level Functional Architecture Complete Mid-Level Functional Decomposition Logical Data Model Complete Conceptual Design (Physical Subsystem Architecture) Allocation of Functions to Conceptual Design Requirements Trades/Analyses Preliminary Design Stage Ends with PDR Complete Identification of CIs/CSCIs (N) Item Performance Specifications (N) Software Requirements Specifications Item Interface Requirements Specification(s) Item/SW Specification trace to/from System Specification Complete System Architecture Complete (Item-level) Functional Architecture Complete Preliminary Design (CI Architecture) Allocation of Functions to Preliminary Design Design Trades/Analyses

8. 8 The Decision Database Decision Database is the documentation that supports and explains the configuration solution decisions. It includes: Trade Studies Cost-effectiveness Analyses Data generated to understand a requirement Alternative solutions & information used to select the preferred solution It is controlled as part of the CM process

9. 9 DoD Policy and Practice (8.2) DoD uses Specifications to communicate product requirements Standards to provide guidance concerning proven methods and practices. DoD uses 3 classes of specifications: Material Specifications Program Unique Specifications: MIL-STD-961D Non-DoD Specifications: DoD Index of Specifications and Standards (DoDISS) DoD Policy Government develops Performance Specifications Desired results with criteria Not methods for achieving Contractor develops Detail Specifications Joint Technical Architecture (JTA) provides a list of interoperability standards that are expected to be employed in DoD systems (and which support Open Systems)

10. 10 Program and Configuration Baselines Program Baselines: SEP, CMP, RMP, TEMP PMP, IMS Other selected programmatic outputs Configuration Baselines: Specifications Interface Documents Architecture Artifacts Other selected SE Outputs

11. 11 Specification Specifications MIL-STD-691D, Standard Practice for Defense Specifications DoD Standard for performance and detailed specifications Format and content of system, configuration item, software, process, and material specifications DoD Index of Specifications and Standards IEEE/EIA 12207, Software Life Cycle Processes IEEE-830-1998, IEEE Recommended Practice for Software Requirements Specifications

12. 12 8.3 Summary System Engineering Process Outputs include: System (including CI) Architecture (including associated products and services) Specifications (Systems, Item/Software/Interface, & Design (Item/SW/ Interface Design/Description, Process Spec, & Material Spec) (Technical) Decision Database System Specs describe system requirements, Item Performance Specs describe configuration item requirements, Item Detail Specs Configuration baselines are used to manage and control the technical development The Decision Database includes those documents aor software that support understanding and decision making during the formulation of the configuration baselines DoD Policy requires the development of Performance Specifications. Other specifications must be justified and approved. DoD Policy is to NOT require standard management approaches or manufacturing processes on contracts. Mandatory use of some standard practices are necessary, but must be justified (e.g., JTA)