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.

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:

• insert the documents in Syntax mode in the Data sources Tab;
• activate the option Syntax Advanced Reg. Exp. option;
• enter a syntax in the form of a regular expression with an "or".

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.

How can you ignore requirements depending on the project that uses them?

Certain requirements do not apply to my project towards my customer. At the same time, these requirements are applicable to my customer's project toward his own customer (the end customer). How can I avoid having to cover them in my project, while keeping them for my customer's project?

The "non-applicability" of a requirement varies according to whether it is considered by the supplier's project or by the direct customer's project: some requirements are not applicable to the direct customer, but are applicable to the end customer. Information on non-applicability cannot therefore be included in requirement declarations, which are shared by all stakeholders. The information must be carried by the covers.

To ignore requirements within a project, the N/A system tag (#NA) should be used in covers. Non-applicable requirements are listed and covered with a N/A tag and saved in a dedicated file (e.g. not_applicable.txt). In this way, the software will no longer raise an error if they are not covered by downstream documents. The N/A tag can be combined with other coverage tags if required, such as the comment (#C) tag or a custom tag.

not_applicable.txt

<<REQ_1234>> #NA #C This requirement is not applicable to the supplier. <<REQ_1235>> #NA #C etc..

The above use case involves creating two files:

• not_applicables_supplier.txt which is imported into the supplier's REQCHECKER™ project, which calculates the coverages towards the direct customer.
• not_applicables_customer.txt which is imported into the direct customer's REQCHECKER™ project and calculates coverage towards the end customer.

Is it possible to use Microsoft Word styles to create a statement and a cover?

For example, the same requirement is considered a statement if it's in style n°1 and a cover if it's in style n°2.

This feature is not currently supported by REQCHECKER™.

With REQCHECKER™, you must set at least one category of markers:

• set declaration markers to empty and insert cover markers (<< >> or equivalent). This is the most common solution.
• set blank cover markers and insert declaration markers (< > or equivalent).

You also have the option of using a dedicated style for these markers, enabling them to be hidden (in the Microsoft Word style settings) at the time of PDF printing. As an example Add-in for Microsoft Word offers a discreet style: blue, italic, small size.

I don't understand what the DELETED tag is for?

When the same requirements repository evolves, requirements may be modified (which can be traced by an explicit version or with automatic prints), new or deleted. In the latter case, it may be necessary to keep the deleted requirement in the repository, for example in order to trace the logical deletion (the requirement no longer needs to be considered but remains present in the documents) and to distinguish it from a physical deletion (disappearance from the documents, which could be due to human error). With DELETED, you can trace this deletion and keep the requirement while ignoring it in the coverages.

I don't understand why the COVERED BY column in the Matrix tab isn't filled in?

In the Coverage Matrix, the COVERED BY column shows the requirement (or, in a broader sense, the item such as test case, user story, etc.) which contains a coverage of the requirement shown on the line. Coverages are always positioned as close as possible to the text, and several coverages can be included in the same item. For example, a test scenario may include several steps in its text, each of which may cover different requirements. The association of the coverage with the item that contains it implies positioning the coverages before the END TEXT tag, or before any other tag that delimits the end of the text.