Requality: glossary
A
Active node template (active template)
- is a node template that has been set as active for this concret node type.
If the templates is set as active all this type nodes will be created by the template by default. At the beginning empty template
is set for all project nodes , all parameters in the template have dafault values.
(See Templates editor.) For one node type there could be only one active template.
Active template is marked with bold font in the list of templates in template editor view.
Attributes table (attributes)
– is a set of parameters - attributes - of any 'Requality' project node. These parameters describes different properties of the node.
- Attributes are set in 'Properties view'.
- Every attribute has name, type, value, scope. Also attribute could have a values generator.
- Attributes could be set manually or generated authomatically by the generator, parameters of generator should be set manually by a user.
- Attribute could be inherited from the parent node, in this case it is marked by an arrow-symbol.
- Attributes could be used in predicates, in nodes description, in nodes reusing and nodes iteration.
- There are some attributes that are set authomatically, for example, date of report generation.
- Some attributes should have pre-defined names, usually these
attributes are generated authomatically with the help of wizards (e.g. attribute 'coverageFilePath' of 'Report Settings' node,
that sets a path to coverage information source file).
- For different node types attributes differs.
Attributes are presented in a table with columns: 'Name', 'Type', 'Value', 'Scope' and
'Generator' (attribute values generator).
C
Clone, clone-node
- is a child node of a virtual node, created based on other node (so called reused node) of requirements tree by properties of the virtual node (see 'Virtual node properties'). By default clone gets a type and properties of the reused node. But its properties can be changed by user. In 'Requality Explorer'
view an icon the clone-node is marked by additional image of the letter 'V'.
Comment
- is an entity that contains some text comment and refers to the requirement, text node or test purpose.
One requirement/text node/test purpose may have several comments.
Comment properties
- are comment parameters that are specified and could be set in the 'Properties' view.
For Comment node 'Properties' view contains two tabs
- Main tab contains the following requirement parameters of comment:
- Id – comment identifier. The identifier is unique among the children of the one parent. Couldn't be changed manually.
- Name – name of the comment. It shouldn't be unique. Name is empty by default. Name could be changed manually.
- Author – author of the comment. By default this field is filled in accordance with the settings of the operating system.
- Field for text of the comment. Is empty by default. Could be changed manually.
- Source tab contains only json-code:
- json – low-level representation of the comment
as an entity. Is not edited.
Coverage file
- XML-document that sets a coverage of requirements and
test purposes by other elements (test for example). It is used to generate some kind of reports.
Format of the file:
<?xml version="1.0" encoding="UTF-8"?>
<coverageInfo>
<reqcoverage qid="unique_id_of_requirement_or_test_purpose">
<covered_by uri="path_to_covering_element" [hits="1"]/>
</reqcoverage>
<reqcoverage qid="unique_id_of_requirement_or_test_purpose">
<covered_by uri="path_to_covering_element"/>
</reqcoverage>
<error [name="error_name"] testuri="uri_of_covered_by_element" [uri="link_to_error_description"]>
[<violates qid=unique_id_of_requirement_or_test_purpose"/>]*
[<description [format="error_description_format"]>error_description</description>]
</error>
</coverageInfo>
Here:
Square brackets denote optional parameters.
-
coverageInfo - can be only one instance in the file. It contains multiple XML-elements reqcoverage (one or more) and error (can be absent, one or more)
-
reqcoverage - child-element for coverageInfo. Should be specified for every covered Requality-element. (Uncovered nodes are not specified at all.)
Contains nested XML-elements covered_by (one or more). Every nested covered_by element should match one test procedure or test.
reqcoverage element has attribute qid.
-
id - is user-visible-name(element) or qualifying-id(element) of the covered element:
-
user-visible-name(element) - is element name (if exists, i.e. if for this element name field in Properties view is not empty),
otherwise it is specified as user-visible-name(element.parent)/id, i.e. first specify user-visible-name of parent element, then specify element id (use '/' as delimeter).
For example:
"TR-FMF-01-01-002/TR-FMF-01-01-002_T01"
-
qualifying-id(element) - is full path to the element beginning with root node (Requirements), '/' is used as a delimeter.
For example:
"Requirements/01/MyRequirement01"
-
covered_by - child element for reqcoverage. There could be several covered_by elements inside reqcoverage, it depends on how many test procedures or
tests cover corresponding Requality-element. Every covered_by element matches one covering Requality-element. covered_by has attributes: uri and hits.
-
uri - is attribute of covered_by XML-element, it specifies a path to the test described in this covered_by element:
-
if it is described a coverage of test purposes by test procedures then here uri is a path to test procedure step.
-
If test procedure is situated in the same project then the path is specified without protocol, for example:
"/TestProcedures/01/TestStep04"
Here 01 - test procedure id, 04 - test procedure step number.
-
If test procedure is situated on the other Requality project then path looks like:
"requality://ProjectName/TestProcedures/01/TestStep04"
Where ProjectName is a name of the project where test procedure is situated.
-
if it is described a coverage of test purposes by test then here uri is a path to test. For example:
"file:///home/user/work/test1.c#12"
-
hits - attribute of covered_by XML-element, it is optional. Indicates how many times this reqcoverage requirement is linked to in covered_by test.
-
error - element to describe error resulting from the test. Includes one description element with error description. Includes one or more
optional violates elements if it is possible to define which exactly requirements are violated by this error. error element has attribute
testuri and two optional attributes: name and uri.
-
testuri - path to test described in covered_by element
-
name - optional parameter, it is used to show displayed error name. If error name is not defined then "error"+error_index_number is used as name.
-
uri - optional parameter, path to file with more information about the error.
-
violates - optional element, corresponds to requirement that is violated by the error. Every violates element corresponds to one violated
requirement. violates element has attribute qid. If violates is not defined the error will not be shown in a report.
-
qid - is user-visible-name(element) or qualifying-id(element) of covered element(for more details see description of reqcoverage element above).
-
description - optional element, text description of the error. Has optional format attribute.
-
format - format of error description. Can be "html" or "plain". In case of "plain" all html tags will be shown as plain text.
-
error_description is a text of error description. For "html" format it is allowed to use html tags for text formatting.
D
Document
– is a xhtml-document that contains requirements written in a free form. User marks text fragments in the document
and assigns them to the requirements.
E
Enumerated attribute type (Enum)
– is attribute type, defines a list of available attribbute values. 'Enum'
type can be set manually in 'Properties' view of 'Requality' project
(see 'Project 'Requality' properties') as ordinar attribute of project node:
- The name of this attribute will be considered as the name of 'Enum'-type.
- 'ENUM_DEFINITION' should be set as a type of this attribute.
- The value of this attribute is a list of values. It can be set manually with the help of values editor
or by using additional option of attribute extraction (from all project nodes).
- The editor is opened by clicking in 'Value' cell. All available values and comments (if needed) are listed in the editor window.
This is a view of the Enum values editor window:
- 'Enum' extraction process is started by 'Extract enum definition from attributes' button in the 'Properties' view opened for project node.
Here user can choose one of attributes used in project tree nodes. And select new type name (by default it will be the name of the selected attribute).
At the end all this attribute values turns into the list of Enum-type values. And all attributes that were collected for 'Enum'-type, will get
the name of the newly created enumerated type as the name and preserve their values.
- Attribute 'ENUM_DEFINITION' is not inherited by other project nodes as usual project attribute. But it sets 'Enum'-type
and this type is shown in the list of available values for all attributes in the project (to avoid confusion, it is displayed with a prefix Ⓔ).
G
Generator or Attribute value generator
- is a special functionality to generate a list of attribute values automatically.
Any node of Requality project (besides folders and documents) has a table of attributes in Main tab of 'Properties' view. There is a column Generator in
the table. You can open Attribute value generator wizard by clicking in a cell in this column.
Attribute value generator wizard window contains the following parameters:
- Origin – element of requirements tree in which the generator is described.
Couldn't be edited manually. Generally it shows the node for which this attribute values generator has been opened.
But if considered attribute has been inherited from other node this node will be shown in Origin field.
- Attr.gen.type – a method of how to generate attribute.
There are three methods of attribute generation: 'RANDOM', 'BY_FORMULA', 'CYCLE'.
- RANDOM - random generation. If this method is selected three edit field appear:
'Min' (minimum value of random set),
'Max' (maximum value of random set) and 'Count' (number of generated values).
- By default all these values are set to 0.
- These values could be edited manually.
- 'Max' value should be not less than 'Min' value,
but if user sets values conversely field values change places with each other.
- Changes in these fields effect on 'Preview' field.
- Also if 'RANDOM' is set button 'Generate new set' appears.
Pushing this button generates new set of values in the 'Preview' field.
- BY_FORMULA - generation of values in accordance with a defined formula. If this method is selected 'Formula' field appear.
- By default 'Formula' field is empty. Could be edited manually.
- Formula should be written as JavaScript expression. The node attributes could be used as expression variables.
- Example: set in 'Formula' field value: 'element'+_i, where i is other attribute of the node with value 'IValue',
generator will generate value element_IVALUE.
- CYCLE - generates values by iterating cycle From-To(by initial state, final state and step).
If this method is selected three edit field appear: 'From', 'To' and 'Step'.
- By default all these values are set to 0.
- These values could be edited manually.
- 'To' value should be not less than 'From' value,
but if user sets values conversely field values change places with each other.
- Changes in these fields effect on 'Preview' field.
- Preview - a field which displays a set of values generated by the selected method.
The content of this field is the result of setting generator parameters. It is empty by default. Editing is possible indirectly by
changing generator parameters. (see editing of 'Attr.gen.type' field).
L
List values editor
- is used to set and change values of LIST attribute.
List values editor wizard contains two following elements:
- drop-down menu to select type ('INT', 'FLOAT', 'BOOL', 'STRING', 'LIST', 'REFERENCE').
- list of values. Could be edited manually. Order of the list could be changed with the help of arrows on the right.
Location
– is a part of the document
that has been marked by user as belonging to any requirement. So the location means both
the marked part of the document and a link in requirement properties to this part of the
document. One location could belong to several requirements
in one project simultaneously.
M
Markup Editor
- is a view in the 'Requality' perspective, it's a document editor. It is used to mark requirements fragments in the documents.
Module Editor
– is a view in the 'Requality' perspective, it's a visual editor to present requirements and text nodes as plain document view.
It's designed to develop documentation by requirements creation. In contrast to 'UniEditor' and
'Review' editors in this editor nodes are shown without tabspaces, such approach allows to show requirements catalog
in more compact view, but it doesn't allow easy way to see the hierarchy. To analyse requirements hierarchy in the view it's recommended to use requirements tree in
'Requality Explorer' view.
N
Node properites
– are a set of the node parameters. Are specified and could be set in the 'Properties' view. There is also a restricted set of parameters in
'parameters editor' dialog window. This dialog can be opened in 'Module Editor', 'UniEditor' and 'Review'.
Node template
– is an entity corresponding to one of node types ('Comment', 'Report Settings', 'Requirement', 'Test Purpose',
'Text Node', 'Virtual Node') of the 'Requality' project. It work as a template to create new nodes of the same type.
- Node template properties (see 'node template properties') are similar to properties of the ordinary same type node.
- Node template parameters can be set by a user.
- When creating new node by the node template this new node gets all parameters of the template node.
- There could be many templates of the same type node in one project. But there is the only one active node template -
the template that is used by default.
- The user can set 'active template' for every node type except for the folders and reports.
- By default the active node template is blank, i.e. all its parameters has default values (see 'Templates editor').
Node template properties
– are a set of the node template ('node template') parameters. Properties of some type node template are similar to properties of this type node.
Parameters are specified and could be set in the 'Properties' view.s
O
Outline
- a view in the 'Requality' perspective that displays the list of the document locations.
P
Project 'Requality' properties (project properties)
– project 'Requality' parameters. Are set as parameters of the root project node. Are specified and could be set in the 'Properties' view.
'Properties' view for the project node has 2 tabs:
- 'Main'
- Button 'Extract enum definitions from attributes' opens a dialog for extraction Enum-type from existing project attributes.
See 'Enumerated attribute type (Enum)'.
- 'Attributes' are project attributes represented in a table (see 'Attributes table'). Attributes table is mostly similar to attributes
tables of other project nodes, but it has no 'Scope' column. Read more about attributes table
here. All project attributes have global scope by default,
so these attributes are inherited by whole the project tree.
In project attributes table there can be set 'ENUM_DEFINITION' attributes, such attributes are used to
specify enumerated type to use it in other nodes attributes. Read more 'Enumerated attribute type (Enum)'
- 'Templates' tab is similar to 'Templates editor' dialog window and has the same functionality.
See 'Templates editor'.
Properties
- is a view in the 'Requality' perspective that displays the parameters of the selected object (requirement, document, test purpose, report, comment).
R
REFERENCE attribute type
- is a special attribute type of requirements, virtual nodes and test purposes, which allows to link its node
to some other node of the same 'Requality' project catalog. 'REFERENCE' attribute could be added in 'Properties'
view in 'Main' tab in 'Attributes' table. It's a usual attribute of 'REFERENCE' type,
that has a value - target node to link to.
The nodes linking is represented in 'Requality Links Explorer' view.
In this view links are available in both sides – both from node with created attribute:
and from linked node indicated in the 'Value' field of the REFERENCE attribute of first node:
Referred requirement
- target requirement referred to by other requirement (related requirement).
Related requirement
- initial requirement related to other requirement. Related requirement has 'REFERENCE' type attribute. This attribute contains (referred requirement).
Report
– is a document that contains a ready report generated by settings set in ReportSettings node.
The report has a set of not editable parameters that allows to see what settings has been used to generate this report.
Only report name could be edited. By default the name of the report contains date and time of generation.
Report by 'Coverage' template
- presents information about coverage of requirements and test purposes by other elements (tests for example)
with the help of additional data source. There are 2 possible sources of coverage data:
- A file in special format
- Automatic search of files that contain identifiers of requirements or
test purposes covered by that files
In this case Requality performs search over user-selected projects
in current workspace looking for files with user-selected extension. For
found files it is performed line-by-line check over its content by
regular expression defined by user. As a result, a set of covered
elements and related covering files is collected.
Report by 'Document Model' template
- presents information about coverage of locations in document
by other elements (tests for example) with the help of additional data source.
There are 2 possible sources of coverage data:
- A file in special format
- Automatic search of files that contain identifiers of requirements or
test purposes covered by that files
In this case Requality performs search over user-selected projects
in current workspace looking for files with user-selected extension. For
found files it is performed line-by-line check over its content by
regular expression defined by user. As a result, a set of covered
elements and related covering files is collected.
Report by 'Progress' template
- presents project statistics from different SVN revisions..>
The report consists of two pages:
- First page contains following diagrams:
- Diagram shows total number of nodes: requirements (not leaf and leaf nodes), test purposes.
- Coverage diagram.
- Diagram shows ratio of requirements number an test purposes number.
- Second page contains total spreadsheet with numeric characteristics for revisions: number of requirements,
test purposes, number and ratio of covered and not-covered requirements.
To create the report the user could set report settings (required time period and time step between revisions)
and also user can set the coverage source, where to take coverage date from.
Report by 'Traceability' template
- contains project catalog nodes and links between.
The report consists of two pages. First page contains information about direct links, second page
contains information about reverse links. By default first page is opened. To open second page you should click on reverse link name (the name could be set in project properties).
To turn back click on direct link name.
Report properties
- are Report parameters that are specified and could be set in the 'Properties' view.
Report parameters are identical to Report Settings parameters (except 'date' attribute), but are not editable (except 'Id' parameter).
- Id parameter here is Report identifier,
it is shown on 'Report Settings' tab of 'Properties' view. By default it includes id of 'Report Settings'
(refers Report Settings that has been used to generate this Report) and generation date and time. But it could be edited manually.
- Attributes table contains date attribute. It is generated automatically when report generating and contains generation date and time.
Report Settings
– is an object that allows generating report that contains a summary of the project (number of verified and not verified
requirements, test purposes coverage of requirements, requirements coverage of document, etc.). It has a set of parameters
that influences the content and form of the report and defines a source of report data. Several reports could be generated based on a single
Report Settings node. Changing Report Settings does not affect the reports that has been already generated.
Report Settings properties
- are Report Settings parameters that are specified and could be set in the 'Properties' view.
For Report Settings node 'Properties' view contains two tabs:
- Report Settings tab contains the following report parameters:
- Id - Report Settings identifier. The identifier is unique
among the children of the one report folder. It could be changed manually.
- Root requirement – the requirement
for which report will be generated. Only this node and all its children nodes (requirements
and comments) will be considered in the report. In the case of additional plug-ins for Requality,
nodes of other types could be included in the report. Could be changed manually.
Template – a template which form and content
defines how the report looks like and what data it contains. For example, data can be represented as a list
or a table. Also report could include all nodes of the Requirements tree or only nodes of some specific type.
In the case of plug-ins for Requality, list of available templates can be expanded. You can create required
templates by yourself. The template could be changed manually: just select it in the list of the possible
templates. Following templates are available by default: 'Coverage', 'XML-export', 'Requirements',
'Document Model', 'Test Purposes Coverage', 'Progress' and 'Traceability'.
List of available templates could be expanded if you add your own templates or use additional
plug-ins for Requality.
'Coverage' - contains information about coverage of requirements and test purposes by other elements (by tests for example).
It's required to set source of coverage information for report generation. Read more about 'Coverage' here
'XML-export' - a report in XML, is designed to use Requality reports by other tools.
'Requirements' – contains list of all requirements.
'Document Model' - is similar to 'Coverage' but shows information about coverage of locations in a document.
'Test Purposes Coverage' - contains summary of the current status (in process, verified, etc.) of requirements ant test purposes.
'Progress' - experimental template, presents statistics about number of requirements and test purposes from different SVN revisions.
'Traceability' - contains project catalog nodes and links between.
- Attributes – the attributes of the Report Settings,
are set in the table. More about attributes table you can read here.
If it's required to set coverage data source for report generation this data will be added to attributes table
as value of 'coverageFilePath' attribute. The attribute table could be changed manually. Information about the source of coverage data could be added
to the table as attribute coverageFilePath. To set or edit this attribute there is button 'Update Coverage Source'.
The button appears on the tab if report generation requires coverage data.
- Source tab contains only json-code:
- json – low-level representation of the report
as an entity. Is not edited.
Requality Explorer
- is a view in the 'Requality' perspective, that displays all content of the project (documents, requirements, reports, comments).
Requality Links Explorer
- is a view in the 'Requality' perspective, that displays project catalog nodes linked with selected node by 'REFERENCE' type attribute.
Requality project
- is an Eclipse project created using Requality plug-in. It contains documents, requirements, reports and comments.
Requirement
– is an entity
that contains a description of some requirement, and links to those parts of the
document that reference to this requirement.
- The requirement may have no description
and no links to the document. Such requirements are usually used for organization
of the hierarchical structure of requirements, acting as parent nodes.
- Only requirements
without child-requirements in the hierarchy can have test purposes.
- Every requirement
has a set of parameters that specify its content and properties (see 'Requirement properties').
- Requirement can be converted to a 'Text Node' keeping all parameters.
Requirement properties
- are requirement parameters that are specified and could be set in the 'Properties' view.
For requirements 'Properties' view contains four tabs:
- Main tab contains the following requirement parameters:
- Id - requirement identifier. The identifier is unique
among the children of the one parent. It could be changed manually.
- Name – name of the requirement. It shouldn't be unique.
Name is empty by default. Name could be changed manually.
- Type – requirement type. For requirement it is always 'Requirement'.
This field has a drop-down list and allows to switch node type to Text node ('Text' or 'Header').
- Attributes – the attributes of the requirement. Are represented in a table.
Read more here: 'Attributes table'.
- Description tab contains the following requirement parameters:
- Alternative Description –
- alternative text of the requirement, that specifies and supplements the text of the selected fragments.
It could be changed manually.
- Locations - the list of locations of the requirement,
grouped by documents. Manually you can only delete locations.
- Advanced tab contains:
- Predicate – a predicate, defines what requirements
will be included in reports. Predicate is inherited from the parent requirements by default.
Could be changed manually.
- Source tab contains only json-code:
- json – low-level representation of the requirement as entity. Couldn't not be edited.
Reused node
- any node of requirements tree, that is set as target for iteration in virtual node properties (see 'Target' in 'Virtual node properties'. Clone-nodes (see 'Clone') of this virtual node are created based on the reused node. But it doesn't influence on the reused node itself. Changes of reused node or its subtree are influence on the clone-nodes.
Review
- is a view in the 'Requality' perspective, it's a visual editor for requirements, test purposes and comments.
It is designed for viewing rather than editing, so it has limited functionality. It allows only adding, editing and deleting
comments and changing the status of requirements and test purposes. In contrast to 'UniEditor' it allows setting statuses
of the requirements and test purposes into the value 'verified'.
S
Sub-requirement, or child requirement
- a requirement that is a child node for some other requirement in the project hierarchy.
T
Templates editor
is an editor for node templates (см. 'Node template').
Allows to create, delete, edit node templates and set active templates. Can be opened from editors: 'Module Editor', 'UniEditor', 'Review'.
Contains fields:
- Select Node Type - drop-down list to select node type. It specifies the type of nodes to work with in the templates editor view.
So if 'Requirement' type has been selected in this list then only requirement templates will be shown in the list of existed
templates and every new template will be created for requirement node type.
- Create template - a button to create new template.
- Extract template - a button to create new template based on an existing node.
- List of templates - a list of available templates for the node type selected on 'Select Node Type' drop-down list.
- Edit - a button to open editor for the template selected in the 'List of templates' field.
- Remove - a button to delete the template selected in the 'List of templates' field.
- Set as active - a button to set selected in the 'List of templates' template active
(see 'Active node template').
Blank template - 'Empty' - is active by default.
Active template is marked with bold font in the 'List of templates' field.
Test purpose
– is an entity that contains
the description of the test cases and expected results. Test purpose belongs only to the requirement
that has no requirements-children. Every test purpose has a set of parameters that specify its
content and properties. One requirement could have several test purposes.
Test purpose properties
- are test purpose parameters that are specified and could be set in the 'Properties' view.
For test purposes 'Properties' view contains four tabs:
- Main tab contains the following test purpose parameters:
- Id – test purpose identifier. The identifier is unique for all test situations
of the one requirement. It could be changed manually.
- Name – test purpose name. The identifier can be not unique. Is empty by default. Can be changed manually.
- Status - test purpose status. It could be: 'in
process', 'complete' or 'verified'.
Could be changed manually.
- Author - an author of the test purpose. Could be changed manually.
- Attributes – the attributes of the test purpose. Are represented in a table.
Read more about attributes table here.
- Description tab contains the following test purpose parameters:
- Test purpose description - a description text of the test purpose. Could be changed
manually.
- Expected results - result expected for the test purpose.
- Advanced tab contains:
- Predicate – a predicate, defines what requirements will be included in reports.
Predicate is inherited from the parent requirements by default. Could be changed manually.
- Source tab contains only json-code:
- json – low-level representation of the test purpose as entity. Couldn't be edited.
Text Node
is an entity that contains some text. It is designed to store and display the notes and comments included in documents.
Such text is a part of document but is not a system requirement.
- The text node is similar to 'Requirement' but is not a 'Requirement' node, and it will not be shown in report
about requirement coverage or report about coverage by requirements.
- Text node has a set of parameters which defines its content and properties (see 'Text node properties').
- There ate two formats of the text node: simple text ('text') and header text ('header').
The format of the text node affects on how it looks like in 'UniEditor' and 'Module Editor' editors.
- Text node can be converted to a 'Requirement' keeping all parameters.
Text node properties
are text node parameters that are specified and could be set in the 'Properties' view.
For text nodes 'Properties' view contains four tabs:
- Main tab contains the following text node parameters:
- Id - text node identifier. The identifier is unique
among the children of the one parent. It could be changed manually.
- Name – name of the text node. It shouldn't be unique.
Name is empty by default. Name could be changed manually.
- Type – text node type.
For text node the type can be 'Text' (for plain text),
or 'Header' (for header). This field has a drop-down list and allows to change one text node type to another
('Text' to 'Header' and revert) or change text node to 'Requirement').
- Attributes – text node attributes, are presented in a table.
Read more here.
- Description tab contains the following text node parameters:
- Description –
text of the text node. Can be edited manually.
- Advanced tab contains:
- Predicate – a predicate, defines what text node
will be included in reports. Predicate is inherited from the parent node by default.
Could be changed manually.
- Source tab contains only json-code:
- json – low-level representation of the text node as entity. Couldn't not be edited.
U
UniEditor
- is a view in the 'Requality' perspective, it's a visual editor for requirements, test purposes and comments.
Allows adding, editing and modifying requirements, test purposes and comments, and also allows changing statuses of
the requirements and test purposes. In contrast to the 'Review'
editor it doesn’t allow setting statuses of the requirements and test purposes into the value 'verified'.
Update Processor Tasks
- is a view in the 'Requality' perspective, it is used after transferring locations to new document version.
It allows to check transfer correctness manually. And it allows manual transfer of locations have not been transferred authomaticallty.
This view shows a list of all requirements and status of every requirement transfer:
- 'Verify' – all requirement locations have been transferred, user should only verify the correctness of the transfer.
- 'Add Locations' – requirement locations have been transferred partially, user should find analogues of not-transferred
locations or make sure new document doesn't contain these locations.
- 'Find Locations' – none of requirement fragments has been transferred. User should find analogues of not-transferred
locations or make sure new document doesn't contain these locations or the requirement in a whole.
V
Virtual Node
- is an element of 'Requality' project catalog, it is used for reusing of elements of requirements catalog. Using virtual node allows
you to automatically create a subtree of clone-nodes (see 'Clone') that are similar to already existing subtree of requirements catalog.
To reuse nodes you should select the method of clone-nodes iteration and then select target node to reuse (see 'Virtual node properties'). There are two methods of iteration:
- 'Reuse' — copies of the target node with its subtree are added to the virtual node as children.
- 'Base element' - copies of direct children of the target node with their subtree are added to the virtual node as children.
For 'Reuse' method there is also 'It.vars' setting related to number of clones calculation. The setting allows to use list variables to create several clones of one node with different variable values.
In the project tree virtual node is shown as a node of requirements tree, it's a child of the node for which you want to define a subtree of clone-nodes.
Virtual node could be hidden (not shown) in the project tree. In the hidden mode in the project you can see only children of this
virtual node (clone-nodes) but not itself.
Virtual node properties
- parameters of virtual node, that could be defined in 'Properties' view.
For virtual nodes 'Properties' view contains 4 tabs:
- Main tab contains the following parameters:
- Id – virtual node identifier. The identifier is unique among the children of the one parent.
It could be changed manually.
- Name – name of the virtual node. It shouldn't be unique. Name is empty by default. Name could be changed manually
- Attributes – virtual node attributes, set in the attributes table.
Read more about the attributes table here.
- Iteration tab contains the following parameters:
- Target – is a target element which is processed by the virtual node.
It could be a requirement or a test purpose. 'Target' is one of Requality project nodes. If a parent-requirement of virtual
node has a child test purpose then only test purpose (not requirement) could be the 'Target' in this case.
- Iteration method –
is a way how to use virtual node. Could have two values (specified in a drop-down list):
- Reuse - common description (patter) is used, its copies will be added to the virtual node.
- Base element - base element method, copies of target element's direct children will be added to the virtual node.
- It.vars – iterated variables.
This parameter is shown in the tab only if 'Reuse' method is selected.
No one iterated variable is set by default. There could be several It.vars. It.vars could be added or removed by
corresponding add and remove buttons. It.var could be selected in a drop-down list which contains a list of
available attributes. Only attribute of the virtual node (from the Attributes table) that has type List, could be added as It.var.
- Source tab contains only json-code:
- json – low-level representation of the requirement as entity. Couldn't not be edited.