Requality: glossary

A

Active node template (active template)

- 'node template' that has been set as active for this node type. If a template is selected as active, then when creating new nodes of this type, all nodes will be created by this template by default. Initially, an empty template is selected for all project nodes, where all parameters are set by default. ( See 'Templates editor'. ) There can be only one active template for one node type. The active template is marked with bold font in the list of templates in the 'Templates editor' view.

Attributes table (attributes)

– is a set of parameters - attributes - of any 'Requality' project node. These parameters describe 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 automatically 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 automatically, for example, date of report generation.
• Some attributes should have pre-defined names, usually these attributes are generated automatically with the help of wizards (eg attribute 'coverageFilePath' of 'Report Settings' node, that sets a path to coverage information source file).
• For different node types attributes differ.

Attributes are presented in a table with columns: 'Name', 'Type', 'Value', 'Scope' and 'Generator' (attribute values generator).

• Attribute name should be unique for the one node. It can't be empty and can't begin or end with spaces.
• Attribute type is set in 'Type' column. By default available types are: 'INT', 'FLOAT', 'BOOL', 'STRING', 'LIST' and 'REFERENCE'. But if in the project there is global 'ENUM_DEFINITION' attribute it's name with prefix Ⓔ will be shown in the drop-down list in the 'Type' column as available Enum-type (see 'Enumerated attribute type (Enum)').
• Attribute value is set in 'Value' column.
• Attribute scope is set in 'SCOPE' column. It can be one of 3 following values: 'DIRECT_CHILDREN', 'LOCAL', 'SUBTREE'.
  • LOCAL - value applies only to the current element.
  • DIRECT_CHILDREN - value applies only to the direct children nodes of the current element.
  • SUBTREE - value applies to all the children nodes of the current element subtree.
• By the way, attribute with the same name can be redefined in a child-node. In this case new defined value is more actual for this node than inherited one.

  NOTE! Column 'SCOPE' is missing in the attributes table of the project node, by default scope of these attributes is whole the project tree.

• Attribute values generator should be set in 'Generator' column. How it works you can see (here).

Attributes value generator

See '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 an 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. (They can also be viewed and edited in a shortened form in the 'Parameters editing window'.)

For Comment node 'Properties' view contains three tabs:

1. Main tab contains the following 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.
   
   
   
2. History tab contains information about the history of all 'revisions' related to this comment. The contents of the tab are similar to the contents of the 'History' tab for the requirement (see 'Requirement parameters').
   
3. Source tab contains only json-code:
   • json – low-level representation of the comment as an entity. Is not editable.
   
   

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.

File format:

<?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.

1. 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)
2. 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.
3. qid - 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"
4. 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.
5. uri - is attribute of covered_by XML-element, it specifies a path to the test described in this covered_by element. For example:"file:///home/user/work/test1.c#12"
6. hits - attribute of covered_by XML-element, it is optional. Indicates how many times this reqcoverage requirement is linked to in covered_by test.
7. 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.
8. testuri - path to test described in covered_by element
9. 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.
10. uri - optional parameter, path to file with more information about the error.
11. 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.
12. qid - is user-visible-name(element) or qualifying-id(element) of covered element(for more details see description of reqcoverage element above).
13. description - optional element, text description of the error. Has optional format attribute.
14. format - format of error description. Can be "html" or "plain". In case of "plain" all html tags will be shown as plain text.
15. 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. Formed based on a requirements document imported into the 'Requality project'. The user selects text fragments in the document and assigns them to requirements.

E

Enumerated attribute type (Enum)

– is attribute type, defines a list of available attribute 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).
  1. 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:
     
     
     
     
  2. '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 Ⓔ).

F

ForeignID

– is an unique numeric identifier of a node in the requirements tree, which is specified in the 'ForeignID' attribute. The user ensures its presence independently. ForeingID is also used as predefined attribute name for SeqID.

FullName

– path to the node identifying the node. Contains a listing of all parent nodes in order, starting from the root node 'Requirements' and ending with the node under consideration. In this listing, nodes are specified by their names, or by identifiers if there is no name defined. The separator is '/'.

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 editable fields 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 appears.
    • 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 editable fields 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

- editor of the values ​​of the attribute of the 'LIST' type. If the 'Properties' window of a node contains an attribute of the 'LIST' type, then the 'List Value Editor' is used to set and edit its values.

The editor opens in a special window, which contains the following two 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

Mandatory attributes

- these are attributes that are automatically specified for existing and newly created elements of the requirements tree in accordance with the 'Requality project' settings. Mandatory attributes may vary for different types of nodes. All 'system attributes' are mandatory. 'User attributes' may become mandatory in accordance with the settings .

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

Nameorid

– a parameter used to define the identifier or name of some node of the requirements tree. If the node has a name, then 'nameorid' is the name of the node, otherwise 'nameorid' is its identifier. Can be used, for example, as a parameter in requirements descriptions. In this case, it should be written with an underscore at the beginning: '_nameorid'.

Node properites

– these are node properties, a set of attributes that characterize the node. The full list of node parameters can be viewed and edited in the 'Properties' view window of the Requality perspective. A shortened list of parameters is in a special 'parameter editing window', which opens when creating and editing nodes in the 'Module Editor', 'UniEditor' and 'Review' editors. Some attributes may be 'mandatory', they are configured in the Requality project settings. The attributes that are specified in the attribute table are user-defined, since their presence is determined by the user, unlike all other system attributes.

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 works 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 (can also be viewed and edited in abbreviated form in the 'parameter editing window').

O

Outline

- a view in the 'Requality' perspective that displays the list of the document locations.

P

Project revision, Project version

- the state of the project and all its nodes, saved in the repository.

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 name of this attribute is the name of the link.

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:

Reference, reference between the nodes of requirement tree

- is a unidirectional named relationship between two nodes in the Requality project requirements tree. The link originates from the referencing node and enters the target node. It is set in the target node's attribute table as an attribute of type 'REFERENCE' and is displayed for both nodes (referring and target) in the 'Requality Links Explorer' window (for the referencing node as an outgoing link, for the target node as an incoming link). The name of this attribute is the name of the outgoing link in the referencing node and, unless otherwise specified in the project properties, is the name of the incoming link in the target node. When a new link is created, the name of the incoming link in the target node is the same as the name of the corresponding outgoing link in the referencing node. However, the Requality project has several predefined link names that have different incoming and outgoing link names.

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, which specifies the requirement that is being reffered to (referred requirement).

Report

– an entity representing a ready-made generated report. The report is generated based on the settings specified in the 'Report settings' node (see 'Report settings') and cannot be generated again. It has a read-only set of parameters that allow you to find out by what settings this report was generated. You can only change the report name. By default, the report name contains information about the date and time of generation.

A report can consist of several reports if it is generated for several linked projects at once. In this case, at the top of the report there will be a line with a list of links for these projects. When you click on such a link, the report for the corresponding project will be opened in the same window.

Each report at the beginning contains a summary table with brief information about itself. It includes such data as the date and time of generation, the version of the tool at the time of report generation, the name of the initiator of the generation (as specified in the operating system settings), and a reference to the repository if the project is under version control.

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. The main parameter for generating a report is 'Report Template'. Several reports could be generated based on a single Report Settings node. Changing Report Settings does not affect the reports that have been already generated.

Report Settings properties

- are 'Report' Settings properties that are specified and could be set in the 'Properties' view. (They can also be viewed and edited in a shortened form in the 'Parameters editing window ').

For Report Settings node 'Properties' view contains three tabs:

1. 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 the report will be generated. Only this node and all its children nodes (requirements and comments) will be considered in this report . In case of additional plug-ins for Requality, nodes of other types could be included in the report. Could be changed manually.

   • Template – report template, according to which the appearance and content of the report are modified. The report template is changed manually: selected from the list of available report templates. It is a 'system attribute'. The following report templates are available by default:

     • Reports for solving typical problems
       • 'Requirements View'('Чтение требований') - to show all requirements and text nodes as a table.
       • 'Checking Design Rules' ('Проверка правил оформления') is a report containing information about violations of the requirements design rules, including those described in the ' Checker rules ' settings.
       • 'Requirements Coverage Analysis'('Анализ покрытия требований') contains information about the coverage of requirements and test situations by other elements (for example, tests). To generate, you need to specify the source of coverage information. You can read more about the 'Requirements Coverage Analysis' report here.

       
       

     • Export
       • 'Export project to XML'('Экспорт проекта в XML') - exports the Requality project as an XML document, intended for using the report with other tools.

       
       

     EXPERIMENTAL

     • Requirements markup
       • 'Requirements Extraction Analysis' ('Анализ выделения требований', experimental functionality) (экспериментальная функциональность) - this report downloads all available documents and their markup, designed to analyze the requirements markup in imported documents.
       • 'Document model \ Requirements markup coverage analysis' ('Анализ покрытия выделенных требований', experimental functionality) is similar to the 'Requirements Coverage Analysis' template, but provides coverage information about document fragments.

       
       

     • Traceability
       • 'Custom visualization of relationships between requirements' ('Настраиваемая визуализация связей между требованиями', experimental functionality) - a report with links between related nodes of the Requality project. Designed to view links according to the specified settings.
       • 'Bi-directional Relationship Visualization' ('Двунаправленная визуализация связей', experimental functionality) - This report is designed to show relationships in both directions (outgoing and incoming) simultaneously.

       
       

     • Design rules development
       • 'Debug Design Rules ('Отладка правил оформления', experimental functionality) - this report is designed to debug requirements design rules, it allows you to examine nodes where the rules written for the project produce a result other than 'true' or 'false', that is, they may be written incorrectly.

       
       

     • Rest
       • 'Export to LORequality' ('Экспорт в LORequality', experimental functionality) - this report is intended for exchanging requirements with LibreOffice .
       • 'Progress' / 'Project progress' ('Прогресс по проекту', experimental functionality)- this report is designed to analyze the change in the number of requirements and test cases based on the commit history, allows you to view statistics on the number of requirements and test cases in different revisions, uploaded to the repository for this project.

       
       

   • 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.

   
   

   

   
   

2. History tab contains information about the history of all 'revisions' related to this Report Settings node. The contents of the tab are similar to the contents of the 'History' tab for a requirement (see 'Requirement Settings').
3. Source tab contains only json-code:
   • json – low-level representation of the report as an entity. Is read-only.

Report by 'Progress' template ('Прогресс по проекту')

- presents project statistics from different Git revisions.

The report consists of two pages:

1. 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.
2. 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 data from.

Report by template 'Document model' ('Анализ покрытия выделенных требований')

-a report on coverage about coverage of 'locations' in document by other elements (for example, tests), specified using an additional source of coverage information. There can be two such sources:

1. File with coverage information written in a specific format
2. Automatic search for files containing identifiers of requirements or test situations covered by them. When using this source, a search is performed on projects selected by the user in the workspace to find files with the specified extension. The extension is specified by the user. For the specified files, the file contents are checked line by line for compliance with the regular expression described by the user. As a result of such search, the tool receives a set of covered elements and information about the covering files.

Report by template 'Requirements Coverage Analysis' ('Анализ покрытия требований')

-a report on coverage of requirements and test purposes by other elements (for example, tests), specified using an additional source of coverage information. There can be two such sources:

1. File with coverage information written in a specific format
2. Automatic search for files containing identifiers of requirements or test situations covered by them. When using this source, a search is performed on projects selected by the user in the workspace to find files with the specified extension. The extension is specified by the user. For the specified files, the file contents are checked line by line for compliance with the regular expression described by the user. As a result of such search, the tool receives a set of covered elements and information about the covering files.

Report by the template 'Custom visualization of relationships between requirements' ('Настраиваемая визуализация связей между требованиями', experimental functionality)

-a report with links between related nodes of the Requality project directory.

The report consists of two pages. The first contains information about direct links, the second about inverse links. By default, the first page opens; to go to the second, click on the link with the name of the inverse relationship (set in the project properties). To go back to the first page, click on the name of the relationship.

Report on the 'Checking Design Rules' template (Отчет по шаблону 'Проверка правил оформления')

-a report in the form of a table containing a list of nodes in which the 'Checker rules' rules are violated, and information about which rules are violated in each such node.

Report parameters

- are 'Report' parameters that are specified (mostly during 'Report Settings' generation) and accessible in the 'Properties' view.

Report parameters are identical to 'Report Settings parameters' (except for the 'date' attribute), but are read-only (except for the 'Id' parameter).

• The Id parameter in this case is the report identifier, located on the 'Report Settings' tab of the 'Properties' window. By default, it includes the identifier of the 'Report Settings', on the basis of which this report was generated, and the date and time of generation. However, it can be manually edited by the user.
• The attribute table contains the date attribute, which is automatically created when the report is generated and contains information about the date and time of report generation.

Report template

– this is the main setting that determines the contents and appearance of the report. It is specified in the 'Report settings' node. For example, the data can be presented as a list or a table. You can include all nodes of the 'Requirements' tree in the report or only nodes of a certain type. Requality has a set of built-in report templates that are available by default. If you use plugins for Requality, the list of available templates can be expanded. You can also add and delete your own report templates. The report template itself is described in a separate file in the file system.

Requality Explorer

- is a view in the 'Requality' perspective, that displays all content of the 'Requality project' (documents, requirements, reports, comments).

Requality Links Explorer

– is a view in the Requality perspective, which displays the project catalog nodes of the Requality project linked to the selected node by the 'reference link' specified in the 'REFERENCE' type attribute. In this window you can view both outgoing and incoming references together and separately, sort their display by name, and enable highlighting of linked nodes in the 'Requality Explorer' view.

Requality project

- is an Eclipse project created using Requality plug-in. It contains documents, requirements, reports and other entities.

Requality project properties

– properties of the Requality project, set as parameters of the root node of the project. Set in the 'Properties' window.

For a project, the 'Properties' window contains 3 tabs:

1. Tab 'Main'
   • 'Extract enum definitions from attributes' button opens a dialog box for extracting an enumeration type from existing project attributes. See 'Enumerated attribute type (Enum)' for details.
   • 'Attributes'- project attributes, presented in a table. The attribute table (see 'Attributes table') of a project is similar to the attribute tables of other project nodes, except that the 'Scope' column is missing. All project attributes are considered global by default, that is, they are inherited by the entire project tree. In the project attribute table, attributes of the 'ENUM_DEFINITION' type can be specified, which are used to specify an enumerated type for use in other project attributes. For more information about the enumerated type, see Enumerated Attribute Type (Enum).

   
   

   

   
   

2. The History tab contains information about the history of all revisions in the project. This tab contains the change history table - this is a table containing information about all revisions of the project requirements tree elements that were saved to the repository using the 'Repository' menu. Each save of changes to the repository corresponds to one row:
   • the first cell contains the text of the comment for this change,
   • the second cell contains system revision name (for a regular user this information is not important),
   • in the third cell - the name of the user who uploaded the version to the repository,
   • in the fourth - the date when the version was uploaded to the repository.
   Double-clicking on a particular version line opens a perspective for comparing the state of the project at that time with its current local state.

   
   

   

   
   

3. 'Templates' tab- the contents of this tab are completely identical to those of the 'Templates Editor' view and have the same functionality. See Templates Editor for details.

   
   

   

   
   

Requirement

– is an entity that contains a description of some requirement, and links to those parts of the document that reference to this requirement.

• A requirement can have 'sub-requirements (child requirements)'.
• 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. (They can also be viewed and edited in a shortened form in the 'Parameters editing window').

For requirements 'Properties' view contains five tabs:

1. 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 – node 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'.
   
   
   
   
2. 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.

   
   
   
   

3. History tab contains information about the history of all revisions related to this requirement. The user cannot edit anything on this tab directly, only when saving the next version to the repository. The tab contains the following information:

• The version history table is a table containing information about all versions of a given requirement. Each version has one row, which contains the text of the comment for this version, the system version number, the name of the user who uploaded the version to the repository, and the date it was uploaded to the repository. The top row corresponds to the latest version synchronized with the repository. Then, from top to bottom, the versions are listed in descending order, from newest to oldest. Double-clicking on the row of a specific version opens a comparison window, which displays information about the differences between this version of the requirement in question and its current local version. The local version currently in the workspace is marked in green. This is especially important to see if the project has been switched to an old version.







4. 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.
   
   
   
   
5. 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

SeqID

– is a unique identifier of the requirements tree node within the project. It is an attribute of the requirements tree node (requirement, text node, comment, etc.) and is a number. In some cases, this number may have a user-defined prefix, but it does not exist by default. The name of the attribute is specified in 'SeqID' project parameter by the user, by default it is 'ForeignID'. The uniqueness of the identifier lies in the fact that only one requirements tree node in the project can have such an identifier throughout its entire life cycle, and even if this node is deleted, no other node will receive the same identifier while the mechanism is enabled. In order for the mechanism for supporting auto-generated identifiers in the Requality project to work and their uniqueness to be tracked, it must be enabled in the project settings (by default, the mechanism is not enabled when creating a new project). Otherwise, such attributes are considered as regular attributes of the node, and the uniqueness of their values ​​is not guaranteed. When the auto-generation of identifiers is enabled, all nodes of requirements tree that were already in the project receive an attribute with the specified name and a unique value. If some nodes already had an attribute with this name, it is considered as 'SeqID', and its value will be reserved for this node. All new nodes will receive this attribute with an automatically assigned value. After disabling the mechanism of auto-generated identifiers, all attributes (regardless of the source, including manual one assigned before the activation) will be deleted.

Sub-requirement, or child requirement

- is a child node for some other requirement in the project hierarchy. If a parent requirement R contains N subrequirements RC _1, ..., RC _ N, then the requirements RC _1, ..., RC _ N are said to represent a decomposition of requirement R. In other words, the target system satisfies requirement R if and only if it satisfies all requirements RC _1, ..., RC _ N.

System attributes

- these are parameters of the Requality project node that exist for nodes by default, the user cannot create them, delete or change their data type, but, as a rule, the value can be edited. Sometimes the value cannot be edited either, for example, some system attributes of a report cannot be edited, because they contain information about the initial settings on which this report was generated. System attributes can be edited in 'Node Properties' (see 'Requirement Properties' as an example). It is necessary to distinguish between 'system attributes' and 'user attributes', and also keep in mind that there are 'mandatory attributes'.

T

Templates editor

- is an editor for node templates (see '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.

Term, term relation

– is a concept in Requality that denotes the presence of a special one-to-many directed relationship 'Term - Term referrers' between several nodes, where one of these nodes is considered to be the place where the term is defined, and all the others are places where it is used. This relationship is specified not by an attribute of type 'Reference', but by special attributes named 'def-term' (in the node where the term is defined) and 'usedef' (in the nodes where the term is used). The name of a term aim to be unique within a project.

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

- test purpose parameters that are specified and could be set in the 'Properties' view. (They can also be viewed and edited in a shortened form in the 'parameter editing window').

For test purposes 'Properties' view contains five tabs:

1. 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.

   
   

   

   
   

2. 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.

   
   

   

   
   

3. History tab contains information about the history of all revisions related to this test purpose. The contents of the tab are similar to the contents of the 'History' tab for the requirement (see 'Requirement Properties').

   
   

4. Advanced tab contains:
   • Predicate – a predicate, defines what test purposes will be included in reports. Predicate is inherited from the parent requirements by default. Could be changed manually.

   
   

   

   
   

5. 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 are 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. (They can also be viewed and edited in a shortened form in the 'parameter editing window').

For text nodes 'Properties' view contains five tabs:

1. 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.
   
   
   
   
2. Description tab contains the following text node parameters:
   • Description – text of the text node. Can be edited manually.

   
   
   
   

3. History tab contains information about the history of all revisions related to this text node. The contents of the tab are similar to the contents of the 'History' tab for the requirement (see 'Requirement Properties').

   
   

4. 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.
   
   
   
   
5. 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 to set 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 automaticallty. This view shows a list of all the 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.

User-defined attributes

- are node parameters defined by user (unlike a system attributes): an user can create they, remove, define the type and value. User-defined attributes are set in attributes table (see attributes table). It is better to distinguish a user-defined attributes from system (see system attributes) one and also take into account that an user-defined attribute may also become a mandatory.

UserVisibleId, UVId

- special designation of a node for its identification.

• If the node in question has no name, then 'UVId' is defined as 'UVId of the parent node'/'node ID'.
• If there is a name and an 'ignoreName' attribute is defined (see Attributes table) with value 'true', then 'UVId' is defined as 'UVId of parent node'/'node name'.
• If the name is present and the 'ignoreName' attribute is missing or has the value 'false', then 'UVId' is defined as the 'node name'.

UUId

- a unique and unchangeable intra-system (within Requality) identifier of any node of the Requality project. It is a 128-bit number. When the identifier 'Id' of a node changes, its 'UUId' does not change, although it should be noted that Requality understands such an operation as deleting an old node (with the old identifier 'Id') and creating a new one (with a new identifier 'Id').

V

Virtual Node

- is an element of 'Requality' project catalog, it is used for reusing of the 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. (They can also be viewed and edited in a shortened form in the 'parameter editing window').

For virtual nodes 'Properties' view contains 4 tabs:

1. 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.
   
   
   
   
2. 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, but this parameter isn't specified by default. '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.
   
   
3. History tab contains information about the history of all 'revisions' related to this virtual node. The contents of the tab are similar to the contents of the 'History' tab for the requirement (see 'Requirement parameters').
   
4. Source tab contains only json-code:
   • json – low-level representation of the requirement as entity. Couldn't not be edited.