Skip to end of metadata
Go to start of metadata

Table of Contents

Internal Block Diagram of the View 2.1.

The purpose of this view is to define and refine internal and external requirements of the studied system. Figure 1 shows the drop down list in the main toolbar and gives access to different views, including the view 2.1

Figure 1. Drop-down list to access the view 2.1.

To add a Requirement to the system, enabling systems, or stakeholders, you can:

  • drag and drop the Requirement icon from the palette on the concerned object (see figure 2),
  • select the concerned object, right-click on it and then choose "Add New Object" or "Add Existing Object" to add a new or existing Requirement (see figure 3).

Figure 2. Palette of Objects in the View 2.1


Figure 3. Add a New or Existing Requirement to an Object by right click on it

Attributes of Requirements

You can then specify the attributes of the added Requirements either through the icon shown in figure 4 in the main toolbar or by right-clicking on the Requirement and selecting Properties.

Figure 4. Object Properties icon

Table 1 shows the properties of Requirements which contain three parts:

  • General attributes:
    • Name: Name of the Requirement such as WI-FI connection,
    • Type: Requirement which is filled automatically when the Object is created and cannot be modified,,
  • Attributes, their types, and their values:
    • ArkiId: a String (of maximum 255 characters) that is the unique ID of the Requirement,
    • Attachment: an attached file which contains related elements to the Requirement,
    • Description (Desc): a MEMO to give a description of the Requirement,
    • Rationale: a MEMO to explain why a parent Requirement includes the child Requirements,
    • Requirement type: an Enum to specify the type of the Requirement e. g. Performance, Constraint, High level, etc.
    • State: an Enum to specify the state of the Requirement in its life-cycle e. g. In analysis, Analysed, Approved, Fixed, Validated, Verified, etc.
    • Author: a String (of maximum 255 characters) to give the name of the person who created the Requirement,
    • Comments: a MEMO to add comments on the Requirement,
    • Flexibility: an Enum to determine the flexibility level of the Requirement i.e. how the Requirement is negotiable,
    • Milestone: a String (of maximum 255 characters) to determine the date of validation of the Requirement according to the different versions of the product,
    • Original_ID: a String (of maximum 20 characters) that is the automatic ID of an imported Requirement from Doors,
    • Source: a MEMO to give the reference of the documents that describe the Requirement,
    • ASIL Safety Goal: an Enum to determine the Automotive Safety Integrity Level,
  • Validation Attribute Group: these attributes are explained in the view 6.3 


Table 1. Table of Properties of Requirements

Attributes not managed under revision


The following attributes will not generate a revision management change when edited (1.0 -> 1.0*):

  • Requirement type
  • state
  • Author
  • Original_ID
  • ReqIF.ID
  • Spec Review
  • MIL Module
  • MIL SW
  • PIV


Refine Requirements

During the conception Process, Requirements become more and more detailed and can be transformed to technical Requirements. Figure 5 shows an example of refinement. You can see that a Stakeholder requirement is detailed by two System Requirements.

Figure 5. Refine a Stakeholder Requirement into two System Requirements

In order to refine a Requirement, you can:

  • either use the "Link Components" icon in the toolbar,
  • or select the Requirement to be refined (click on it). Then, right click on it to select "Add New Object" / "Refine".

In a similar way, a System Requirement may imply the Stakeholder Requirements. In this case, the Refine direction comes from the System and goes to the Stakeholder. It should be noted that the direction of Refine is important and shows the direction of the implication. To choose the "right" direction, you should know which Requirement has implications on the other ones.

Tabular View of the View 2.1.

In the Tabular view of the view 2.1., as in its Internal Block Diagram, we can define and refine the Requirements. Projects Tools gives access to Tabular views (see figure 6).

Figure 6. Tabular View of the View 2.1. in Project Tools

a. Define Requirements

In table 1 you can define and refine requirements and specify their attributes.

Table 1. Define Requirements  through Tabular View

Three buttons are available in the top left-hand corner of the table:

  • Open RMGW file: to use a RMGW (see the documentation on Model GateWay),
  • Export to Excel: to export the table to an Excel file,
  • Append Line: to add a new line at the end of the table.

Using the last one (Append Line) you can add a new row to create a new Requirement (see figure 7).

Figure 7. Add a new Object in Tabular view 2.1

By right-clicking on the cell of ID of each existing Requirement, you can replace it either by another existing Requirement or by a new one. In the same way, you can insert or remove a row (see figure 8).

Figure 8. Modify the Content of the table in Tabular view 2.1

When the modifications are done in the table, three buttons (in the bottom right hand corner of the table) allow you to apply or cancel them:

  • Apply: modifications are taken into account in the table,
  • OK: the same as Apply, but it switches the view back to the Internal Block Diagram,
  • Cancel: modifications are deleted and the view is switched back to the Internal Block Diagram.


  • No labels