Table of Contents
Internal Block Diagram of the sub-projection 6.2.
The purpose of this sub-projection is to define the Tests and allocate them to Requirements. Then, a VM can be allocated to a Test. The Figure 1 below shows a drop-down list, in the main toolbar, which gives access to the sub-projection 6.2.
Figure 1: Drop-down list to access the sub-proj. “6.2. Define Tests”
In this sub-projection, the Requirements of sub-projection “2.1. Define requirements” are initially loaded. By a drag and drop of the Objects from the palette (see Figure 2) or adding existing ones inside the System, we can:
- create new Tests (possibly several) for each Requirement
- allocate an existing Test (created before) to one or several other Requirements
- set which Validation Means will be used for each Test (by allocating it to the Test via “add existing” or “drag & drop” between trees)
- optionally (advanced users) create and allocate Observed and Stimuli signals to Tests in order to specified the Tests,
- Stimuli signals include the input flows of the Tests,
- Observed signals include the output flows of the Tests,
- optionally allocate VP flows, Data and Physical flows to the signals created before.
Figure 2: Palette of Objects in the sub-proj “6.2. Define Tests”
Similarly to the Validation Means, we can fill the tables of the properties for the Tests. Additionally to the common attributes (already discussed in sub-projection “6.1. Define Validation Means”) such as Name, desc, etc., there are specific other attributes for Tests.
This table (shown on Figure 3) contains specifically:
- Attributes, their types and their values:
- 1. Initial Condition: a MEMO to describe the initial conditions (input values, etc.) of the Test,
- 2. Expected Result: a MEMO to describe the result (output values, etc.) which is expected if the test is run suitably and the corresponding Req fulfilled,
- Author: a String (of maximum 255 characters) specifying who has designed the Test.
- CSR type: a String (of maximum 255 characters) specifying wthe safety and regulatory state of the Test.
Figure 3: Properties table of a Test
Figure 4 shows an extract of the sub-projection “6.2. Define Tests” tree for the Laptop example. We can see the main Objects discussed before and the parent-child relations:
Figure 4: Laptop example tree (extract) in sub-proj. “6.2. Define Tests”
Tabular View of the sub-projection 6.2.
Figure 5 shows the actions in the Tabular View of the sub-projection 6.2.
Figure 5: Tabular View of the sub-proj. “6.2. Define Tests” in Project Tools
a. Define Tests
In the table illustrated in Figure 6 below, you can define a Test from column “test id”, which is allocated to the Requirement indicated in the first column of the current line.
Figure 6: Define Tests through Tabular View (sub-proj. “6.2. Define Tests”)
b. Allocate Validation Means to Tests
In the table illustrated in Figure 7 you can allocate VMs to Tests. There are two sheets in this table. The first sheet shows the list of all the Tests and their allocated VMs. This sheet allows checking whether each Test has at least one allocated VM. The second sheet contains the list of all the VMs and the Tests they are allocated to. This sheet allows checking whether all VMs are allocated to Tests.
Figure 7: Allocate Validation Means to Tests through Tabular View (sub-proj. “6.2. Define Tests”)
c. Matrix Test on Requirement
This matrix (Figure 8) is used to match existing Tests on Requirements. The sign "X" in a cell means that the Requirement (line) and the Test (column) are matched, as shown on the screenshot below:
Figure 8: Match Tests on Requirements through Tabular View (sub-proj. “6.2. Define Tests”)
Comment: This table is another representation of information present in a. Define Tests with two main differences:
- less attributes are displayed and the focus is more on the relationship between Tests and Requirements,
- a new Test cannot be defined here : just existing ones (defined previously) are shown.