In systems engineering circles, it is well known that requirements management capability improves the likelihood of success in the team-based development of complex multidisciplinary systems. Two key elements of this capability are an ability to identify and manage requirements during the early phases of the system design process. This is when errors are cheapest and easiest to correct. Methodologies for the team development of system-level architectures need to support the following activities:
Throughout the development process, teams need to maintain a shared view of the project objectives, and at the same time, focus on specific tasks. It is the responsibility of the systems engineer to gather and integrate subsystems and to ensure ensure that every project engineer is working from a consistent set of project assumptions.
A Typical Application at NASA
Figure 1 is a high-level schematic of layered requirements development at NASA Goddard Space Flight Center. Generally, layers of requirements correspond to levels of responsibility.
Figure 1. Layered Development and Organization of Requirements at NASA Goddard
Initially, the requirements elicitation process is motivated by a statement of "mission objectives" that will aim to advance our scientific understanding in one or more ways. Levels 1 and 2 focus on the definition of "science" and "high-level engineering" requirements, respectively. At Level 3, engineering requirements are organized into clusters (e.g., ground segment; communications segment; satellite segment) suitable for team development. Requirements at Levels 4 and 5 may be directed to a specific sub-system (e.g., an instrument that will fly on a satellite) or component (e.g., a circuit board).
Representing Requirements with Graph Data Structures
When requirements are organized into layers for team development, graph structures are needed to describe the comply and define relationships among requirements.
As we will soon see, when software tools employ a tree-based model to display relationships among requirements, gaps appear between the visual representation and the underlying graph-based data structures. Systems engineers currently use manual procedures to identify and close these gaps. In an effort to mitigate the limitations of this slow and error prone process, in this study we formulate algorithms and implement software tools for the graph-based organization and visualization of requirements.
State-of-the-Art Capability for Requirements Management
Present-day requirements management tools such as CORE , DOORS , and SLATE  provide the best support for top-down development where the focus is on requirements representation, traceability, allocation of requirements to system abstraction blocks, and recently, step-by-step execution of system models.
State-of-the-art practice is to organize groups of requirements (e.g., functional requirements, interface requirements) into tree hierarchies. Figure 2 shows, for example, a partial requirement document with requirements arranged into layers. Here, requirement C in layer 2 defines requirements E in layer 3. Conversely, requirement E complies with requirement C.
Figure 2. Pathway from Requirements Graphs (organized into layers) to Requirements Tree Hierarchies
A number of complicating relationships are possible. First, a child node (complying requirement) may have more than one parent node (defining requirement). This means that requirements documents need to support multiple inheritance structures. Furthermore, as requirements are classified and broken down into granular components, they can also trace across the same level (i.e., one requirement may comply or define the other requirements).
When the underlying data structure for the requirements is a graph, but visualization procedures assume that a tree structure is sufficient, resolution of this incompatibility is handled through the duplication of nodes in the visual representation (e.g., duplicate entrices for nodes C and E in Fig. 2).
Key Problem with Duplicate Requirements
When the overall number of requirements is very small (i.e., less than, let's say, a dozen requirements), the duplication of requirements nodes is not a significant barrier to a complete understanding of relationships in the requirements document. A systems engineer can easily find all of the duplicates and manually reconstruct the graph structure.
However, for all real world problems (hundreds and thousands of requirements), the presence of the duplicate nodes vastly complicates the task of interpreting/understanding the requirements document structure. When the manual identification of all complying and defining requirements becomes intractable, designers cannot be absolutely certain all comply/define relationships have been identified. This leads to decision making based on an incomplete picture of a requirement's role in the system design.
The tree representation of requirements hierarchies is fundamentally flawed and, in our opinion, only works well when requirements comply/define from a single source. In this work we formulate algorithms and develop Java-based software that can read the tree representation of the requirement database, and construct and visualize the block diagram representation with all duplicate nodes removed. See Figure 3.
Figure 3. Many-to-Many Relationships in Layers of Requirements. On the right-hand side we show extraction and visualization of requirements as a tree, followed by compaction back in to a graph format.
The input-to-screen transformation involves two steps:
Since the heart of this work involves a new and different way of requirements document visualization, efficiency of the systems engineering process can be enhanced with several new features of requirements management and visualization, namely:
Screenshots of PaladinRM
We have implemented the requirements visualization software in a tool called PaladinRM -- see Figure 4.
Figure 4. Screendump of PaladinRM Graphical User Interface
Figure 5 shows a requirement graph with requirements clustered vertically based on their level assignments.
Figure 5. Requirements Graph organized Vertically into Groups (corresponding to layers of development).
PaladinRM has been tested on suites of requirements containing up to 1100 requirement nodes, which currently forms the entire set of GPM project requirements.
Requirements are read into PaladinRM through file and interactive keyboard input. Requirements need to be in our proprietary XML file format, which can be created through:
Development of xml input files is very straight forward and practical for problems having a small number of requirements (e.g., less than 100).
Click here to see a collection of thirty three high-level requirements for a building architecture application. The requirements are organized into four layers.
Requirements Selection and Export
PaladinRM allows for the selection of individual requirements followed by a search for requirements that lie in the neighborhood of the selected requirement (i.e., within a user-supplied number of links).
Suppose, for example, that a small set requirements is read into PaladinRM and visualized as shown in Figure 6.
Figure 6. Selection of Requirements within a Neighborhood
Now let's use the selection box (details not shown) to select requirement 8-5 (Schedule Constraint). The properties of requirement 8-5 are shown in the box on the left-hand side of the graphic. A requirements sub-graph is obtained by selecting an individual requirement and then specifying the "number of levels" and "direction" of the required search. In this case, requirement 8-378 (No Title) is the only requirement that is distance one level from 8-5.
The selection box may also be used to select multiple requirements, as shown in Figure 7.
Figure 7. Exporting Selected Requirements
The export command generates an xml file of requirements that have been selected.
Support for graph-based visualization and management of requirments is simply a first step in systems development.
Looking ahead, we would like to understand how graphs of requirements can be attached to class and object hierarchies (representing concepts and objects in a particular application domain), which in turn might be mapped onto engineering drawings.
Figure 8. Pathway from requirements to UML-like class diagrams to engineering models/drawings for an architectural design application.
Figure 8 is a schematic illustrating the flow of requirements to UML-like representations of system behavior and system structure, whcih in turn, flow to engineering models/drawings.
This work was supported, in part, by a series of grants from NASA Goddard Space Flight Center. The views expressed in this web page are those of the authors and not necessarily those of the sponsors.
To license the PaladinRM software, please contact
Dr. Gayatri Varma Executive Director, Office of Technology Commercialization, Ph. 301-405-2960 E-mail: email@example.com
Developed in December 2004 by Mark Austin
Last Modified: March 2010
Copyright © 2004-2010, Vimal Mayank, Natasha Shmunis (nee Kositsyna), Mark Austin, University of Maryland. All rights reserved.