SLATE Assisted Mapping Requirements to Design

• Introduction to SLATE
• Using SLATE for the HSTN Problem

In this section we present SLATE capabilities to the extent we have used it. SLATE has much more functionality than discussed here

Introduction to SLATE

An important step in the systems engineering approach is the mapping of requirements into design. We can use tables to describe how different requirements refer to parts of the design process. This is however a difficult process and afterall, the result is difficult to read and understand.
Here is the definition of SLATE as from its designers, TD Technologies, Inc.:
"SLATE...a dynamic, multi-user information system for organizing and managing the product life cycle, from definition through eventual disposal."
Steps in creating a SLATE project:
Defining requirements and hierarchies:
The following figure shows the organization of requirements and hierarchies in the appropriate folders.

Fig 7.1 Defining requirements and hierarchies

• Functional Requirements
• Performance Requirements
• Interface Requirements
• Design Constrained Requirements
• Organizational Requirements
• Acceptance Requirements

Relationships are defined among requirements (from the Requirements Folder) abd hierarchy elements (in the Hierarchy Folder). Relationships show how different requirements affect certain elements of the design. This is basically the step of mapping requirements to design. The advantage is that we can very easy keep track of requirements change. The links are preserved, only the contents of the requirements change. In the case the requirement is deleted, all its links to different system elements dissapear.
The following figure depicts this process:

Fig 7.2 Defining Relationships

TRAM's are links between different views of the system. The aim of defining TRAM's is to trace requirements between two or more hierarchies.

Fig 7.3 Defining TRAM's

Using SLATE for the HSTN Problem

In this paragraph, we show the SLATE approach for our design problem.

The starting point as described above is the creation of the required folders. The components are:

• Requirements folder;
• Hierarchy folder;
• Documents folder - here we keep the project documentation;
• TRAMS folder here are all the TRAM's, even if they can be seen in the hierarchy folders, at certain nodes;

Fig 7.4 SLATE Main Window

The different types of requirements are organized in the requirements folder:

Requirements were classified into:

• NOS Requirements
• System Level Requirements
• EUS Requirements;
• SNS Requirements.

Fig 7.5 SLATE Requirements Window

The identified requirements are then organized in child folders.

Fig 7.6 SLATE Requirements Window Substructure

The leafs of requirements structure contain the actual text.

Fig 7.7 SLATE Requirements Window Leaf Nodes

We identified two views for our system: the software view and the hardware structure. These are presented in the figures below:

Fig 7.8 SLATE Hierarchies Window

The Software view contains all software modules used by the HSTN hardware.

Fig 7.9 SLATE Software Hierarchy

SLATE allows users to see an alterate view of the hierarchies, i.e. the hierarchy tree:

Fig 7.10 SLATE Software Hierarchy - Tree View

The hardware structure follows:

Fig 7.11 SLATE Hardware Hierarchy

As above, we may want to see the tree picture:

Fig 7.12 SLATE Hardware Hierarchy - Tree View

Creating TRAM's is the process of linking a source hierarchy node to a destination node located in one of the other views. In our case, we TRAM nodes from the software view to nodes from the hardware view.

Fig 7.12 SLATE TRAM's

General Design To Contents Conclusions