DID FinderBack
Source
DI-EDRS-82290

Dynamic Object Oriented Requirements System (DOORS) Package

Defines the format, content, and use of the DOORS Database package for documenting requirements management compliance and bidirectional traceability, including subcontractor-developed requirement documents, across all DoD acquisition program phases.

Approval DateAugust 22, 2019
AMSC Number10082
Preparing ActivityMDA
Project NumberEDRS-2019-001
OPR—
DTIC ApplicableNo
GIDEP ApplicableNo
Limitation—
Applicable FormsNone
Approval Limitation—
Form Version—
DID Formatfree_text
963C CompliantYes
DISTRIBUTION STATEMENT A: Approved for public release; distribution is unlimited.
Supersedes
—
Related
—

Description & Purpose

—

Application & Interrelationship

—

Use & Relationship

This Data Item Description shall be used in preparing all ongoing, interim, or final Dynamic Object Oriented Requirements System (DOORS) Database modules. The purpose of these modules is to present compliance of requirements management and bidirectional traceability, to include management of all subcontractor-developed requirement documents.

This DID contains the format, content, and intended use information for the DOORS package. It is intended that all requirements contained herein shall apply to all applicable DoD acquisition programs through all program phases.

Preparation Instructions

1Reference documents.The applicable issue of the documents cited herein, including their approval dates and dates of any applicable amendments, notices, and revisions, shall be as cited in ASSIST at the time of the solicitation; or, for non-ASSIST documents, as stated herein.
1.1References.
1.1.1MDA Directive 5000.15, "Ballistic Missile Defense System requirements Traceability Process,"[current version via Missile Defense Agency (MDA) Portal or Secretary General Staff Action Control Office ([email protected])] as government furnished information (GFI). This Ballistic Missile Defense System (BMDS) Requirements Traceability Handbook provides detailed process for implementing and administering processes for BMDS requirements traceability within routine systems engineering and program technical reviews.
1.1.2"MDA System Verification Plan,"[current version via MDA Portal or MDA Secretary General Staff Action Control Office ([email protected])] as GFI. The MDA System Verification Plan describes the trace process and verification sequence by rollup requirements.
1.1.3MDA Policy Memorandum No. 63, "BMDS Technical Baseline,"[current version via MDA Portal or MDA Secretary General Staff Action Control Office ([email protected])] as GFI. The memorandum provides an organizational chart of the requirements/specification hierarchy.
1.1.4MIL-STD-961, "Department of Defense Standard Practice - Defense and Program-Unique Specifications Format and Content,"available at https://assist.dla.mil. The MIL-STD-961 provides requirements for the preparation of defense specifications and program-unique specifications prepared either by DoD activities or by contractors for the DoD.
2Format.
2.1Format 1 defines the DOORS Database
2.1.1The DOORS Database shall be provided in the following formats:
2.1.1.1*.DMA file type archived from DOORS.
2.1.1.2*.DLP file type archived from DOORS.
2.1.1.3*.PDF file type from Adobe.
2.1.1.4*.XLSX file type from Microsoft Excel.
2.1.2The respective DOORS Package Contract Data Requirements List (CDRL) shall specify versions as an additional requirement.
2.2Format 2 defines the Trace Certification Memorandum (TCM)
2.2.1*.PDF file type from Adobe.
2.3Format 3 defines the Prime Item Description Specification (PIDS)
2.3.1*.PDF file from Adobe and IAW MIL-STD-961.
2.4Format 4 defines the Requirements Traceability Verification Metrix (RTVM)
2.4.1*.XLSX file from Microsoft Excel.
2.5Format 5 defines the Specification Tree
2.5.1In contractor format and machine-readable by the Government.
3Content.
3.1DOORS Database shall consist of the following:
3.2TCMis a certification of Element Requirements Trace as defined in DOORS Partition and shall contain:
3.3PIDS shall contain:
3.3.1PIDSFormat and content of performance specification shall be IAW MIL-STD-961, paragraphs 4.1 through 5.14
3.3.2PIDS SheetFormat and content of performance specification sheets shall be IAW MIL-STD-961, paragraphs 5.16 through 5.16.4
3.3.3PIDS RevisionFormat and content of performance specification revisions shall be IAW MIL-STD-961, paragraphs 5.17 through 5.17.2
3.3.4PIDS SupplementFormat and content of performance specification supplements shall be IAW MIL-STD-961, paragraphs 5.15 through 5.15.9
3.3.5PIDS AmendmentFormat and content of performance specification amendments shall be IAW MIL-STD-961, paragraphs 5.18 through 5.18.7
3.3.6PIDS Inactive for New Design NoticeFormat and content of inactive for new design notices shall be IAW MIL-STD-961, paragraph 5.19.2
3.3.7PIDS Cancellation NoticeFormat and content of cancellation notices shall be IAW MIL-STD-961, paragraph 5.19.3
3.3.8PIDS Reinstatement NoticeFormat and content of reinstatement notices shall be IAW MIL-STD-961, paragraph 5.19.4
3.3.9PIDS Reactivation NoticeFormat and content of reactivation notices shall be IAW MIL-STD-961, paragraph 5.19.5
3.3.10PIDS Administrative NoticeFormat and content of administrative notices shall be IAW MIL-STD-961, paragraph 5.19.6
3.4RTVM shall contain:
3.4.1Cover Page and DocumentationThe RTVM software database files shall contain the following:
3.4.1.1Cover PageEnter the Title, Date of Issue, Revision Date Contract Number, Contractor's name and address, Distribution Statement (as delineated in the contract), Export Control Warning Label (as delineated in the contract and if applicable), and Security classification.
3.4.1.2Record of Change PageEnter a record of all changes made to the RTVM.
3.4.1.3Database Architecture Description PagesEnter a detailed description of the database, show relationships and define all the terms, acronyms used in the database fields.
3.4.2Data DescriptionDescribes the data to be contained in the RTVM relational database.
3.4.2.1Unique Identification Number (UID)Enter the UID for every requirement in the system configuration baseline (functional and physical).
3.4.2.2Source documentFor each specification and source document, enter the document number and title for the source of each requirement statement.
3.4.2.3Specification or Source Document Paragraph NumberEnter the specification or source document paragraph number for each requirement.
3.4.2.4Requirement TextEnter the specification or source document requirement text.
3.4.2.5Requirement TraceabilityFor each requirement, identify and show the traces between all other requirements for within specification tree layers and the system configuration items.
3.4.2.6Requirement TypeThe RTVM database shall identify if the requirement is derived or decomposed from a parent requirement.
3.4.2.7Requirement AttributeFor each requirement define whether the requirement is a measure of performance, design parameter, software functional requirement, interface requirement, physical parameter, core standard, environmental and cybersecurity (This data field can encompass other data attributes if needed.)
3.4.2.8Requirement StatusIdentify the Requirement status for each requirement, as approved, under review. The status shall identify the latest revision number.
3.4.2.9Non-Conforming RequirementsFor non-conforming requirements, enter the System Trouble Report (STR) and/or Deficiency Report (DR) number and title.
3.4.2.9.1HyperlinkProvide hyper-link to the STR and DR databases.
3.4.2.10Design ReferenceEnter the specific piece of design information (i.e., design document section, drawing, etc.) associated with each requirement.
3.4.2.11Requirement AllocationEnter the specific system, subsystem, hardware item, component, Computer Software Configuration Item, Computer Software Component and Computer Software Unit that each requirement has been allocated. System level (e.g., Element Specification) requirements shall be allocated to all Configuration Items defined for the system.
3.4.2.12Form of End ProductEnter the form and maturity level of the end product used for verification. For example the form can be the system, subsystem, unit level, software configuration Item and the maturity level can be the first article, production representative, prototype or final configuration item.
3.4.2.13Verification MethodFor each requirement, enter the verification method as follows IAW MIL-STD-961, Section 4-Verification (5.9):
3.4.2.13.1AnalysisAn element of verification that uses established technical or mathematical models or simulations, algorithms, charts, graphs, circuit diagrams, or other scientific principles and procedures to provide objective evidence that states requirements are met.
3.4.2.13.2DemonstrationAn element of verification that involves the actual operation of an item to provide objective evidence that the required functions were accomplished under specific scenarios. The items shall be instrumented and performance monitored.
3.4.2.13.3ExaminationAn element of verification that is generally nondestructive and typically includes the use of sight, hearing, smell, touch, and taste; simple physical manipulation; and mechanical and electrical gauging and measurement.
3.4.2.13.4TestAn element of verification in which scientific principles and procedures are applied to determine the properties or functional capabilities of items.
3.4.2.14Verification DocumentEnter the document number, title, and date of the verification document that contains the verification method.
3.4.2.15Verification Document ParagraphEnter the verification document paragraph number that provides the verification method.
3.4.2.16Verification ProcedureEnter the verification procedure section, and verification procedure step(s) that provides the verification method for each requirement.
3.4.2.17Other TestsEnter the names of other tests conducted, prior to verification of the requirements, where the requirements are tested.
3.4.2.18Verification ResultsEnter the results of the verification for each requirement. Did system under test conform to the requirement? (Yes, No).
3.4.2.19Corrective ActionsEnter all corrective actions taken and the results of the corrective actions.
3.4.2.20CommentsEnter explanatory notes as required.
3.5Specification Tree shall illustrate the documentation of decomposition flowing from the Government source requirements down to the PIDS and Component Specifications.
3.5.1Top LevelGovernment Source (System Specification (SS), Element Specification (ES), Interface Control Document(s) (i.e., System Interface Control Document (SICD), Interface Control Document (ICD), etc.), Facilities Requirements Document (FRD), etc) traced to PIDS and/or Element Specification.
3.5.2Second LevelCritical Components (i.e., SRS, SDD, HRS, HDD, etc.) traced from Top Level and PIDS.
3.5.3Lowest LevelComponent Specification (if applicable, for each major component and can be separate tree from higher levels) traced from previous level(s).

References

—

Figures

Figure Table 1: DOORS Database Attribute Table (Attributes 1-8)

Figure Table 1. DOORS Database Attribute Table (Attributes 1-8)

Figure Table 1 (cont.): DOORS Database Attribute Table (Attributes 9-31, continued)

Figure Table 1 (cont.). DOORS Database Attribute Table (Attributes 9-31, continued)

Figure Table 2: TCM Certification Items (Element Requirements Trace)

Figure Table 2. TCM Certification Items (Element Requirements Trace)

Figure 5.1: Specification Tree Example

Figure 5.1. Specification Tree Example

Schema v3.0Community-maintained · Verify against ASSIST
Community-maintained — not an official government database.
Verify against ASSIST·GitHub·About·Disclaimer