Haught Visual Analysis of Requirements Flowdown - September 15-17, 2010 Workshop Presentation

Sep 11, 2026

Uploaded by Bintang

This presentation describes techniques developed by the IV&V Program for visual analysis of requirements flowdown, tracing capabilities from top-level requirements to lower-level software components. Beginning in 2007, analyses moved beyond Excel and Access spreadsheets by leveraging Microsoft Project’s network diagramming features. The approach helps identify traceability issues across multiple boundaries, supports risk-based assessments, and has been applied on NASA projects including Constellation, Ares, and Global Precipitation Measurement (GPM).

LanguageEnglish

CategoryPresentations

FormatPDF

Pages17

Reading Time6 min

AccessFree to download

Background

Driving Event

Lesson Learned

Analyze Trace Connectivity

Parse Trace Table

Consolidate Trace Links

Look for Circular References

Walk-Through: Customizing an MS Project View

Haught Visual Analysis of Requirements Flowdown Visual Analysis of Requirements Flowdown Kenneth M. Haught TASC, Inc. NASA IV&V Program 2010 Annual Workshop on Validation and Verification Fairmont, WV September 15—17, 2010 Abstract This presentation describes techniques that have been developed by the IV&V Program for visual analysis of requirements flowdown from top–level capabilities to lower–level software components. Beginning in 2007, IV&V analyses typically performed in Excel spreadsheets or Access databases were expanded to leverage the network diagramming features within Microsoft Project. This approach allowed an IV&V analyst to ―see‖ beyond adjacent interfacesand to visually explore system–integration issues by examining traceability across multiple boundaries. The IV&V Program has used these techniques to identify development issues on NASA projects such as Constellation and Ares, as well as supporting its internal risk–based assessments (RBAs) needed for prioritizing future IV&V activities on projects such as the Global Precipitation Measurement (GPM) effort. This work has been partially supported under NASA Contract NNG-05CB17C 1 of 17 Haught Visual Analysis of Requirements Flowdown 2 of 17 Acronyms CARD Constellation Architecture Requirements Document FSW Flight Software GPM Global Precipitation Measurement ICESat-2 Ice, Cloud, and land Elevation Satellite 2 ID Identifier IV&V Independent Validation and Verification MS Microsoft NASA National Aeronautics and Space Administration PBRA Portfolio Based Risk Assessment RBA Risk Based Analysis TIM Technical Issue Memorandum WV West Virginia Haught Visual Analysis of Requirements Flowdown 3 of 17 Background Driving Event: IV&V found tangled traces in the Constellation Architecture Requirements Document (CARD) This problem affected over 100 individual requirements. A Technical Issues Memorandum (TIM) was submitted to the Project in October, 2007 A diagram highlighting this issue for 24 selected requirements was included in a briefing presented to the Project in February 2008 – and drew a far more motivated response than the detailed technical description submitted four months earlier. Lesson Learned: While the value of diagrams like these was clear, developing them at the end of an analysis takes effort and time (usually at a time when deadlines begin to press) . Any tools used for generating these diagram should also be used during the analysis itself (thereby saving time) . Haught Visual Analysis of Requirements Flowdown 4 of 17 Analyze Trace Connectivity Goal in Context: A requirements-trace table contains parent-child links that can be used to produce a network diagram for analyzing trace complexity. Success Guarantee: This activity produces a network diagram showing requirements flowdown, along with a listing of any trace errors encountered. Main Success Scenario: 1 Parse trace table 2 Consolidate trace links 3 Look for circular references 4 Diagram links Haught Visual Analysis of Requirements Flowdown 5 of 17 Parse Trace Table Goal in Context: IV&V receives requirements-trace information from many sources (including documents and on-line tools), from which the needed parent-child trace pairs must be extracted for further analysis. These sources present the information in a wide variety of formats and may contain errors (such as duplicate entries, childless parents and orphans) . Success Guarantee: This activity will produce a ―clean‖ list of parent-child pairs (in an Excel spreadsheet with one row per pair), along with a listing of any trace errors encountered. Main Success Scenario: Notes tab lists detailed steps 1 Paste copy of trace source into an Excel spreadsheet 2 Copy parent and child identifiers (and any related info) to separate tab 3 Remove blank rows (if any) 4 Replicate info that had been removed to improve readability (as needed) 5 Search for dupl

FAQs

What is the goal of the requirements-trace visualization approach described here?

It produces a network diagram that shows requirements flowdown and highlights trace errors by analyzing parent-child connectivity and complexity.

How does the method start when trace data comes from many sources?

It parses trace tables by extracting parent-child identifier pairs from varied formats, then cleans duplicates, orphaned, and childless entries.

What types of trace problems are specifically checked before diagramming?

The presentation focuses on circular-reference errors, including both direct (A↔B) and indirect cycles (A→B→C→A).

Sep 11, 2026

Uploaded by Bintang