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.
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 are structured by Requirements Packages.
To add a new requirement, open the context menu of the requirements node. You can choose between the following requirement types:
Requirements consist of four respectively five sections:
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.
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.
This section contains the typical information for this kind of requirement.
Requirements can be traced to other requirements to document relations between requirements or to components to document the realization of requirements in the architecture. Refinement specifications can be created to ease the refinement testing process as well.
Requirements can be connected with each other by traces with different relation types.
Relation types are:
Differentiation of relation type in static relation types and process-dependent relation types:
Static relation types:
Process-dependent relation types:
Assign the source and target requirements by clicking the assign button.
A dialog will be opened where you can place the source and target requirements by dragging and dropping the requirements in the leftmost column. The middle column contains all referred source requirements while the rightmost column comprises all target requirements. Requirements can be removed by double-clicking.
To create a refinement specification, click the Add refinement specification button. A dialog will be opened where you have to choose your desired component to be refined. The selection depends on the assigned target requirements and whether they have formal specifications with concrete components.
After that, a second dialog will be opened to choose the desired refining component. The selection depends on the assigned source requirements and whether they have formal specifications with concrete components.
The refinement specification will be issued and shown in the editor right after the selections.
Traces to a component document the realization of requirements in 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.
Similar to the 'Traces within requirements' section, a dialog will be opened to choose the refining component originating from the formal specification of current requirement. The component to be refined is stated in the Target field of the relation already.
In this section you can specify the safety properties of the requirement.
Whenever the Safety Relevance of a trace link from the requirement to a component is set to yes, the SIL-level is relevant for the linked component.
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.
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.
MIRA offers support for an automatic review of the requirements. Furthermore, it also offers the possibility to save the results of manual review.
The button Review Requirements syntactically checks the structure of the textual requirements and its relations with predefined automatic 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, I: only interface behaviour requirements):
|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|
|A||Traceability||Requirement status at least analyzed||E7.2|
|A||Consistency||Requirements not conflicted||E9.1|
|A||Refinement||Refinement of declined requirements is also declined||E10.3|
|I||Implementation||Requirement connected to component in the component architecture||E11|
Additionally, automatic checks on the traces between requirements and from requirements to architecture are performed (A: all trace types, D: only directed relations, U: only undirected relations, E: only traces to component architectures):
|Trace type||Quality factor||Quality indicator||Check ID|
|A||Completeness||Existance of author.||E1.4|
|U,D||Completeness||Existance of trace type.||E1.4|
|U||Completeness||Existance of at least two target requirements in the trace.||E1.5|
|D||Completeness||Existance of at least one source and at least one target requirement in the trace.||E1.5|
|E||Completeness||Existance of a target component in the trace.||E1.5|
|A||Nonredundancy||No duplicated traces.||E2.2|
|A||Traceability||Trace status is analyzed.||E7.2|
|A||Consistency||No cyclic dependencies between directed traces.||E2.1|
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.