Nasa osma sas 03
1 / 15

NASA OSMA SAS ‘03 - PowerPoint PPT Presentation

  • Uploaded on

NASA OSMA SAS ‘03. Software Requirements Analysis As Fault Predictor Dolores R. Wallace SRS Technologies Software Assurance Technology Center [email protected] William M. Wilson SRS Technologies/SATC [email protected]

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about ' NASA OSMA SAS ‘03' - topaz

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Nasa osma sas 03

Software Requirements Analysis

As Fault Predictor

Dolores R. Wallace

SRS Technologies

Software Assurance Technology Center

[email protected]

William M. Wilson

SRS Technologies/SATC

[email protected]


Software requirements analysis as fault predictor
Software Requirements Analysis As Fault Predictor

Presentation Outline

  • Research Rationale & Objective

  • Requested Project Data

  • Planned Approach

  • Data Acquisition & Analysis Obstacles

  • Results & Findings

  • Conclusions

  • Recommendations


Research rationale objective
Research Rationale & Objective


  • The earlier in the lifecycle that software faults can be found the less expensive it is to correct them.

  • The earliest opportunity to preclude software faults is during the development of the system's requirements.


  • To determine if software requirements analysis results can be used as a predictor of software faults.


Requested project data
Requested Project Data

  • Requirements Specification

    • Accessible in electronic media in MS Word format for use with the ARM tool

    • Conforming to NASA-STD-2100

    • Specification statements identified by hierarchical numbers


Requested project data cont
Requested Project Data – Cont.

  • Verification Test Matrix

    • Requirements to Test or vice versa

      - OR -

  • Traceability Matrix

    • Requirements to Design Elements

    • Design Element To Software Component

      - AND -

  • Test Plans

    • Tests vs. Software Components.


Requested project data cont1
Requested Project Data – Cont.

  • Failure Reports/Data

    - Preferably in DDTS format

    • Including: test id, module id, CSCI id, release/build id, suspected cause of failure and resolution (e.g., actual cause of failure - what was fixed)

  • Configuration Control Reports

    • Baseline item changed -e.g., Requirement, Design, Code

    • Reason/Source of change – e.g., RID, Failure Report, PR, etc.


Planned approach
Planned Approach

  • Use ARM tool to analyze projects’ software requirements.

  • Collected projects’ failure data in a DDTS database.

  • Organize the data to represent same components for each project.

  • Conduct correlation analysis.

  • Study results of step 4 to prove or disprove hypothesis.


Arm tool reports
ARM TOOL Reports

Identifies and Counts:

  • Size of Requirements Document

    • Lines of Text

    • Numbered Paragraphs

    • Number of Specification Statements

    • Number of Unique Specification Subjects

  • Number of Specifications Containing

    • Weak, Optional and/or Incomplete Phrases.

    • Compound and/or Complex Statements.

  • Requirements Document Structure

    • Depth and Distribution of Specifications


Data acquisition analysis obstacles
Data Acquisition & Analysis Obstacles

  • Common Problems

    • No commonality or standardization of data or formats across project.

    • Current projects are reluctant to provide data to outside organizations.

    • Data from completed projects is incomplete, not in a usable form or is not accessible.


Data acquisition analysis obstacles cont
Data Acquisition & Analysis Obstacles Cont.

  • Specific Problems

    • No project staff available to guide through the mass of documents in the collection

    • Documents locked on a WEB site

    • Documents in “.pdf” format

    • Variation of format and media within project

    • Complete set of data for a specific Build/Release not available

    • Data held by support contractor and released only on a “Project Need-To-Know” basis


Results findings
Results & Findings

  • Data provided by four projects

    • Projects A and B

      • Major subsystems of operational information processing system

    • Projects C and D

      • Flight instrumentation packages


Results findings cont
Results & Findings Cont



  • Data from many more projects is required to improve the possibility of finding a number of data sets with sufficient commonality to support analysis.

  • Analysis approach needs to be expanded to include determining if failures attributed to documentation and design flaws are in reality related to deficiencies in requirements.



Advocate and support:

  • The use of NASA-STD-2100 documentation standard

  • The use of a format to report problems and failures that is compatible with DDTS

  • The creation and use of centralized Center repositories for data from completed projects.



  • Lessons

    • Getting data requires strong, interested Civil servant advocate

    • Analyzing data requires tedious effort, even with automated tools

  • Future

    • Analyze latest set of data

    • Attempt correlations for the 4 data sets