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

  1. Main tab contains the following requirement parameters of comment:
    Main tab of Properties view for comment

  2. Source tab contains only json-code:
    Source tab of Properties view for comment

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.

  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. id - is user-visible-name(element) or qualifying-id(element) of the covered element:
  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:
  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. 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:



L

List values editor

- is used to set and change values of LIST attribute.

List values editor wizard contains two following elements:


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.


'REFERENCE' type attribute in 'Properties' view

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:


'Requality Links Explorer view, outbound link to linked node

and from linked node indicated in the 'Value' field of the REFERENCE attribute of first node:


'Requality Links Explorer view, inbound link to linking 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:

  1. A file in special format
  2. 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:

  1. A file in special format
  2. 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:

  1. First page contains following diagrams:
  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 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).

Properties view for Report

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:

  1. Report Settings tab contains the following report parameters:
    Properties view for Report Settings
  2. Source tab contains only json-code:


Requality Explorer

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


Requality Explorer view

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:

  1. Main tab contains the following requirement parameters:
    Main tab in Properties view for requirement

  2. Description tab contains the following requirement parameters:


    Description tab in Properties view for requirement

  3. Advanced tab contains the following requirement parameters:
    Advanced tab in Properties view for requirement

  4. Source tab contains only json-code:
    Source tab in Properties view for requirement

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


Review view



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:

  1. Main tab contains the following test purpose parameters:


    Main tab in Properties view for test purpose


  2. Description tab contains the following test purpose parameters:


    Description tab in Properties view for test purpose


  3. Advanced tab contains the following test purpose parameters:


    Advanced tab in Properties view for test purpose


  4. Source tab contains only json-code:


    Source tab in Properties view for test purpose



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


UniEditor view

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:


Update Processor Tasks view


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:

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.


Project tree contains virtual node

Virtual node properties

- сparameters of virtual node, that could be defined in 'Properties' view.

For virtual nodes 'Properties' view contains 4 tabs:

  1. Main tab contains the following parameters:
    Main tab of Properties view for virtual node

  2. Iteration tab contains the following parameters:
  3. Source tab contains only json-code:
    Source tab of Properties view for virtual node