General Aspects

Aspects in Requirements

You can give structure to your requirements using Aspects. They allow to categorize requirements as explained below.

There are different tags, each representing a particular Aspect the requirement may focus on.

There are 8 Aspects supported by AutoFOCUS:

• “Timing aspect” – the requirement refers to timing constraints
• “Signal aspect” – the requirement defines a signal, its type and its range
• “Parameter definition aspect” – the requirement defines a parametric value. This allows to reused other requirements by changing the value of the parameter
• “Safety level aspect” – the requirement defines a safety level of the system
• “Mode aspect” – the requirement defines an operational mode of the system
• “Design choice aspect” – the requirement was derived from a design choice of the software developer
• “Functional aspect” – the requirement specifies a particular behavior by relating inputs and outputs
•  “Temporal property aspect” – the requirement defines a property, which can be defined using temporal patterns

To add an Aspect, choose the requirement and right-click on it to get the pop-up menu. Now you can select the corresponding Aspects. All assigned Aspects to the requirement will be visible as Tabs in the main editor for Requirements.

Every Aspect can be removed from requirement using the respective button in respective Tab:

Below you can fined more detailed description of every Aspect.

Timing Aspect

You can add this Aspect to a requirement for referring it to timing constraints.

In this section you can define the Timing specification by checking the following constraints:

1. Latency, Response Time or Processing Time of the developed System

2. "should be" - this is an expression, if the chosen time parameter should be "equal", "lower", etc., than the necessary value, which is defined by you ( its value and unit) or
3. its range should be between two values

Signal Aspect

This Aspect can be added to a requirement for defining a signal.

Here you can specify all necessary signal parameters such as:

1. its Name
2. if it is an Input or Output signal
3. its Type (it can be integer, boolean, etc.)
4. Initial Value of the signal or
5. its range (!it doesn't work properly at the moment)
6. and its Update rate in milliseconds (ms)

Parameter definition Aspect

In this Aspect you can specify the reusable parameter in a requirement, by defining:

1. Name of the parameter
2. Default value of the parameter, which will be used during the simulation
3. Type of the parameter, such as "boolean", "int", "double"

Safety level Aspect

If your requirement refers to a safety aspect, you can specify a safety level defining:

1. one of the Safety Standards: "IEC 61508", "ISO 26262" or "DO 178C", on which the requirement is based on.

2. Safety Integrity Level (SIL from 1 to 4) (!it doesn't work properly at the moment)

Mode Aspect

This Aspect can be tagged to the requirement, which describes operational mode of a System.

In this section you can add information about the System's modes by right-clicking mouse onto the table "Mode", i.e. "Turn on" mode or "Switch off".

Design choice Aspect

This Aspect can be used, for example, in order to mark the requirement as a derived from the development process of the System  and added to the requirements' scope at the later phase of the System design process. This Aspect gives a reference to the DO178 standard, where such kind of requirements is described as “derived requirements".

Functional Aspect

A functional aspect specifies the relation of inputs and outputs.

The rows in the table to the left specifies the names (1) of the inputs and outputs (2) used in the relation.

The Code Specification specifies the relation between inputs and outputs.

Temporal property Aspect

Another one Aspect, which can be used in the behavior definition using temporal patterns. For this purpose you need to define a Condition Type :

• "When" - to describe an event,
• "If" - to define undesired a behavior,
• "While" - to define a system state,
• "Always" - to define ubiquitous

 According to your chosen [Condition type], you can apply the defined temporal pattern:

(1) [When] an event happens define [Precondition] and [Trigger(s)] for this event; then choose, how the system should behave choosing [Response Type: "Then always (state)" or "Then once (event)"] and define the Response]

(2) [If] system behaves in an undesired manner define [Precondition] and [Trigger(s)] for this behavior; then choose, how the system should behave setting [Response Type: "Then always (state)" or "Then once (event)"] and define the [Response]

(3) [While] system is in the state, define [Precondition] for this state; then choose, how the system should behave choosing  [Response Type: "Then always (state)" or "Then once (event)"] and define the [Response]

(4) [Always] describe, what your system should do always do [Response].