To address these problems, MOSDD management proposed to automate requirements collection and tracking. As this project progressed and showed some promise, the parent organization of the MOSDD, the Mission Operations and Data Systems Directorate (MO&DSD),;decided to expand the scope beyond the control centers, to include such other mission functions as flight dynamics and data capture.

At about this time, officials at NASA Headquarters were trying to improve the process of spacecraft mission development by reorganizing the required documentation. The result was the replacement of three fundamental early documents (the Support Instrumentation Requirements Document [SIRD], the Systems and Operations Requirements Document [SORD], and the NASA Support Plan [NSP]) with a preliminary requirements checklist (the Mission Requirements Request [MRR]) and a single requirements document (the Detailed Mission Requirements [DMR]).

The change from SIRD/SORD/NSP to MRR/DMR brought all of a mission's detailed requirements into a single document, rather than three documents produced at different times, and changed the requirements generation process familiar to the mission planners, scientists, and developers. To emphasize the importance of this new process, NASA mandated the use of the MRR/DMR format for all new missions. Consequently, the MO&DSD;reanalyzed the requirements automation project to correspond to the MRR/DMR format, further expanded the scope to include the entire requirements generation process, and named it the Requirements Generation System (RGS).

Of the several proposals submitted to design and implement the RGS, the one proposed by the Software and Automation Systems Branch (Code 522) in the MO&DSD;was accepted. The overall structure was (and is) a central requirements database accessed by distributed software at the user's locations, all within a client/server architecture.

NASA expected that no mission was to be delayed by this new requirements process. As the only requirements development tool that followed the MRR/DMR, the RGS immediately gained wide visibility as a way to help complete the requirements document in a timely manner. The first mission scheduled to use the MRR/DMR was the Submillimeter Wave Astronomy Satellite (SWAS), and RGS development meetings focused on the needs of that mission. To date the RGS has been used on the ACER3, CAPL2, EOS AM1, EXPRESS3, GOES, GPP, IEH 1, IFMP, LANDSAT 7, MOPSS, NEWTRACE, NOAA, SAC B, SLA 1, SSBUV, SWAS, TEAMS, and WIRE missions.

The requirements approvers are the Mission Operations Manager (MOM) and the Data Systems Manager (DSM). The MOM establishes the overall structure of the requirements groups, and verifies the rationale and traceability of each requirement. The DSM responds to requirements that have been accepted by the MOM and assigns them to NASA institutional elements (such as the Flight Dynamics Facility). In addition, both the MOM and the DSM can act as requirements generators.

In the past, requirements development has been mostly a manual process, prone to:

€inflexibility to change caused by the fixed page format of the DMR;
€delays caused by groups not responding in a timely manner;
€redundancy caused by groups generating similar requirements;
€misunderstandings caused by groups communicating poorly; and
€gaps caused by higher-level requirements not satisfied by more detailed requirements down the line.

Analysis of the requirements process, its problems, and its workarounds, quickly led the RGS developers to recommend a relational database design. With a relational database, not only is the manual fixed page approach unnecessary, it is difficult to force the system to accept fixed pages. Each requirement is referenced by its number alone, with individual item queries done using a "text search" feature. Sections (such as 4200) remain, but the page number becomes inconsequential and is only seen when the DMR is printed.

Delays. There are three situations that often cause delays in the requirements generation process. The first is in responding to another group's suggested requirements. While not all requirements for one group will impact others, requirements affecting an interface must be considered by all parties involved. With thousands of requirements and dozens of groups, it is very difficult to manually keep track of the status of all of them.

The second situation is in getting the final wording of a requirement for which alterations are suggested. Wording changes are generally requested when the original requirement would cause an unexpected impact on an organization. Until the final requirement has been approved, organizations do not know the resources they will need to dedicate to it. In addition, as all software life-cycle models indicate, the earlier in the process requirements are known the more efficiently they can be implemented.

The third situation is in getting final approval for all requirements. This has been a laborious process, often lasting well into implementation stages of the system. In fact, the author recalls one instance in which the requirements document was brought before an emergency session of mission personnel the day before launch, because it had not been signed (approved) by everyone. This situation is not only dangerous to the project developers, but it also causes concern at the highest levels of NASA and makes the mission managers appear to be incompetent.

The RGS method of handling delays is to make them visible to everyone as early as possible. This was done by putting the entire system, including comments and approvals, online. Groups that are expected to respond to an inquiry are noted, and remain noted until the response has been received. In addition, special reports are available to select requirements that are awaiting a response, including the name, organization, and phone number of the individual to contact.

Redundancy. Some of the delays in requirements generation are caused by separate groups inventing the same requirement over and over. While improved communication may seem to be the most direct solution, many missions generate thousands of requirements and developers could easily spend all their time communicating rather than developing.

The RGS solution to this problem is in visibility and reusability. All proposed requirements for a mission are visible to everyone involved in the mission. When a new requirement is considered, a text scan can be done to see if the function (based on various types of keywords) is already under development. If a near match is found, an individual can send a comment to the originator, explaining the similarities, to see if a single requirement can be constructed.

The RGS also has links to libraries containing requirements from previous NASA missions. A copy and-paste feature has been included to allow developers to reuse blocks of requirements rather than re-specifying them for a new mission. An edit feature has also been included to make the inevitable changes from one mission to the next. The expanded use of this RGS capability is dependent on the construction of more comprehensive electronic requirements libraries from the existing paper documents.

Misunderstandings. One of the most important functions of requirements analysts is their ability to communicate, as precisely as possible, what a requirement is supposed to do. If this communication was done in mathematics there would be no confusion. Unfortunately, English remains the language of the requirements developers, and we must find methods to make the intent of the language clear.

While there have been some successful projects done by limiting and strictly defining the vocabulary permitted in requirements descriptions, this method cannot be used with a large, diverse community such as NASA's. Mission requirements are often decided by negotiation, with arduous compromises over the phrases used. Some of the most uncomfortable moments in a mission occur when one group suddenly realizes that their perception of a requirement is not how it actually works.

The RGS provides two methods to aid communication among requirements developers. The first is the comment area, in which anyone can make remarks about a proposed requirement. Comments follow a requirement throughout its consideration and approval stages, but there is no guarantee that any action will be taken or even that the comment will be read. The comment field is usually used by individuals not directly responsible for the requirement, but who think they have useful information to share.

The second method is the version feature, used by individuals with update privileges to the particular DMR section. If an individual thinks that a proposed requirement is improperly worded, he/she can "update" that requirement in more satisfactory language. The update does not destroy the original wording, but creates a new version of the requirement, tagged with a date/time stamp and the individual's ID. This new version becomes an alternative for the requirements approvers to consider. This feature forces communication, or at least conversation, among the various requirements camps. The MOM and DSM approve one version, perhaps a compromise, and the requirement is automatically locked from further version update.

Gaps. Irrespective of its name, the Detailed Mission Requirements document is not the most detailed set of requirements used for a mission. The DMR is actually considered the highest parent set of requirements for the systems and subsystems that comprise the mission. For example, the satellite control centers use a section of the DMR to define the next set of requirements for a specific mission control center. This next level still may not be detailed enough for the developers to write software, and another level containing even more detail may be defined. This process can continue for an unlimited number of levels.

One of the driving forces for the MOSDD and the MO&DSD;in originating this project was the difficulty in determining that all DMR requirements were fulfilled by lower level developments, and that no spurious lower level requirements (ones that matched no DMR requirement) were included. This task is made more difficult by the non-electronic nature of the DMR, which forces lower level developers to rewrite the requirements. These developers often use slightly different wording, presumably in an attempt to make the requirements more understandable. Occasionally something is lost in the translation, especially if this rewriting process goes to additional levels, and the implemented requirement winds up being not what the original DMR requirement requested.

Developers may have to rewrite requirements for other reasons. A DMR requirement may be somewhat comprehensive (such as "Accept telemetry data from the satellite"), but the implementation may require activity from different components of the system (such as a data capture component, components for each experiment on the satellite, and an error checking component).

The RGS uses two kinds of automatic tracing to resolve the unimplemented requirements problems. The first kind uses the requirement number. Requirements that are direct descendants in a DMR section will be related by requirement number (such as parent requirement 2.1 and children requirements 2.1.1 and 2.1.2). A DMR requirement that doesn't have at least one child is flagged as "childless". The RGS eliminates the problem of "orphan" requirements by dictating that no parent may be deleted without first deleting all of the children.

The second kind of automatic requirements trace involves links to associated requirements. An associated requirement is usually a capability derived from a parent, but is not directly related. Deletions of these parents are noted as warnings for associated requirements within the RGS. Brother/Sister requirements (those on the same level but involving some common areas) are also linked to each other. A change proposed to one requirement may require a change to other associated requirements, and those requirements are flagged as possibly impacted.

Missions are displayed as a set of hierarchical functional categories. Figure 2 shows a typical category page of a DMR. While all categories can be viewed by any authorized user, only users with appropriate privileges can update requirements.

Requirements requesters have an online method of suggesting and reviewing requirements for an entire mission, and to copy large blocks of requirements from similar missions for reuse. Requirements approvers have an immediate view of comments on a requirement, forward and backward traceability on all requirements, a variety of status reports, and the ability to lock requirements groups after approval. The entire process has been streamlined and greatly accelerated, and reports in any format can be generated as needed. The use of the RGS has been recommended to assure DMR content consistency, to reduce the effort required to generate the document, and to maintain document configuration control.

Recently, NASA has initiated the Reusable Network Architecture for Interoperable Space Science, Analysis, Navigation, and Control Environments (Renaissance), a new approach to providing ground data processing systems to support Code 500 customers in a cost-effective, timely manner. The RGS is useful for Renaissance product requirements generation under existing MO&DSD;methodology. Its utility will need to be accessed for requirements generation for alternate life cycles.

A future feature could be automatic configuration management, in which a change proposed to a requirement would automatically generate a change request form for electronic distribution to the individuals interested in that area, and automatically collect their responses.

Future goals are to link the RGS with historical requirements libraries to allow cut-and-paste of requirements from earlier missions, and to allow access to the system for remote scientists, possibly through the Internet.

HTTP://www530.gsfc.nasa.gov/tdrss/dmr.html (May 1996). DMR Preparation and Baselining.

HTTP://garlic.gsfc.nasa.gov/csdev/newslet/newslet.htm (May 1996). RGS User News.

HTTP://groucho.gsfc.nasa.gov/Code_520/Code_522/Projects/RGS (May 1996). Requirements Generation System.

HTTP://joy.gsfc.nasa.gov/renhome/rt_mgmt/RT_Mgmt_Plan.html (May 1996). Renaissance Team Management Plan.

HTTP://renaissance.gsfc.nasa.gov/html/newprod /Renaissance_Standards.html (May 1996). Renaissance Standards.

NASA (1992). Into the Twenty-First Century Mission Operations. Greenbelt, Maryland: Goddard Space Flight Center.

NASA (1992). Instruction Manual for the NASA Detailed Mission Requirements (DMR) Document. Greenbelt, Maryland: Goddard Space Flight Center.

NASA (1992). Operations Concept for the Requirements Generation System (RGS), DSTL-92-013. Greenbelt, Maryland: Goddard Space Flight Center.

NASA (1993). Requirements Generation System (RGS) Requirements Specification, 510-4SRD/0292. Greenbelt, Maryland: Goddard Space Flight Center.

NASA (1995). User's Guide for the Requirements Generation System (RGS). Greenbelt, Maryland: Goddard Space Flight Center.