Frequently asked questions about the use

Is the incrementing of the requirements version necessarily manual and decided by the writer?

Yes, the version is managed manually by the editor.

That said:

  • REQCHECKER™ has a function to compare two versions of the repository which allows to list requirements whose content has changed and whose version has remained the same. For example, it allows you to perform a pre-delivery review to identify omissions by the editors.
  • The main reason for the existence of the version is the impact analysis: to identify downstream requirements that need to be reviewed when an upstream requirement has been modified. REQCHECKER™ proposes an automatic version to avoid the developer to perform the increment manually.

How to combine cascading covers with very different syntaxes?

One solution is to split your project into two covers defined by two .cover files, and inject the requirements declarations of the first one into the second one. For example you can set up:

  • a first project highlevel.cover generates a matrix highlevel-coverage.xlsm;
  • a second project lowlevel.cover project takes this matrix highlevel-coverage.xlsm as input file using BDD mode.

Of course, these names are examples and are subject to change.

What does the position "§-" stand for?

The §- position is assigned to texts positioned before the very first chapter, which is expected to be the first level 1 title. If all the text appears in this chapter, you should check that you are using native Microsoft Word styles: Heading 1, Heading 2 etc. or the equivalent in your language.

Is it possible to manage statement IDs centrally (network directory for example) in order to ensure that there are no duplicate IDs when inserting a statement via plugin?

There is no centralized management of IDs to date. REQCHECKER™ is a stateless application based solely on the project file (.cover) and documents. This choice contributes to its ease of use.

In all cases a cover calculation immediately identifies the duplicate. The software is designed to launch checks on a continuous basis.

To limit the risk of ID duplication you can:

  • Use different prefixes per document. The Word plugin ensures the uniqueness of a requirement ID for the current document since the last calculation (Save and Compute button). It calculates the next ID from the rules defined in the document via the plugin (template ID, next ID etc) avoiding those already used (list established at the last calculation). This is the most recommended solution.
  • Store documents on a shared network space, Subversion, OneDrive, Google Drive etc., which allows you to quickly detect if a conflict exists and correct it.

Is it possible to define the formatting associated with the attributes of a statement when inserting via the Add-in for Microsoft Word?

Yes, using Microsoft WORD styles. Add-in for Microsoft Word creates WORD styles to format the text if they are not already present. You can freely modify them in the document to define a custom formatting. These styles are:

  • Reqchecker Coverage
  • Reqchecker Statement ID
  • Reqchecker Statement Markers
  • Reqchecker Statement Tags
  • Reqchecker Statement Text
  • Reqchecker Statement Title

By modifying their characteristics, especially the line spacing, you should be able to achieve your goals.

How to use an automatic numbered style to define the requirement ID?

Using a numbered list to automatically set requirement IDs in an MS Word document is not supported by REQCHECKER™.

There are two possible solutions:

  • either retain this method by saving the document as a PDF, then using the PDF as the source in the project to calculate your coverages.
  • or write the requirement numbers explicitly. The Add-in for Microsoft Word can help you with this, it has a mechanism for incrementing the requirement ID.

Warning

The numbering method by style is not recommended because it does not guarantee the unicity of the identifiers. For example, if you insert a new requirement between EX_2 and EX_3, all next requirements (EX_4, EX_5 etc.) will automatically be renamed, which will break all coverages and references. In addition, if you declare requirements in a second document, you must manually synchronise the list numbers of the second document to avoid conflicts with the first.

How to manage different document requirements that do not have the same format?

If all documents use the Syntax extraction method, for example one declares the requirements in the CDC_SYS_0010 format and the other declares them in the [REF_23] format (with a prefix and a suffix), you can:

Note

By double-clicking on the editing area you can open the small Regular Expression Editor.

Warning

Not using the BEGIN_STAT and END_STAT tags does not allow you to make the difference between a declaration and a simple reference. For example, any text mentioning REF_23 will be considered a statement, even if it is simply inserted in an explanation that does not seek to state or cover it. Nevertheless the coverings remain correctly distinguished, e.g. <>.

If the documents use different declaration principles, for example for one you use the syntax as above, and for another the chapter numbers, you have to declare the second one in Heading mode in the Data sources Tab.

Finally, sometimes it is necessary to correct the REQCHECKER™ extraction by hand. This can happen with PDF specifications to remove footer texts. In this case you have to create an independent project, extract the requirements and correct them in the Coverage Matrix. Once finalized the report itself is used as a source in the main project using the Database mode.