<i>Use Cases</i> are a special type of requirements. Following Jackson, a use case describes the behavior of the machine to achieve the desired
effect on the environment. Every use case contains one ore more <i>Scenarios</i> describing the interaction of the machine with its environment.
...
...
@@ -130,7 +130,24 @@ Additionally, every use case can be formalized to a <i>Formal Specification</i>.
<imgsrc="./pictures/MIRA.UseCase.png">
<br><br>
<h4><fontcolor="#336699">Change the Requirements Type</font></h4>
<h4>Connection of use case and component architecture</h4>
In the section <i>Detail</i> of a use case, a simple connection between use case and component architecture can be done:
<ul>
<li>setting the scope of the use case to be a component of the component architecture</li>
<li>connecting the trigger of the use case with an input port of the component architecture</li>
<li>connecting the pre-condition, min. guarantee, success guarantee of the use case with states of a state automaton of the component architecture</li>
</ul>
When the scope of a use case is connected with a component, then the reference to this use case is also listed below the component. So you can easily see which use cases belong to one component.
Double-clicking on the reference opens the corresponding Requirement-Editor.
The button <i>Export in ReqIF standard</i> opens a dialog, where all textual requirements descriptions and their hierarchy can be exported to ReqIF-format.
The button <i>Show Requirement Hierarchy</i> 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 automatic verification of requirements. Furthermore, it also offers the possibility to save the results of manual checks.
<br><br>
...
...
@@ -184,41 +199,114 @@ Requirements, that do not pass verification, are marked with a decoration and de
<br><br>
This list gives an overview over the implemented checks for the distinct requirements types (A: all requirements types, U: only use case):
<br><br>
<tableborder="1">
<thead>
<tr>
<th>Req. type</th>
<th>Qualitätsfaktor</th>
<th>Qualitätsindikator</th>
<th>ID</th>
</tr>
</thead>
<tbody>
<tr>
<td>A</td>
<td>Completeness</td>
<td>Existance of title and description</td>
<td>E1.4</td>
</tr>
<tr>
<td>A</td>
<td>Completeness</td>
<td>Existance of a complete description, TODO has to be empty</td>
<td>E1.5</td>
</tr>
<tr>
<td>A</td>
<td>Nonredundancy</td>
<td>Nonredundancy of title or description</td>
<td>E2.1</td>
</tr>
<tr>
<td>U</td>
<td>Nonredundancy</td>
<td>Nonredundancy of title and actors</td>
<td>E2.2</td>
</tr>
<tr>
<td>U</td>
<td>Nonredundancy</td>
<td>Nonredundancy of scenario steps</td>
<td>E2.4</td>
</tr>
<tr>
<td>U</td>
<td>Nonredundancy</td>
<td>Nonredundancy of scenario names within one use case</td>
<td>E2.5</td>
</tr>
<tr>
<td>A</td>
<td>Traceability</td>
<td>Requirement status at least analyzed</td>
<td>E7.2</td>
</tr>
<tr>
<td>A</td>
<td>Prioritization</td>
<td>Requirement prioritized</td>
<td>E8</td>
</tr>
<tr>
<td>A</td>
<td>Consistency</td>
<td>Requirements not conflicted</td>
<td>E9.1</td>
</tr>
<tr>
<td>U</td>
<td>Consistency</td>
<td>Consistent actors of scenario steps and use case</td>
<td>E9.3</td>
</tr>
<tr>
<td>A</td>
<td>Refinement</td>
<td>Refinement of declined requirements is also declined</td>
<td>E10.3</td>
</tr>
</tbody>
</table>
<br><br>
<h4>Support for manual verification</h3>
During the creation of each requirement automatically a list of checks is created in a second tab called <i>Checklist</i>.
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.
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.
<br><br>
<imgsrc="./pictures/MIRA.Checklist.png">
<br><br>
<h3><fontcolor="#336699">Connection of use case and component architecture</font></h3>
In the section <i>Detail</i> of a use case, a simple connection between use case and component architecture can be done:
<ul>
<li>setting the scope of the use case to be a component of the component architecture</li>
<li>connecting the trigger of the use case with an input port of the component architecture</li>
<li>connecting the pre-condition, min. guarantee, success guarantee of the use case with states of a state automaton of the component architecture</li>
</ul>
<h3><fontcolor="#336699">Export</font></h3>
When the scope of a use case is connected with a component, then the reference to this use case is also listed below the component. So you can easily see which use cases belong to one component.
Double-clicking on the reference opens the corresponding Requirement-Editor.
By double-clicking on the requirement analysis node, an overview over all requirements opens.
The button <i>Export in ReqIF standard</i> opens a dialog, where all textual requirements descriptions and their hierarchy can be exported to ReqIF-format.
