RASSP Definition and Role of Executable Requirement (ER-SPEC) and Design (ED-SPEC) Specifications Appnote

Abstract

An executable requirement specification communicates a detailed, unambiguous set of customer requirements to the contractor(s) who will bid on or fabricate the hardware/software elements of a project. Execution of the ER-spec corresponds to evaluation of conformance of a design to the requirements contained in the ER-spec. An executable design specification defines how project-specific design information is to be evaluated. Execution of the ED-spec corresponds to assignment of project parameter values which will be measured against the requirements in an ER-spec. This note describes the contents of hierarchical ER-specs and ED-specs and demonstrates how they capture and expresses both customer intent and detailed project requirements.

Purpose

This application note provides definitions for the RASSP view of executable requirements and specifications. It also describes the role each should play in the development of a new system and/or product. Benefits are described and a process is established for the use of these concepts. Though the LM/ATL RASSP program did not spend alot of time refining and using this technology, it matches well with the RASSP concept of a risk driven hierarchical virtual prototyping process. This work has also be complemented by the work done on the CEENSS program. A Case Study [CEENSS]reference document from this program has been incorporated in the reference section of this application note.

Roadmap

1.0 Introduction

2.0 Methodology Description

• 2.1 Requirements and Their Properties
  • 2.1.1 Quantitative or Qualitative Requiements Classification
  • 2.1.2 Measurable Requirements
  • 2.1.3 Requirement Source
• 2.2 Rationale for Executable Requirement and Specification Methodology
  • 2.2.1 Executable documents support methodology automation at all packaging levels
  • 2.2.2 Executable Requirements and Design Specification Independence from the Physical System
  • 2.2.3 Removal of Ambiguity
  • 2.2.4 Permanent Records Provide Life-Cycle Support
  • 2.2.5 Readily Distributed Standalone References
• 2.3 Relationship Between Executable Requirement and Design Specifications
• 2.4 Constituents of an Executable Requirement Specification
• 2.5 Customer-Generated Executable Design Specification Level Zero (ED-spec0)
• 2.6 The Contractor Executable Design Specification (ED-specN)
• 2.7 Procedures for Creating Executable Requirements and Design Specifications
• 2.8 Roles of Customer and Contractor

3.0 Application Example

• 3.1 Benchmark 4 (SAIP) Project Description and Specification of Requirements
• 3.2 Stepwise Application of Methodology
  • 3.2.1 Creation of the Written Requirement Specification
  • 3.2.2 Extraction of Executable Requirements
  • 3.2.3 Derivation of Consolidated Test Requirements
  • 3.2.4 Definition of an Executable Design Specification
  • 3.2.5 Economics of Executable Requirements

4.0 Conclusions and Recommendations

• 4.1 Conclusions
• 4.2 Recommendations

5.0 References