MIRA - Model-based Integrated Requirements Analysis

Create a Requirements Node

Before creating Requirements, you have to create a Requirements Analysis node.

Create a new Requirements node by choosing Requirements, in the context menu of the Requirements Analysis node.

Change the name of a Requirements node in the properties view. You also can create multiple requirement nodes with different names to organize your requirements.

Requirements Overview

By double-clicking on the Requirements node, an overview over all requirements opens.

The list of requirements can be sorted by clicking on the column headers of the overview list. You can filter the requirements by inserting a filter text in the filter section. Double-clicking on a column opens the corresponding requirement source element.

Requirements Packages

Requirements are structured by Requirements Packages.

Specify Requirements

To add a new requirement, open the context menu of the requirements node. You can choose between the following requirement types:

Requirement for every kind of requirements
Use Case to describe the interaction of the system with its environment

Requirements consist of four respectively five sections:

General: Here all requirements management fields are located together with the fields describing the requirement informal.
Images: Here you can add images to the entry.
Detail: The specific fields for this requirements type are shown in this tab. Only for specific requirements.
Traces: Relations between requirements and to architecture are managed here.
Safety: Here you can specify safety-related information.
Comment: This tab is for comments.

Section General

In this section you can enter typical requirement management information.

The Document Reference connects the requirement with a source Document from the Requirement Sources. You can add a page number for local documents. When clicking on the reference, the document opens automatically at that page.

Section Images

For further description of the entry you can add pictures in the Images-section. To add a picture click on the Add button and choose an image file in the dialog. You can add as many pictures as you want. If you add a picture, it will be copied into the images folder in the AF3-Project-Directory, next to your .af3_20 file. If you want to send the model file to someone else, you should also send the images folder. Each image has a description field which can be used to give information about the picture and to number the pictures. If you click on an added picture, it should be displayed in full resolution in your systems picture viewer.

Section Detail

This section contains the typical information for this kind of requirement.

Section Traces

Requirements can be traced to other requirements to document relations between requirements. Furthermore requirements can be traced to components to document the realization of requirements in the architecture.

Traces within requirements

Requirements can be connected with each other by traces with different relation types.

Relation types are:

Refinement: the source requirements refine the target requirements
is contradicting to: requirements are unresolvable contradicting each other
is overridden by - overrides: requirement replaces the other requirement
is conflicted with: a conflict between two requirements was detected, which has to be analyzed further

Differentiation of relation type in static relation types and process-dependent relation types:

static relation types are conserved after the refining process
process-dependent relation types like is conflicted with have to be removed during the refining process

Static relation types:

is refined with - refines
is contradicting to
is overridden by - overrides

Process-dependent relation types:

is conflicted with

Traces to architecture

Traces to architecture document the realization of requirements in the architecture. Requirements can be traced to components of the component architecture. To set a trace to a component, press the Add button to create a new trace. To add a component, press the

button. To delete a trace, select the row by clicking on the left side of the column. Then press the Remove button.

Section Safety

In this section you can specify the safety properties of the requirement.

Whenever the Safety Relevance of a trace from the requirement to a component is set to yes, the SIL-level is propagated to the component in form of a Safety Specification.

Change the requirement type

To change the requirement type from Use Cases to Requirement or inversely, click the combo box labeled Type, and then choose the desired type.

Attention please, changing the requirements type deletes all information that is not contained in the new requirements type. To continue, click the button "OK" on the confirm dialog.

Formal Specification

A requirement can be formalized to a partial formal model, a Formal Specification. To create a formal specification open the context menu of the requirement and select Formal Specification.

Within a formal specification different kind of models like component architectures, state machines, etc. can be used. For more information see Modeling and simulation. Formal specifications can be used as input for the generation of test cases, see Model-based Testing. The conformance of the architecture implementation with the formalized requirements can be tested as described in Refinement Testing.

Requirement Hierarchy

The button Show Requirement Hierarchy opens a view, where all relations of the current requirement are shown, divided by relation types. Double-clicking on the requirements in the hierarchy opens the corresponding requirement in the editor.

Review Requirements

MIRA offers support for an automatic review of the requirements. Furthermore, it also offers the possibility to save the results of manual review.

Automatic requirements review

The button Review Requirements checks the structure of the textual requirements and its relations automatically with predefined checks. Requirements, that do not pass one of these checks, are marked with a decoration and details on the results are shown in the warning list of the Model Markers.

This list gives an overview over the automatic checks for the distinct requirements types (A: all requirements types, U: only use case):

Req. type	Quality factor	Quality indicator	Check ID
A	Completeness	Existance of title and description	E1.4
A	Completeness	Existance of a complete description, TODO has to be empty	E1.5
A	Nonredundancy	Nonredundancy of title or description	E2.1
U	Nonredundancy	Nonredundancy of title and actors	E2.2
U	Nonredundancy	Nonredundancy of scenario steps	E2.4
U	Nonredundancy	Nonredundancy of scenario names within one use case	E2.5
A	Traceability	Requirement status at least analyzed	E7.2
A	Prioritization	Requirement prioritized	E8
A	Consistency	Requirements not conflicted	E9.1
U	Consistency	Consistent actors of scenario steps and use case	E9.3
A	Refinement	Refinement of declined requirements is also declined	E10.3

Support for manual reviews

During the creation of each requirement automatically a list of checks for the manual review is created in a second tab called Checklist. The list is extracted from a XML-template, which can be modified. At the moment, this XML-template is contained in the source-folder of MIRA.