1 / 12

Lecture 5.2a: SEF Ch 8 SE Outputs

Lecture 5.2a: SEF Ch 8 SE Outputs. Dr. John MacCarthy UMBC CMSC 615 Fall, 2006. Agenda. Requirements Background Documenting Requirements and Design (8.1) Specification Levels and Specification Trees Specification Generation Decision Database Programmatic and Configuration Baselines

cornelia-corbin
Download Presentation

Lecture 5.2a: SEF Ch 8 SE Outputs

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  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. 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 … Requirements Background

  4. 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) 1st 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 Documenting Requirements and Design (8.1)

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

  6. 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) Levels of Specifications and Specification Trees

  7. 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 Specification Generation, Architecture Generation, and the Development Life Cycle

  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. 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. Program Baselines: SEP, CMP, RMP, TEMP PMP, IMS Other selected programmatic outputs Configuration Baselines: Specifications Interface Documents Architecture Artifacts Other selected SE Outputs Program and Configuration Baselines

  11. 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 Specification Specifications

  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)

More Related