# Presentation: 942772

## Requirements Decomposition Analysis

**Dr. Martin S. Feather,  Dr. Allen P. Nikora**
**Jet Propulsion Laboratory,**
**California Institute of Technology**
**&****Dr. Jane Oh**
**Wayne State University****(JPL Summer Faculty Fellow, 2003)**
- Presented by Martin.S.Feather@Jpl.Nasa.Gov

- This research was carried out at the Jet Propulsion Laboratory, California Institute of Technology, under a contract with the National Aeronautics and Space Administration. Work sponsored by the NASA Office of Safety and Mission Assurance under the Software Assurance Research Program led by the NASA Software IV&V Facility. This activity is managed locally at JPL through the Assurance and Technology Program Office.

## Roadmap

** ****Requirements Decomposition:****      Means to perform ****analysis**** (check decomposition done correctly)**
** ****Example 1: Study of Science Experiment’s Requirements**
** ****Simple consistency checking**
** ****Additional complexity arises when timelines involved**
** ****Example 2: Study of an Entire Flight Project’s Requirements**
** ****Sheer volume of requirements!**
** *****Existing***** capabilities for traceability**
** *****New***** capability for traceability closure**
** ****Extracting relevant requirements *****without***** relying on existing traceability**
** ****Motivation**
** *****New***** capability for text-search based retrieval, & example**
** ****Status & Future**

## Motivation – Mars Polar Lander

***Mars Polar Lander / Deep Space 2 Loss – JPL Special Review Board Report*****JPL D-18709 – page 120**

## Analysis

- Level1 Requirements	System Requirements
- Level2 Requirements	Software Requirements
- Level3 Requirements
- ...

*a.k.a. “Requirements Flowdown”*

**If decomposition is incorrect between a pair of levels’ requirements, how might this be detected?**
**Knowledgeable designers/coders/testers notice something amiss**** **
**System fails validation test (behavior does not match high-level requirements)**** **
**Inspection/review of the two levels of requirements**

**Not thorough or systematic ****(CMM level 1)**

**Imperfect****– can’t test everything**** **

**This CI’s purpose is to improve our ability to do this!**

## α

- 2.1.7 The β CDS shall have 49.5 MB of RAM per spacecraft continuously available for the <System> software image to run during <System> experiment time. Of this only 24MBytes is for <System>-specific planning software, the remainder is carried in the CM RAM budget.
**Running Code Size**
**γ** Core  + scripts/rules        0.5MB **γ** Database 	        3MB **α** 		      24MBObservation Planner 	        2MBCluster Manager Logging 20MB
**Total ****	****	****       49.5MB**

**α**

- β

- Study: Science Experiment’s Rqmts

**Simple consistency checking**

**(identities are being deliberately obscured in this material)**

## β

- Study: Science Experiment’s Rqmts

**Timelines introduce additional complexity**

**Level 2 and level 3 requirements:****approximately 9 pages in total**

## Scale:  sheer volume of requirements!

**  ****(1 of) Mission operations requirements module****	****235 requirements**
**  ****(5 of) Level 2 requirements modules:****	**** 1,370 requirements**
**  ****(1 of) Level 2.5 requirements module****	****550 requirements**
**  ****(5 of) Level 3 requirements modules:****	**** 840 requirements**
**  ****(8 of) Level 4 requirements modules:****	****1,595 requirements**

- Study 2: An Entire Flight Project

**Scale:  sheer volume of requirements!**

**(identities being deliberately obscured in this material)**

- This project (and others) keeps Requirements & traceability information DOORS © Telelogic

## Tracing Decomposition StructureExisting Capabilities

**Parent**

- Partial screenshot of DOORS in “graphics mode”

**Children**

**Parent’s siblings**

***= ******Continued in other modules***

- (© Telelogic)

## Tracing Decomposition StructureNew Capability

**Transitive closure of traceability**

** ****Automated script**
** ****Traverses traceability links in *****both***** directions**
** ****Traversal continues over module (level) boundaries**
** ****Results assembled into single hyperlinked HTML table**
** ****Yields comprehension of decomposition neighborhood****	****(e.g., if considering impact of changing a requirement)**
** ****Future refinements possible (e.g., inhibit tracing through...)**

## Why?

**Why?**
- While the Project, SQA & IV&V should and will continue to use existing traceability information (e.g., does every requirement trace to a test case? Do the traced-to requirements achieve the traced-from requirement?), nevertheless...
**For assurance purposes, don’t want to *****rely***** on completeness and correctness of existing traceability information.**

## Extracting Relevant Requirements Without using Existing Traceability

**Search for “****mass****” (potentially many results)**
**Search for *****units***** of mass: “****kg****” (potentially many results)**
**Search for “ ****[digit] kg**** ” (yields small set of results)**
**Note: may need to search for multiple units, e.g., bits per second expressed in ****Gbps****, ****Mbps****, ****Kbps**** and ****bps****!**
**[0-9]( )[G|g|K|k|M|m|()]bps**

**From the ENTIRE set of project requirements, extract only those dealing with a resource,****e.g., mass allocation**

## Extracting Relevant Requirements Without using Existing Traceability

**Spacecraft Requirements:****The spacecraft shall be designed for a maximum orbiter launch mass of 2180 kg and shall accommodate the following allocations:****Spacecraft Wet Mass -   ****	****	****1988.0 Kg****Instruments -            ****	****	****  139.0 Kg****E... - ****	****                ****	****	****    17.5 Kg****Project Manager Reserve - ****	****    35.5 Kg**

**Project System Requirements:****Launch Mass: The PS shall be designed for a maximum injected mass of 2180 kg.**
**The PS shall be designed to accommodate 156.5 kg [including all reserves] of Payload mass.**
**The PS shall accommodate a reserve of 35.5 kg to be allocated by the project manager**

- “**[0-9]( )[K|k]g**” yields 15 requirements dealing with mass.Here are several of them:

## Status & Future

** ****ACCOMPLISHED **
**Automated transitive closure script:**
** ****implemented as PERL script that operates on HTML files as exported from DOORS**
** ****Regular-expression text-based searches:**
** ****carried out using DOORS search and filter capabilities:**
** ****search the project to identify the modules**
** ****filter those modules to just those requirements**
** ****FUTURE WORK:**
**Implementation:**
**Both could be implemented as scripts within DOORS (using DOORS scripting language DXL)**
** ****Both amenable to other requirements repositories**
*** ******Refine closure script! Extend searches! Look at checking!***