Requality: glossary
C
Comment
- is an entity that contains some text comment and refers to the requirement or test purpose.
One requirement/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.
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.
- Scope - the scope of the generated parameter, could be one of 3 following values:
'DIRECT_CHILDREN', 'LOCAL', 'SUBTREE'.
- DIRECT_CHILDREN - value applies only to the direct children nodes of the current element.
- LOCAL - value applies only to the current element.
- SUBTREE - value applies to all the children nodes of the current element subtree.
By default 'DIRECT_CHILDREN'value is set. User can select one of these three values in a drop-down list.
- 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.
O
Outline
- a view in the 'Requality' perspective that displays the list of the document locations.
P
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,
similar to the attributes of requirements. The attribute table could be changed manually. Information about the source of coverage data could be added
to the table as attribute coverageFilePath. There is a button Update Coverage Source to set this attribute value or change it in the table. The button
Update Coverage Source Include is shown in the view only if coverage source is required.
- 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.
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.
- Attributes – the attributes of the requirement. Attributes
have name, type and value. Could be changed manually or generate automatically by Attributes value generator.
User sets parameters of the generator. Generator has a parameter to define the way of attributes inheritance, so attributes could be inherited by children-nodes from parent-node.
Attributes are inherited from the parent requirements by default, but they can be overridden.
Attributes are used in predicates and generators.
- 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 is completed by hand.
- Locations - the list of locations of the requirement,
grouped by documents. Manually you can only delete locations.
- Advanced tab contains the following requirement parameters:
- Predicate – a predicate, defines what requirements
will be included in reports. Predicate is inherited from the parent requirements by default.
Could be changed manually.
- Base requirements – basic requirements.
These are requirements that inherit and extend considering requirement. Could be changed manually.
- Source tab contains only json-code:
- json – low-level representation of the requirement as entity. Couldn't not be edited.
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
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.
- Status - test purpose status. It could be: 'in
process', 'complete' or 'verified'.
Could be changed manually.
- Author - an author of the test purpose, similar to the attributes of requirements. Could be changed manually.
- Attributes – the attributes of the test purpose. Attributes have name, type and value.
Could be changed manually or generate automatically by Attributes value generator.
User sets parameters of the generator. Generator has a parameter to define the way of attributes inheritance,
so attributes could be inherited by children-nodes from parent-node.
Attributes are inherited from the parent requirements by default, but they can be overridden.
Attributes are used in predicates and generators.
- 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 the following test purpose parameters:
- 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.
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 (VN)
- is an element of 'Requality' project catalog, it is used for reusing of elements of requirements catalog.
To reuse you should select the way of reusing and select target element to reuse. Now there are two methods of reuse:
- 'Reuse' — to use common description (pattern), copies of which will be added to the virtual node.
- 'Base element' - to define base element in which copies of the direct target element children will be added to the virtual node
For common description it is also available to define number of copies. In the project tree virtual node is shown as
one of children of those element for which you want to define reused elements as children.
Virtual node could be hidden in the project tree. In hidden mode in the project you can see only children of this
virtual node (that is reused elements) 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 – VN identifier. The identifier is unique among the children of the one parent.
It could be changed manually.
- Name – name of the VN. It shouldn't be unique. Name is empty by default. Name could be changed manually
- Attributes – the attributes of the VN. Attributes have name, type and value.
Could be changed manually or generate automatically by Attributes value generator.
User sets parameters of the generator. Generator has a parameter to define the way of attributes inheritance,
so attributes could be inherited by children-nodes from parent-node.
Attributes are inherited from the parent requirements by default, but they can be overridden.
Attributes are used in predicates and generators.
- 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 VN (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.