itmWEB: Interfacing Requirement Management Tools


..information technology management..

white paper

Published in Proceedings of the Seventh International Symposium of the INCOSE - Volume II, August 1997. Prepared by the Requirements Working Group of the International Council on Systems Engineering, for information purposes only. Not an official position of INCOSE. This paper does not necessarily reflect the views of the authors' companies. Copyright 1997.

Interfacing Requirements Management Tools
In The
Requirements Management Process -
A First Look

(A Requirements Working Group Information Report)

David A. Jones
Systems Group
Texas Instruments Incorporated

Pradip C. Kar
Systems Engineering
United Defense Limited Partnership

James R. van Gaasbeek
Advanced Systems and Technology
Northrop Grumman Corporation

Frank Hollenbach
Management & Data Systems
Lockheed Martin

Marty Bell
Systems Group
Texas Instruments Incorporated

Dr. Robert S. Ellinger
Advanced Systems and Technology
Northrop Grumman Corporation

Table of Contents

ABSTRACT

1. INTRODUCTION

2. REQUIREMENT CHARACTERISTICS

2.1 Requirement Definitions
2.2 Requirements Management
2.3 Requirement Formats and Components
2.4 Requirement Context
2.5 Requirement Collections

3. REQUIREMENTS IN THE SYSTEMS ENGINEERING PROCESS

3.1 Process Models
3.2 Common Process Features
3.3 Requirement Flow Representation
3.4 Tool Relationships
3.5 Additional Characteristics of the Actual Process

4. THE REQUIREMENT MANAGEMENT TOOLS

4.1 Definition
4.2 Tool Categories
4.3 Tool Functions
4.4 Auxiliary Functions
4.5 Data Interfaces
4.6 Current Tools

5. TOOL INTEGRATION CONSIDERATIONS

5.1 Why Have Multiple Tools And Why Connect Them
5.2 The Tool Hardware / Software Platform Interfaces
5.3 Issues in Integration
5.4 Some Problems
5.5 Guidelines for Interface Development

6. TOOL INTERFACING EXAMPLES

6.1 Example 1: RTM - to - RDD-100 Interface
6.2 Example 2: SLATE - to - Teamwork Two-Way Interface
6.3 Example 3: CORE - to - DOORS, RDD-100 - to - DOORS Interfaces
6.4 Example 4: HTTP / Web Publishing
6.5 Other Tool Interfacing / Integration Efforts

7. STANDARDIZATION EFFORTS

SEDRES
PSL Project

8. CONCLUSIONS AND RECOMMENDATIONS

9. ACKNOWLEDGMENTS

10. REFERENCES

11. BIOGRAPHIES

APPENDIX A. SOME DATA INTERFACE TECHNOLOGIES

A.1 Introduction
A.2 ASCII Based Files
A.3 Binary Files
A.4 Common Memory
A.5 Application Program Interface (API)
A.6 Object Interfaces

APPENDIX B. CORE INTERFACE DATA EXAMPLE

APPENDIX C. SLATE STEP INTERFACE DATA EXAMPLE

APPENDIX D. SOME OTHER COMMERCIAL AND CONSORTIUM TOOL INTEGRATION EFFORTS

CASETS / System Architect And More
Catalyst / RDD-100 And More
Cradle / REQ 26DeGregorio & Novorita Information Model / DOORS
RAASP-Lockheed / RDD-100 And More
RDD-100 Integrated Systems Engineering / RDD-100
RaDEO-TI System Design Advisor / SLATE
SBD
Notes

List of Figures

Figure 1. Requirement Data Flow.
Figure 2. Analyses and Requirement Collections Block Examples.
Figure 3. Requirement Management Tool Interface Data Flow.
Figure 4. Requirement Management Tool Hardware / Software Platform Interfaces.
Figure 5. Example 1 Information Flow.

Abstract

Interfacing requirements management software tools with other tools can facilitate the requirements management process by allowing people to exchange requirements more easily, to use the optimum tools in their work, and to adapt to tool changes. In this exploratory paper we attempt to provide some useful information to requirement tool users and developers who need to specify or devise requirement tool interfaces.

Examination of a simple hierarchical requirement data flow model suggests major interfaces of

The model presented suggests the type of data that should flow across these interfaces.

Twelve commercial requirements management tools are identified in this paper, and a couple of interface file formats are illustrated.

Some generalizations are made, such as that each data item should be entered once and reside in a single master location where possible.

Several examples of actual implementations illustrate accomplishments and practical difficulties encountered. Also eight commercial / consortium tool integration efforts are summarized with lists of the major tools involved, and a couple of standardization efforts are described, including a major European effort, SEDRES.

Some work by INCOSE in identifying requirements data is recommended in this paper.

Not all of the topics in this paper are covered in detail, but we think that a significant amount of useful information is provided.

1.  INTRODUCTION

This interim report is intended to provide useful information to requirement tool users and developers who need to specify or devise requirement tool interfaces. This is an exploratory work in progress covering the following topics in varying degrees:

Complementary work, on a specification for an integrated engineering environment, is being done by the INCOSE Tools Integration Working Group. (Schier et al 1996)

2.  REQUIREMENT CHARACTERISTICS

2.1  Requirement Definitions

In considering requirement management tool interfaces our approach is to start with a broad definition of requirements. Such a definition is " Anything that somebody's gotta do to provide a product or service," (including provide an operational or environmental capability). This definition is simple and easy to remember and emphasizes the person and task aspect of requirements that is at the heart of requirements management. (Jones 1995) (Harwell et al 1993)

A more specific definition is "A statement identifying a capability, physical characteristic, or quality factor that bounds a product or process need for which a solution will be pursued." (IEEE Std 1220-1994)

Another specific definition is "Requirements. Characteristics that identify the accomplishment levels needed to achieve specific objectives for a given set of conditions." (EIA/IS-632)

2.2  Requirements Management

Requirements management is the process of ensuring that people are aware of requirements they have and do not have.

A more specific definition, from a Requirements Working Group information paper, is "Requirements Management is the identification, derivation, allocation, and control in a consistent, traceable, correlatable, verifiable manner of all the system functions, attributes, interfaces, and verification methods that a system must meet including customer, derived (internal), and specialty engineering needs." (Stevens and Martin 1995)

Requirements management, when properly performed, reduces the time that engineers spend finding the information that they need to do their job, eliminates version mix-ups, and reduces errors.

2.3  Requirement Formats and Components

Relatively high level requirements tend to be formally structured items, such as

Other requirement formats include

Requirements may contain requirement parameters in such additional forms as

2.4  Requirement Context

In its most common form, a requirement is expressed as a statement, possibly with associated tables and figures. Part of the description of a particular requirement is often common to other requirements, and in a document may only be stated once. This common part we call context.

A requirement without context may be ambiguous. Take for a simple example the requirement, "The diameter shall not exceed 1 inch." The diameter of what, measured under what conditions? We need to know the system and the subsystem, if any to which this applies. More esoteric requirements often require more context information.

Examples of context provided in typical military specifications are

2.5  Requirement Collections

The methods that have been used to formally collect groups of requirements for a particular use have evolved over time. These collections provide context as well as individual requirements and generally also include a satisfactory human interface. Some current examples include

  1. Formal specifications.
  2. Interface documents.
  3. Collections of presentation slides.
  4. Formal operational need document.
  5. Formal analysis document.
  6. System models.
  7. Requirement database.
  8. Software design document.
  9. Mechanical assembly drawing.
  10. Electrical schematics.

All but the last three of these example collections are associated with systems engineering.

Most of these collections are usually for a single system level, but the formal analyses, computer models, and requirement databases are often for multiple system levels.

One definition for a specification is "A document that fully describes a physical element or its interfaces in terms of requirements (functional, performance, constraints and physical characteristics) and the qualification conditions and procedures for each requirement." (IEEE Std 1220-1994)

3.  REQUIREMENTS IN THE SYSTEMS ENGINEERING PROCESS

3.1  Process Models

The best practice and representation of the systems engineering process is still an evolving, and sometimes contentious, subject. Although there is not yet a generally accepted representation there are many candidates in various systems engineering papers (Oliver and Steiner 1996) and books (Rechtin 1991) and in the two working standards- "EIA Interim Standard Systems Engineering" (EIA IS-632) and "IEEE Trial-Use Standard for Application and Management of the Systems Engineering Process" (IEEE Std 1220-1994). Work on a non-interim EIA 632 is underway.

These representations of the process are usually shown as a flow diagram with boxes representing activities connected by arrows representing activity completion or time sequence. Some examples of the activities identified are shown in Table 1.

Table 1.  Example SE Process Model Activities
MODEL
Oliver and Steiner 1996
EIA/IS-632
IEEE Std 1220-1994
One draft of EIA 632


ACTIVITIES

Assess available information

Define effectiveness measures

Create behavior model

Create object model

Perform trade-off analysis

Create sequential build & test plan


Requirements analysis

Functional analysis / allocation

Synthesis

System analysis & control


Requirements analysis

Requirements trade studies

Requirements baseline validation

Functional analysis

Functional trade studies & assessments

Functional verification

Synthesis

Design trade studies & assessments

Physical verification

Control


Acquirer-supplier agreement process

Planning process

System design process (Define system requirements, Define design solution, Assessments & trade-off studies, Verify design solution)

Control process

System qualification process

3.2  Common Process Features

There are some common underlying features that relate to the application of software tools to the process.

One underlying idea is that whatever process is used, or however it is represented, there is a resulting hierarchy of requirements composed of collections of requirements that correspond to the various parts of the system or product being engineered and the people who work on them.

The archetypal example of a requirement collection is a specification. Specifications organize and format requirement collections in a convenient form for people to use. Such organization and formatting is needed whether the requirements are presented in paper documents or electronically.

The hierarchical arrangement of the requirements occurs because normally 1) system development is composed of sub-tasks, such as subsystem development, which are the responsibility of particular groups of people such as a company or a team; 2) this arrangement repeats at lower levels; and 3) each level is responsible for all lower level requirements.

The archetypal example of the hierarchical nature of the requirements is the weight budget that may exist for a system. The total of the weights for all components of the system obviously must not exceed the total allowable weight of the system. However weight requirements normally are not just assigned to components but to the intermediate subassemblies as well. The result is a requirement-flow-hierarchy of weight requirements from the total system weight through the subassembly weights down to component weights. The process for deriving the weight requirements, however, might have been any of several-a top down decomposition of the total weight subassembly-by-subassembly; the use of a simulation of the entire system; or some other method.

A second underlying idea is that wherever a derived requirement exists some analysis was involved.

Any particular requirement in a requirement collection in the hierarchy comes either from another collection, from an analysis, or an external source variously called the "customer" or "users / buyer / suppliers". Requirements from an external source may be in non-standard, or informal form, such as telephone conversation or meeting records. Requirements that are put into collections are in a formal standard form.

A third concept is that as requirements are generated or revised the flow of requirements to collections must be done in an orderly, gated manner. Generally the responsible people must agree to accept the requirements involved.

Some requirements in collections do not pass to other collections or analyses but instead are implemented. That is, for example, a part is built or tested, or assembled from lower level components.

A distinction can be made between customer objectives, also called "needs and desires", and system requirements. Customer requirements are in the customer's terms and may not be well stated or easily measurable. System requirements, which are derived by analysis of the customer requirements, are in system terms and should be well stated and measurable. In addition to requirements themselves, the systems engineering process deals with a hierarchy of feasibilities, possibilities, and queries that are associated with the requirements. If the requirements are considered to flow "downward" then these items flow "upward".

Finally, the requirement management process and tool must maintain control data for the requirement hierarchy and facilitate operator control of the process.

Figure 1.  Requirement Data Flow

3.3  Requirement Flow Representation

Figure 1 is a representation of these concepts. Although this figure could be mapped to the various representations of the systems engineering process, that mapping is outside the scope of this paper. Figure 1 is a data flow diagram for requirements and does not show the steps of a process. It contains the most basic elements resulting from the systems engineering process that impact requirement management tool interfaces.

The heavy, generally downward directed lines represent the requirement flow. It starts with the needs and desires of the top level user / buyer / suppliers and goes down through the first analyses to the first requirement collections. From there the flow goes down through the gated storage and the second level analyses to the second level requirement collections. Depending upon the process model used, the first requirement collections might correspond to system specifications, and the second to subassembly specifications.

The users / buyers / suppliers at the second level generally are not the same as those at the first level. There may be, for example, additional customers for a subassembly that are not customers for the system.

Table 2.  Requirement Control Data
Group
Item
Index key Identifier and revision designator
Traceability items Source requirement ID
Destination(s)
Owner
Source status items Certainty / validation
Questions to source
Importance / criticality
Destination status items Risk / feasibility
Suggested alternatives
Verification items Verification method
Verification level
Transverse reference Relationship
items Destination

The lighter, generally upward directed lines are the feasibility, possibility, and query data that were generated as a result of the requirements being placed in the collections.

The dotted, upward directed lines represent the flow of requirement control data. This data is a record of the requirements in the hierarchy and their revision, source, and destination. This data may be centrally located, or, in document-based systems, be partially contained in tables in documents such as specifications. The data typically consists of that shown in Table 2.

The term analyses is used in this diagram in its very general sense and includes 1) market and system requirement definition analyses, 2) architectural / concept analyses, 3) lower level derivation analyses, and 4) null analysis for requirements that are ready for use.

Figure 2.  Analyses and Requirement Collections Block Examples.

Figure 2 is a further example (and only an example), based upon an actual project, of the analyses and requirement collection blocks of Figure 1. The SPEC blocks are hardware specifications, and the CSCI SRS blocks are software` module specifications ("Computer Software Configuration Item Software Requirement Specifications").

3.4  Tool Relationships

In the upper levels of the hierarchy the requirements management tools generally contain the gated storage, the requirement control data, and the requirement collections. There are sometimes exceptions-the first example later in this paper shows a case wherein a separate tool generates the requirement collections (specifications). Simulation tools generally perform the calculations for the analyses, and data repository tools may store the data files and rationales for these analyses. The requirements management tool must pass requirements to, and get requirements from, these analysis tools, along with necessary control data, and may maintain a link to the data repository. The requirement data which is to be passed to an analysis tool may include both a system description, such as the arrangement of subassemblies, and the requirement to be analyzed, such as the total allowable system weight. At some level the requirements management tool may pass requirements to engineering design tools. Thus at these points the engineering design tools contain the gated storage function and the specialized requirement management tool may no longer be involved.

3.5  Additional Characteristics of the Actual Process

Simultaneous Multiple System Versions May Exist

Single derivation analyses may attempt to optimize a combination of several parameters over a relatively continuous range of possibilities, but sometimes it is desirable to compare completely different concepts, architectures, or components, i.e. different possible versions of the system. In the preceding diagrams this comparison can be treated as two systems emanating from the highest level market / use analysis (or possibly from a lower level element if more restricted in scope.)

Access and Change Control Required

Requirements must be accepted by the destination party, whether they originate from another level or from an analysis at the same level. Coordination among stakeholders is essential regarding versions and status of requirements collections. Some systems engineering efforts incorporate proprietary or secure information which needs to be protected against unauthorized dissemination.

Lower Level Requirements Are 90% Derived

One of the authors (Jones) examined military specifications from several levels of a military system and conducted an informal survey of several experienced systems engineers in a large company. Although more thorough research is needed, that study showed that in a wide variety of situations, the requirements at a given level were on the order of 90% derived; and only about 10% were directly copied from a higher level.

Limited Time Is Available

The usual fact of life is that there is very limited time for product design. As a result design-then-trace often occurs.

4.  THE REQUIREMENT MANAGEMENT TOOLS

4.1  Definition

A requirement management toolset is one that facilitates requirement management. A previous INCOSE Requirements Working Group paper (Jones et al 1995) identified the following basic needed features for a tool to be considered to be a requirement management tool:

Certainly some sort of storage is implied as is a human interface, by publishing on paper or electronically.

Such a toolset may be composed of one or several tools, and any of these tools may perform functions in addition to requirement management.

4.2  Tool Categories

As we attempt to generalize about requirement management tool interfaces it is well to keep in mind that a wide variety of such toolsets exists. Categories are not clear cut, but tools can range over the following:

  1. Document-based: Traces requirements by adding tables / links to pre-existing documents.
  2. Requirement tracing: Traces and often edits requirements between imported requirement collections.
  3. Requirement generating: Generates requirement collections from within the tool. Such toolsets generally can also be used in a similar way to those in the preceding category.
  4. Built-in modeling and simulation.

4.3  Tool Functions

An automated requirements management tool can support both the engineering discipline and the management discipline to manage requirements. Such a tool must be able to collect and manage both technical and programmatic requirements.

Common functions performed by the tool consist of requirements identification, viewing and editing, tracing requirements to their origin, and report generation.

Technical functions required by the tool includes change impact analysis. When a requirement is changed, all affected requirements must be identified. All requirements that drive the requirement being changed are examined to verify requirements' compliance has not been effected. All requirements that are driven by the changed requirement must be examined to verify their integrity after the change.

Another useful function to be performed is completeness and consistency checking.

Management functions required by the tool consist of metrics collection and monitoring requirement stability through change control. Change control consists of keeping track of any adds, deletes, or changes to existing requirements. Tracking changes and the reason for the changes can lead to improved processes to reduce changes, and hence costs, on future programs.

With this data collection, continuous improvement can be applied to reduce the instabilities in the future.

4.4  Auxiliary Functions

A function that we have not included in our definition of a requirements management tool is analysis or design, including system design. A number of commercial tools however include such auxiliary functions as functional analysis and simulation capabilities, either built into the tool or in the form of a closely integrated companion product with which the tool interfaces.

When auxiliary functions are included in a tool the associated interfaces are generally hidden. On one hand the integrity of the interface is likely to be good because all aspects of it are controlled by one vendor, but on the other hand one of the advantages of a tool interface is lost - the ability to use alternative tools for a given function.

4.5  Data Interfaces

The major types of interfaces are

All except the last two of these are illustrated in Figure 3.

Some existing interface technologies and file formats are described briefly in Appendices A, B, and C.

Figure 3.  Requirement Management Tool Interface Data Flow

4.6  Current Tools

Commercially available specialized requirements management tools available in 1997 known to the authors are

All of these tools can fulfill the requirements management tool function of Figure 3, but many include various auxiliary functions as well, such as the functional model and physical model functions of that figure. Nearly all of these tools also include import / parsing and some sort of publication capability.

Additionally, general purpose tools have been adapted as requirements management tools:

Finally, there are experimental tools being used for research, such as Traceability of Object-Oriented Requirements (TOOR). (Pincheiro and Goguen 1996) (This article also provides reference to a number of earlier requirements management tools.)

5.  TOOL INTEGRATION CONSIDERATIONS

5.1  Why Have Multiple Tools And Why Connect Them

The use of software based SE tools has become commonplace within the SE community. The reasons for having multiple tools include

The reason for connecting requirements management tools with other tools is to facilitate the seamless flow of requirements data among the people who originate and use them. Requirements should all flow to where they need to go for implementation without the need to maintain multiple databases which cannot be kept consistent.

Our goal for interfacing is to make it appropriately convenient to use multiple tools in likely scenarios, including

Convenience in these situations includes

5.2  The Tool Hardware / Software Platform Interfaces

At the basic level, the tool environment includes a host computer, operating system and some type of presentation software to allow interaction with a user. Software SE tools have data and control interfaces with this environment and may additionally exchange data and control with storage media, other computers and programs, and the human operator as shown in Figure 4.

Figure 4.  Requirement Management Tool Hardware / Software Platform Interfaces.

5.3  Issues in Integration

In general, the integration of tools, whether in systems or software engineering, must address integration of the varying tools at a variety of levels. Wasserman suggests that integration issues fall into five categories (Wasserman 96):

We do not address presentation integration in this paper and we address platform integration and control integration only slightly.

5.4  Some Problems

Process-Related

Fundamentally Different Data

Data supporting a given activity can be of fundamentally different types supporting different types of systems representations and models. Systems can be represented in a variety of ways-state diagrams, behavior diagrams, IDEF0 models, functional flow block diagrams, and a variety of dynamic models-each of which clearly delimit certain attributes of a system, while masking others. The data, too, required by each of these representations of a system are different (though there will naturally be a core of data that is similar.) The data may be so different (the way the representation describes a task) that there is no readily apparent transformation of the data that would be of any utility.

Variety Of Formats

The same data can be in a variety of formats. Format includes attributes like the length of the variable (i.e., the number of character stored) and the code of the data. Examples of text formats include ASCII, EBCDIC, Word, WordPerfect, SGML, and HTML. Examples of graphics formats include raster images (e.g., .GIF or .TIF) formats, or vector image (e.g., .PDF, IGES, Postscript, and STEP). Since requirements can be based on video or audio, formats for those media will eventually have to be accommodated.

Application Suppliers Changing Formats

Suppliers of requirements management and systems engineering tools, like all software suppliers, are always attempting to enhance their products. Frequently, this means that the file format requires upgrade to support the enhancements.

Market-Related

In the competitive marketplace conflicts of interest can exist between suppliers and users. Generally users want standards and a choice of vendors without dependency on any one vendor. Vendors may want

5.5  Guidelines for Interface Development

We have identified major process-related and platform-related tool interfaces. In this section we provide a few generalizations and guidelines for interface development:

Choosing a tool architecture which facilitates integration may also be helpful. (McCay 1996)

6.  TOOL INTERFACING EXAMPLES

Here are some detailed examples followed by others in more summary form.

Caveat: These examples reflect experiences of particular users at particular times. They should not be considered necessarily to reflect the current capabilities or limitations of any tool at the present time in this rapidly evolving field.

6.1  Example 1:  RTM - to - RDD-100 Interface

Overview

An implemented interface is described between RTM (Requirements Traceability and Management), a requirements management tool, and RDD-100 (or just RDD) (Requirements Driven Design) a systems engineering tool, used to perform functional analysis and allocation (behavior modeling), system synthesis and dynamic verification of system behavior. The intent of the implemented interface or "bridge" was to extract a subset of the RTM database and place it into the RDD-100 database in order to develop performance specifications at several levels of the system.

The information flow is shown in Figure 5. The structure of the requirements database within RTM is called a schema. When it is desired to develop a specification at a particular level, (for example a SSS), the requirements from that level of the RTM schema are transferred from RTM to RDD-100 using the bridge. The details of the bridge are described in the succeeding paragraphs. Once the requirements and their attributes are in RDD, they are manually associated or linked with other information within RDD such as the functional and physical models and the specification outline. Once the linking is complete, the specification is transferred to the Interleaf document publishing tool using an existing interface for review and publication.

Figure 5.  Example 1 Information Flow.

Data Transfer.

As stated in the overview paragraph, the bridge was a limited implementation, involving the transfer of only the data needed to generate specifications. The bridge was not designed to transfer information freely between the two tools which would have been harder and more expensive. An important principle used in the implementation was: to the greatest extent possible, information would not be duplicated in the two tools. The RTM database was the master database for requirements. Similarly, RDD was master for the system hierarchy or physical model of the system. It was determined by analysis that information presented in Table 3 needed to be transferred from RTM to RDD.

Bridge

The RTM-RDD bridge was implemented by file transfer and consists of:

Attribute Type
Attribute Name
Reason Transferred
Single, Multiple Project Unique Identification (PUID) Identify the requirement uniquely in RDD and in the specification
Single Requirement Text Paragraph text material needed for section 3 of the specification
Single Requirement Title Paragraph heading in the specification.
Single PUID Component ID The components are the level of system at which the requirement is applicable. For example the system requirements are labeled SYSTEM and the first three letters of the PUID are SYS.
Single OwnerThis field is not used in the specification but is used to keep the information in RDD consistent with RTM
Single Requirements Key Default Field generated by RTM to uniquely identify a requirement
Multiple Verification Method This attribute defines how the requirement will be verified (for example by test). Used in the verification section of the specification and included in the verification cross reference matrix (VCRM)
Multiple Verification Level The level at which the requirement is to be verified. The level is usually the same as the level at which the requirement is written but can be different, depending upon verification strategy. Included in the VCRM.
Multiple Allocated To Identifies the element or subsystem to which the requirement is allocated.

The SQL routines and RDD reports are described below.

SQL Routines

After execution of the two SQL routines, the single attribute file contains the set of single value transfer attributes from RTM shown in Table 3 such as PUID, Requirement Title, Requirement Text, PUID Component ID and owner. The multiple attribute file contains the multiple value attributes such as "verification method," "verification location" and "allocated to." In order to ensure that the attributes are tracked to the correct requirement, the PUID attribute, though a single attribute, is included in the multiple attribute file.

RDD Reports

The first single attribute RDD report is executed to prepare the RDD database to receive single attribute requirements information from RTM. Because RTM is the master for requirements, all RTM key, requirement title and requirement description locations in RDD are first erased. This procedure ensures that new RTM keys, requirement titles and requirement descriptions will replace old, non current requirements. After the new data is written, if an area is blank in RDD, it will indicate that the requirement is no longer current.

The second single attribute RDD report is executed to populate RDD with information from the single attribute file. For each record in the single attribute file, the report tries to match the PUID in the record with that in the RDD database. If a match is found, the report inserts Requirement Title, Requirement Text, RTM Key, PUID Component ID and owner. If no match is found, a new database entry is created in RDD and the complete record including the PUID is entered into the RDD database.

A third single attribute RDD report is executed to check consistency between the single attribute file and the data base within RDD and create error reports in case of unpopulated entry fields, and to check links within RDD. For example, for requirements imported from RTM with new PUIDs there will be no links within RDD. The reports output will provide a checklist of requirements which need to be linked within RDD.

The first multiple attribute RDD report is executed to prepare the RDD database to receive multiple attribute requirements information from RTM. Similar to the first single attribute report, the report deletes all verification requirements. This breaks the following links within RDD:

The second multiple attribute RDD report is executed to populate RDD with information from the multiple attribute file. Again, the PUIDs in the file are matched with those in RDD and if a match is found, a determination is made whether there is a link to a verification requirement. If not, a link is created. Next a link is established to the verification method(s) which may be multiple. Finally, the process is repeated for "verification level" and "allocated to."

Final cleanup

A final cleanup report is executed after all other reports, described above, have completed execution. This report identifies all requirements with empty requirement text (deleted requirement) and deletes them.

Summary Notes.

The RTM to RDD one way bridge described above has been implemented and works as designed. Specifications at two levels of the system hierarchy have been produced using the bridge and the underlying process. However, the description would not be complete if we did not mention the fact that the final implementation of the bridge was not as it was initially conceived. We had initially thought that a specification, being primarily a list of requirements, should be produced from RTM, which is the master database for requirements. Accordingly, a transfer of the specification outline, and the functional and system hierarchies from RDD-100 to RTM were planned for linking in RTM and a direct output to Interleaf. However this was not possible due to practical difficulties in extracting the information from RDD-100 and the associated cost. As we go to press, we are working on a specification for a two way interface between RDD-100 and RTM to be implemented in the future as time and budget permits.

6.2  Example 2: SLATE - to - Teamwork Two-Way Interface

A systems engineering organization was using TD Technologies' SLATE (System Level Automation Tool for Engineers) requirements tool and CADRE's (now Cayenne's) Teamwork structured analysis and design tool in the development of a software component of a product. These two organizations collaborated with TD
Technologies to develop a use case and requirements for the integration of the systems and software engineering requirements processes that integrated the tools. The organization developed an interface between the two tools via an Applications Programming Interface (API). SLATE is an object-oriented tool that uses a commercially-available object-oriented database management system (Versant) to establish and maintain its data repository. Teamwork does not implement a database as such, rather storing data in data structures based upon various types of data flow, context diagrams and structure charts.

Table 4. Comparison of SLATE-Teamwork Interface Goals and Actual Implementation.

Original Goal
Implementation
Flow-down conceptual design from SLATE to Teamwork Enter conceptual design in Teamwork
Flow-down requirements from SLATE to Teamwork Implemented
Continuous flow of design information from systems engineer to software designers via the interface Partially implemented for requirements, not for architecture
Architecture is built in SLATE from the Teamwork database.
Continuity of traceability, verification, and validation information as product evolves from SE to SW Almost completely implemented
SE and SW engineers able to work in both tools without interrupting their work or focus to switch between tools Largely implemented. Teamwork diagrams can be opened upon command from SLATE and both tools synchronized upon demand.

The systems engineering organization first developed a concept of operations for the joint use of the two tools, with a determination of which functions would be performed using each tool and what data would be stored in each tool, and what data would be transferred between tools. As the interface development progressed, the organization found that their original approach was impractical and revised the concept of operations and the interface requirements. As the two engineering groups worked through the issues of integration, software engineers realized they would be using both tools in their product development cycle. Table 4 provides a comparison of what was originally intended and what was actually accomplished in the first release of the interface.

The resulting sequence of events for joint tool use is:

  1. Create system requirements in SLATE.
  2. Create system architecture ("abstraction hierarchy") in SLATE.
  3. Create software diagram of objects in Teamwork.
  4. Create links ("handle objects") in SLATE for the Teamwork objects.
  5. Using the SLATE synchronization utility, link the two databases. The handle object is a persistent object and retains all information to locate data in Teamwork.
  6. In SLATE, allocate requirements to these handle objects.
  7. Use a SLATE menu command to resynchronize the SLATE and Teamwork data. This action creates notes on the diagrams in Teamwork for each requirement allocated to a handle and informs the systems engineer of changes in the software architecture.

At the end of this process, Teamwork contains the linked requirements as notes attached to Teamwork objects.

6.3  Example 3: CORE - to - DOORS, RDD-100 - to - DOORS Interfaces

Sufficient numbers of organizations are using the QSS DOORS product and either the Vitech CORE or Ascent Logic RDD-100 products that a firm (Alford Enterprises) has developed a commercially-available bridge to transfer data between the two programs. CORE and RDD-100 make use of similar entity-relation-attribute (ERA) databases and DOORS uses a proprietary object-oriented database. The interfaces were developed using the DOORS Extension Language (DXL). The interfaces are bi-directional and provide complete data exchange to the extent that the schema in use in either CORE or RDD-100 has a one-to-one mapping to the object representation implemented in DOORS. The bridge designer reports that the bridges are not yet fully bi-directional for changes because when DOORS deletes a relationship (a link in their terminology, e.g. from a requirement to another requirement to show traceability), they don't keep enough information around to be able to later identify that it was deleted, thus you cannot export back to RDD or CORE the fact that it was deleted. This is an example of why bridges are difficult.

6.4  Example 4: HTTP / Web Publishing

Several companies have successfully used web technologies to publish specifications and in some cases get feasibility and suggestion feedback. (Bartholomew et al 1997)

A project in one company used RTM for requirement management and exported specification files from that tool in RTF format. These files are imported into MS Word, manually touched up, and made available on Web servers both on an intranet within the company and on an extranet (secure transmission to selected destinations via the Internet) to suppliers and customers.

Another company has accomplished a similar feat using RDD-100 as a requirements tool, exporting specifications to Interleaf publishing tool and creating either Interview Worldview files or Adobe Acrobat PDF files which were made available from a Web server on an intranet and extranet. Using this method 2,000 users were served with only ten RDD licenses.

VITAL LINK has been used in a similar manner to produce HTTP documents for an intranet by putting the Frame Maker output documents into Adobe via the distiller.

6.5  Other Tool Interfacing / Integration Efforts

There are a number of tools that provide an ASCII file interface that allow elements to be passed from one tool to another (RDD-100 and CORE, for example). This integration can be across platforms (e.g., from workstation to PC, from PC to Macintosh). The use of a file interface allows for data integration as the data are moved from one application to another.

Some interfaces provide for data and format translation between programs. Desktop publishing and word processing tools are good examples of this process as they filter in text, graphics and formatting data from a variety of other tools for subsequent presentation.

Some tools are migrating toward representing requirements as objects and passing the objects among elements. An informal survey conducted by the Software Productivity Consortium (SPC 1996) cites a migration of user interest from use of large CASE environments to tools that handle requirements as distinct items.

Appendix D contains brief overviews of the integration products and technologies known to the authors in January, 1997.

7.  STANDARDIZATION EFFORTS

SEDRES

The goal of this project is to define a validated data exchange standard for systems engineering tools. The Commissions of the European Community (CEC) are funding the Systems Engineering Data Representation and Exchange Standardization effort as an Esprit project (#20496). Five European corporations, two European universities and the Australian Centre for Testing and Evaluation are developing a mechanism for exchanging data between systems engineering tools and providing information to tool vendors to support use of the standard. Started in January 1996, this project will run for three years, cost M6.2 ECU and expend over 40 man-years of effort. The participants hope to promote the SEDRES-developed standard to become a part of the existing STEP standard. Planned activities include:

The initial general requirements for the design data representation and exchange standard have been completed.

The approach used is applicable to tool interfaces generally. The requirements on the SEDRES standard were divided into three sets:

Representational requirements deal with how the entities, relationships, and constraints of the system and its development process will be described. The standard is to provide means for describing the system hierarchy, requirements, functional hierarchy, data flow, behavior, physical architecture, configuration management, traceability, and verification and validation, among other things.

Exchange requirements deal with where and when certain information is to be exchanged relative to events in the SEDRES process model. (This model is similar to the IEEE trial use SE standard.) (IEEE Std 1220-1994) Exchange types can be user defined. Examples of some of the types of exchanges contemplated are

Finally, non-functional requirements deal with such items as the exchange being automatic with predictable delay times, having encryption available, and having status reports available. (www.ida.liu.se/projects/sedres/index.html)

PSL Project

The U. S. National Institute of Standards and Technology (NIST) Manufacturing Systems Integration Division is now involved in the neutral representation of data for the sharing of manufacturing process information, starting with the early indications of manufacturing process flagged during design. This effort is called the Product Specification Language (PSL) Project. This effort appears to have a slight overlap with the sharing of systems engineering requirements data. There are three universities and one company, Knowledge Based Systems Incorporated, involved in this work.

Plans include process representation; definition of language grammar, syntax, and notation; and pilot implementation. (www.mel.nist.gov/psl )

8.  CONCLUSIONS AND RECOMMENDATIONS

A particular model of requirement flowdown provides a good basis for examining requirement tool interfaces. This model is composed of a repeating pattern of levels, each of which contains

with the flowdown of tentative requirements iterating with the feedback of feasibility estimates and suggestions. (This model is a refinement of one we first described two yeas ago. (Jones et al 1995), and its iterative feature has become more widely adopted.)

Some key goals in interfacing tools should be

Based upon the model, consideration of interface goals, and experience on practical systems, the key types of interfaces and some tentative related recommendations are

Practical interfacing of current tools requires compromises.

9.  ACKNOWLEDGMENTS

The following people contributed to discussions of this paper in multiple Requirements Working Group Tools Section meetings and teleconferences:

The following people have reviewed and offered useful comments on an early draft of this article: Mack Alford (Alford Enterprises), Karl J. Arunski (Texas Instruments), Laura K. Beach (Mesa Systems Guild), Brad Fennell (Texas Instruments), Ivy Hooks (Compliance Automation Inc. / VITAL LINK), Norm Jones (Texas Instruments), Dean Leffingwell (Rational Software / RequisitePro), Brian Mar (University of Washington), James N. Martin (Texas Instruments), Kevin A. Massey (Texas Instruments), Pete McDevitt (Naval Air Warfare Center), John Nallon (TD Technologies / SLATE), Gerard O'Conner (GEC Marconi Systems / RDT), and Stauber (Lockheed Sanders). Suggestions from all of these reviewers helped improve the quality of the paper.

10.  REFERENCES

Bartholomew, Bart, Jim Hinderer, and Terrell Landry, "Using A Local Internet for Information Sharing", The Capstone System Engineering News, May 1997, pp. 19-20. (Texas Instruments Systems Group).

Bell, Marty and David A. Jones, "Using MS Access to Manage Requirements", Proceedings of the Sixth Annual International Symposium of the INCOSE, Volume 1, pp. 347-354, 1996.

Cusumano, Michael A,. and Richard W. Selby, Microsoft Secrets - How the World's Most Powerful Software Company Creates Technology, Shapes Markets and Manages People (NY: The Free Press, 1995, 512 pages)

DeGregorio, Gary L and Novorita, Robert J, "Less is More: Capturing the Essential Data Needed for Rapid Systems Development," Proceedings of the 6th Annual International Symposium of the International Council on Systems Engineering, Vol. 1, pp. 951-958, July, 1996.

EIA/IS-632, "EIA Interim Standard Systems Engineering", December 1994. (Electronic Industries Association Engineering Department)

Harwell, R. M., Eric Aslaksen, Ivy Hooks, Roy Mengot, and Ken Ptack, "What Is A Requirement?" Proceedings of the Third Annual International Symposium on the NCOSE, Volume I, 1993, pp 17-22.

IEEE Std 1220-1994, "IEEE Trial-Use Standard for Application and Management of the Systems Engineering Process", (Issued February 1995 for trial use). (Institute of Electrical and Electronic Engineers (IEEE))

Jennings, Larry E. and Stephen J. Tauber, "Exploiting the Turnpike Effect in Engineering Process Support", Proceedings of the Sixth Annual International Symposium of the INCOSE, Volume 1, pp. 223-230, 1996.

Jernigan, Stephen S. "Integrated Office Suite Software, and the Development of Ad Hoc Tools," Proceedings of the Sixth Annual International Symposium of the INCOSE, Volume 1, pp. 243-245, 1996.

Jones, David A., Donald M. York, John F. Nallon, and Joseph Simpson, "Factors Influencing Requirement Management Toolset Selection," Proceedings of the Fifth Annual International Symposium of the NCOSE, Volume 2, 1995, pp 33-58.

Jones, David A., "Experience With Automated Requirements Management", Proceedings of the Fifth Annual International Symposium of the NCOSE, Volume 1, 1995, pp. 11-18.

McCay, Brian, "Assessing Interoperability Using a Tool's Architecture", Proceedings of the Sixth Annual International Symposium of the INCOSE, Volume 1, 1996, pp. 253-260.

Pinheiro, Franciso, and Joseph Goguen, "An Object-Oriented Tool for Tracing Requirements", IEEE Software, March 1996, pp. 23-31.

Rechtin, Eberhardt, Systems Architecting­Creating & Building Complex Systems, 1991, 333 pages. (Prentice-Hall)

Schier, James, John Nallon, John Walker, and David Kolberg, "Tools Integration Interest Group Report: Scenarios Leading Towards A Concept of Operations for an Integrated Systems Engineering Environment," Proceedings of the Sixth Annual International Symposium of the INCOSE, Volume 2, 1996, pp. 251-283.

SPC, "A Survey of Requirements Tool Users", Software Productivity Consortium, 1996)

Stevens, Richard, and James Martin, "What is Requirements Management?", Proceedings of the Fifth Annual International Symposium of the NCOSE, Volume 2, 1995, pp. 13-18.

Wasserman, Anthony I, "Toward a Discipline of Software Engineering", IEEE Software, November 1996, pp. 23-31.

11.  BIOGRAPHIES

Marty Bell

Marty Bell (P.E.) is a software system engineer with 19 years experience in software design and system design. These systems include real-time, embedded processor applications ranging from test systems, radar systems and electro-optical systems. In the past few years he has been involved in database development and requirements generation. His education includes an undergraduate degree in electrical engineering with a computer option.

Robert S. Ellinger

Robert S. Ellinger is an Information Technologist developing an Information Infrastructure to support the engineering and business processes. He has over 30 years experience in the development of information systems. He has worked in and taught in the areas of systems analysis, code development, data base engineering, data communications analysis and implementation, simulation, and computer-assisted instruction. He was a project leader of an engineering/shop floor system that won the Society of Manufacturing Engineers Lead Award. He has authored or co-authored numerous papers and presentations. Dr. Ellinger has a BS and an MA from Western Michigan University, and a Ph.D. from the University of Iowa.

Frank Hollenbach

Frank Hollenbach is a member of the technical staff at Lockheed Martin Management and Data Systems. His current activities include systems engineering and integration, systems analysis, and systems engineering process improvement. He was previously employed at the Naval Air Warfare Center (NAWC) Warminster performing research and development in Advanced Software Technology. Mr. Hollenbach earned a BS in Electrical Engineering and a Master of Engineering in Engineering Science from Penn State University and is pursuing graduate studies in Computer Science at Lehigh University. He is active in the INCOSE Requirements Working Group and the AIAA Software Systems Technical Committee.

David A. Jones

David A. Jones (P.E.) has over twenty-five years experience in system design. These systems included test systems, display systems, stochastic signal generation systems, radar signal processing systems, and electro-optical systems with hardware and software subsystems. In the last several years he has been involved in the support of automated system engineering, and systems engineering process development. His education includes undergraduate degrees in electrical engineering and mathematics from Texas Tech, a master's degree in business administration from SMU, and other graduate work in engineering. He is cochairman of the International Council on Systems Engineers Requirements Working Group.

Pradip Kar

Pradip Kar is the manager of systems engineering at Armament Systems Division of UDLP. Pradip has over 20 years of Navy Combat system development experience with emphasis in weapon control systems. He led the development of the Digital Data Distribution Set, a 10MB/s token passing local area network. He also worked on development of the Army Advanced Field Artillery System (now Crusader). Prior to joining UDLP, Pradip spent 20 years in the Indian Navy as a weapon system specialist and retired as a Commander. Pradip has a BSc (Hons) in Electrical Engineering from the University of London, England; and has done course work for an MS in Computer Science at the University of Minnesota.

James van Gaasbeek

James van Gaasbeek is a Principal Systems Engineer involved in process development and automation support in Northrop Grumman Military Aircraft Systems Division. He has over 20 years experience in analysis, research and development in the areas of aeroservoelasticity, flight dynamics and handling qualities, constructive and virtual simulation and systems engineering. Mr. van Gaasbeek currently serves on the Education and Training Committee of the Los Angeles Chapter of INCOSE. Mr. van Gaasbeek received a BS in Aeronautics and Astronautics from the Massachusetts Institute of Technology, an MS in Engineering Mechanics from the University of Texas and an MBA from TCU.

APPENDIX A.  SOME DATA INTERFACE TECHNOLOGIES

A.1  Introduction

In order for a Requirement Management Tool to be useful it must support various data types. The supported data types of the interfaces shown in Figure 3 must include commonly used data types that have existed for years and be capable of supporting newer data types as they become available.

A.2  ASCII Based Files

The most common of these data types is the Text Delimited type. Virtually all applications support this data type. Another common data type is the Microsoft Rich Text Format (RTF). With the ground swell of the Internet taking place, Hypertext Markup Language (HTML)/Standard Generalized Markup Language (SGML) is becoming popular. And some companies are producing additional data types such as CASE Data Interchange Format (CDIF), RDD-100/CORE, and STEP. These data types are starting to gain some acceptance.

A.3  Binary Files

Not all tools interface readily with binary files. The reason is that binary files are source tool specific. Unless the source tool has a wide acceptance, the need for conversion is likely. A requirement management tool should be sensitive to various binary types without becoming too burdened with an exhaustive selection.

A.4  Common Memory

Copy and paste techniques into and out of a memory clipboard much like Windows is very desirable. When the requirement management tool has a common data type with another tool, this technique is invaluable.

A.5  Application Program Interface (API)

The API allows software programs to communicate with one another and exchange control and data. It generally is a custom interface.

A.6  Object Interfaces

Several methods are in use and under development to allow software to embed objects that are linked to other programs by a set protocol.

Microsoft's Object Linking and Embedding (OLE) interface standard using their Component Object Module (COM) represents one approach. This approach has been extended to allow connecting objects on more than one workstation by the Distributed Component Object Model (DCOM). COM itself has been extended for specific applications- Design and Modeling extension developed by Intergraph (www.intergraph.com) and Real Time Market Data extension developed by the Open Market Data Council for Windows. A number of software tools used by systems engineers already have some OLE / COM capabilities. (www.microsoft.com/msdn/library/backgrnd/objstrat.htm)

Other approaches include the Object Management Group's Common Object Request Broker Architecture (CORBA) (www.omg.org), IBM and others' Open Doc (www.software.ibm.com/clubopendoc/index.html), and Sun's Java Beans.

APPENDIX B.  CORE INTERFACE DATA EXAMPLE

The Core interface files can be seen as exported from the Core demo disk. An example entry is 


OriginatingRequirement \Accept Requests\Attributes

        creator = * \Vitech Corporation\

        creationDate = * 'July 6, 1993'; 

        number = * '3.1.1'; 

        abbreviation = * 'AR'; 

        description = * 'The system shall accept intelligence data collection requests from the certified users.'; 

        paragraphNumber = * '3.1'; 

        paragaraphTitle = * 'GENERAL REQUIREMENTS'; 

        modificationDate = * 'July 8, 1994'; 

        modificationTime = * '11:40:12 AM'; 

relations

        generates = insert CriticalIssue \Criteria for Determining Certified User\, CriticalIssue \Media of Collection Requests\;

        incorporated in = 

insert OriginatingRequirement \General Requirements\;

        owned by = assign Engineer \Vitech Corporation\;

        traces to = insert Function \Accept and Format Request\;

        verified by = insert VerificationMethod \Accept Requests\;

end originatingRequirement;!

APPENDIX C.  SLATE STEP INTERFACE DATA EXAMPLE

The SLATE schema includes such items as :

kRequirement ("Reqtxt, Id, source)
Note
Attribute

An example line from a STEP file is 


#20 = kRequirement('2-1', $, #18, $, (#21), (#51), $, 0, (), (), #19, 'The Range Finder shall detect the target.', 1, 0, $, ());

Where 


2-1     Requirement number

$       SLATE ID (all have same) 

#18     Owner (pointer) 

$       

(#21)   Complying pointer list

(#51)   Defining (pointer) list

$       

0       History policy

()      Note list

()      Attribute list

#19     Type definition (pointer) 

'The range Finder shall detect the target.'

        Text requirement

APPENDIX D.  SOME OTHER COMMERCIAL AND CONSORTIUM TOOL INTEGRATION EFFORTS

CASETS / System Architect And More

The CASETS product was developed at Rockwell (now Boeing North American) and provides a set of tools to integrate the EIA systems engineering processes (EIA/IS-632). It runs under either Windows 3.1 or Windows 95, and incorporates the following commercial off-the-shelf tools:

Vendor
Tool
Adobe Acrobat Reader
hDC Windows Express
Microsoft Office (Word, Excel, Power Point)
Microsoft Project Manager
Popkin Software System Architect (RM function)
Boeing North American Parser

AHP (Analytical Hierarchy Process tool)

Auto Spec Generator

QFD (Quality Functional Deployment tool)

Taguchi

SPC (Statistical Process Control tool)

ProbSched

Risk Assessment

TPM (Technical Performance Measure)

TQM (Total Quality Management tool)

Templates

CASETS uses the Popkin System Architect product to create and maintain the database containing all data, or references to the files containing the data. Data created in any of the tools (e.g., requirements, schedule) can be referenced by any of the other tools.

Contact Larry Davidoff (l.d.davidoff @ boeing. com) for further information.

Catalyst / RDD-100 And More

Catalyst has been under development by Software Productivity Solutions (SPS) for the Rome Laboratories. Currently the product runs under Solaris 2.4 or 2.5, and requires SunSoft NEO 1.0. The feasibility of hosting the tool on a PC platform is under study.

Catalyst uses a Common Object Request Broker Architecture for the integration framework which supports user selection of the tools to be integrated. Integration of the following commercial off-the-shelf and proprietary tools has been completed:

Vendor
Tool
Ascent Logic RDD-100 (RM function)
InSight Modeling tool
Oracle Oracle
Software Productivity Solutions Process Enactment tool

Browser and Impact Analysis tool

Object Community Interchange tool

QFD tool

General Relation Manager tool

Object Servers

The Catalyst product supports integration strategies from loose (interchanging data files) to very tight (using the tool's API). Loosely-integrated tools, such as RDD-100, can execute in environments other than Solaris, as long as the data files can be moved to the Catalyst host. The types of data transferred depend upon the tools integrated. As a QFD tool is provided by SPS, and RDD-100 is one of the tools already integrated, requirements data may be transferred among the tools.

A white paper, "Tool Integration in Catalyst", available at the SPS web site, provides an overview of the integration mechanisms. (www.sps.com)

Cradle / REQ

Structured Software Solutions Limited (3SL) has developed the Cradle product. The tool, originally developed as a computer-aided software design tool, has been expanded to include a systems engineering toolset. The product is modular and all components use a common, concurrent multi-user repository. The repository data model is open, supporting integration of other tools, and is constructed of objects and frames that can be cross-referenced. The repository implements several levels of access control. The 3SL-developed Cradle components are:

Tool
REQ (RM function)
Source Document Management
Requirements Editor
Document Comparison

SYS
Validation
Logical Modeling
Physical Modeling
Comparator
Animation

PERF
Performance Modeling

SWE

Structure Charts
Code Generation
Reverse Engineering

DOC
Document Editor
Document Printer
Template Editor

CORE
Cross Reference
Text and Graphics Reporters
Configuration Management
Workgroup Management
Project Database
System Notes

3SL REQ, used in conjunction with 3SL CORE, provides the requirements management capability. Cradle can be executed on most UNIX platforms.

The Cradle product, manufactured by 3SL (www.3sl.co.uk/sssl), has been distributed and supported in the United States by Mesa Systems Guild. (www.mesasys.com).

DeGregorio & Novorita Information Model / DOORS

Personnel at Motorola are using the QSS DOORS product with extensions to provide needed integration between the requirements management database and process and other, related, systems engineering tools and processes (DeGregorio and Novorita 1996). The integration effort is still in the pilot stage, and is based on a systems engineering data model described in the reference. DOORS may be run on PCs (Windows 95, and Windows NT) and many UNIX platforms.

(Motorola: cgd001@email.mot.com and cbn001@email.mot.com) (QSS: www.qssinc.com)

RASSP-Lockheed / RDD-100 And More

The Lockheed Martin Advanced Technology Laboratories has been performing the Rapid Prototyping of Application-Specific Signal Processors (RASSP) effort under contract to DARPA. The goal of the program is to improve the cost and time involved in development and manufacture of signal processors by a factor of four. The developed RASSP design process has been automated using an extensive set of integrated tools, including Ascent Logic's RDD-100 tool in the system definition phase for requirements definition and management. The entire integrated toolset includes:

Vendor
Tool
Alta Group of Cadence Design Block Oriented Network Simulator (BONeS)

Signal Processing WorkSystem (SPW)

Ascent Logic RDD-100 (RM function)
Aspect Development Explore CIS
Berkeley Design Technology Ptolemy HSIM
Honeywell Technology Center Generic VHDL library
Intergraph Design Methodology Manager DM2
JRS Research Laboratories NetSyn
Lockheed Martin Advanced Technology Laboratories GEDAE
Lockheed Martin PRICE Systems PRICE S, H, HL, M cost models
LogicVision ICBIST
Lucent Technologies Signal Processing Environment Aiding debugging for RASSP (SPEAR)
Management Communications and Control GrTT, uPIDgen
Management Sciences RAM/ILS
Mentor Graphics Falcon Framework, QuickVHDL
Omniview Performance Modeling Workbench
Precedence SimMatrix
Quickturn Design Systems ASIC Emulator
Rockwell Aerospace, North American Aircraft RASSP Enterprise Model Repository
University of Oregon TIBBIT, PIE
Vista Technologies OO VHDL Modeling Tool

The various tools integrated into rassp execute on the platforms on which they can be hosted, with data being transferred between platforms as needed. (www.atl.external.lmco.com/projects/rassp/rassp.html).

RDD-100 Integrated Systems Engineering / RDD-100

Ascent Logic is offering the Integrated Systems Engineering product based on the work performed under RASSP. ALC has linked RDD-100 to the Lockheed PRICE cost and schedule estimating tools, the Management Sciences RAM / ILS tools and the Aonix Software through Pictures (StP) tool. The toolset uses the PRICE and RAM / ILS tools for analysis and the RDD-100 repository for requirements definition, analysis and management. Requirements information can then be downloaded to the StP tool to support software design. Ascent Logic is currently integrating a reliability tool developed at Sandia National Laboratories (WinR) into the toolset.

RDD-100 can be installed on Sun and Hewlett-Packard workstations as well as Windows-based PCs and Macintosh computers. The other tools also run on UNIX platforms, and integration is performed through importation and exportation of formatted data files into and from the RDD-100 database. (ALC: www.alc.com).

RaDEO-TI System Design Advisor / SLATE

The full name of this investigative project, sponsored by Advanced Projects Research Agency (ARPA), is Rapid Design Exploration and Optimization Program (RaDEO), and it has several contractors, of which Texas Instruments (TI) is one. Its objective is for a development program to address more design objectives without increasing the design time, to optimize the design for several differing objectives, and to shorten prototype cycle times.

TI is integrating these tools

Vendor
Tool
Amber MATLAB Infrared Focal Plane Array Cost and Performance Analysis Tools
Structural Dynamics Research Corp. Metaphase data repository
TD Technologies SLATE (RM function)
Texas Instruments Inc. MATLAB IR Missile Seeker Performance Analysis Tools (IRAT)
University of Florida STADIUM controller for multiple simulations using design-of-experiments technique

As planned, statements of input requirements for simulations will be exported from SLATE. Simulations will then be used to derive requirements which are collected in a standard format. These requirements will be imported into SLATE and also included in derivation analyses that are stored in Metaphase along with the simulation data. A link from SLATE to Metaphase will allow derivation analyses to be displayed for derived requirements. The exporting and importing of requirements from SLATE will be done via ASCII files, and the link to Metaphase via C++ and /or TCL APIs. (radeo.nist.gov/radeo)

SBD

In response to the Navy's Simulation-Based Acquisition thrust, the Defense Advanced Research Projects Agency (DARPA) initiated the Simulation-Based Design (SBD) program. Lockheed Martin Missiles and Space division has developed a set of SBD tools to provide a smart-product model repository and to interface tools to the central repository. The repository is compliant with CORBA and the interfaces follow the High-Level Architecture publish-subscribe model. The data interface to a tool to be integrated is defined in an object model that is registered with the CORBA repository. The interfacing tools are available from Lockheed Martin.

The SBD backbone tools operate on Sun and/or Silicon Graphics workstations. A port to Hewlett Packard workstations is currently under development. The current instantiation uses the Orbix product for the CORBA-compliant repository. Any tools to be integrated to the repository can run on the appropriate platform, with integration accomplished through the publish-subscribe mechanism over a network.

To date, the tool has been used for ad hoc integration of tools to support demonstrations of tool capability. It has been used to connect users at five geographically dispersed sites to simulate a missile attack on a ship, analysis of the weapon damage, redesign of the ship and a re-simulation. Several iterations of the design loop were performed to converge on an optimal design. The exercise was conducted using a Lockheed-developed requirements management tool for the source of the system requirements. (sbdhost.parl.com)

Notes

CASETS is a product of Boeing North American.
CATALYST is a product of Software Productivity Solutions.
CRADLE is a product of Structured Software Systems Limited.
DOORS is a product of QSS.
RASSP is a product of Lockheed Martin.
RDD-100 is a product of Ascent Logic Corporation.
Simulation Based Design is a product of Lockheed Martin.

Used by Permission.

Link to International Council on Systems Engineering

Return to Spotlight Archive



The itmWEB Site™, Copyright © 2006, itmWEB Media Corporation,
All Rights Reserved - webadmin@itmweb.com