Reqchecker 1.8 is ready

SUMMARY

Several improvements increase software ability to extract requirements from PDF and WORD documents. The new check feature runs several checks on requirement titles and text to increase consistency and ease of reading. French, German, and English are the languages supported. The new “Syntax+Full” extraction mode considers any part of the document as a requirement.

NEW EXTRACTION FEATURES

@ New custom tag types (PRO Version only)
Requirement custom tags (or attributes) can use the following new types:
• “Multiline Text“ extracts a requirement tag on several lines. The text is read until the next “known thing”: next keyword, next chapter or next requirement.
• “Cell Text“ extracts the tag keyword from a table cell and the tag value from the next cell. Reader plugins must support table recognition (for example *.pdf, *.docx).

@ Readers improvements
The MS Word .docx and .doc reader plugin recognizes the bullet style (one level only).
The MS Word .docx reader plugin recognizes table cells (one level only).
The PDF reader plugin detects and ignores watermarks. Paragraph recognition is improved. (PRO version only).

@  Parser improvements
⦁ Accepts the dash character “-“as part of a requirement version.
⦁ Forces the first character of a requirement version to be a digit or an exception. This improves version parsing when there is no termination tag (END VERSION). The exceptions are “v”, “V” and “DELETED” for compatibility with some projects.
⦁ Allows file ID to be 8 characters long when it is modified manually

@  Requirement filtering by title (PRO Version only)
This set of filters ignores (removes) requirements whose title matches one of the filters in the list. The filter value is case-sensitive. The filter value can use ‘*’ (one or more characters) or ‘?’ (any character) wildcards to filter a position containing text. Default values for a new project ignore requirements containing dotted lines in a table of contents; this avoids the several statements error when the table of content refers to some requirement statements.

@  Text filtering by style name (PRO Version only)
This set of filters ignores (removes) the text of the document whose style name matches one of the filters in the list. The filter value is case-sensitive. The filter value can use ‘*’ (one or more characters) or ‘?’ (any character) wildcards to filter a position. Default values for a new project ignore the table of content styles; this avoids the several statements error when the table of content refers to some requirement statements.

@   Compatibility with REQTIFY improvement
⦁ The new “title for requirement” parsing option. When disabled, no title is read from requirement.
⦁ The statement version tag and the coverage version tag can use the same keyword.
⦁ The BEGIN COVER statement prefix (see Coverage GUI tab) can be written in the line or cell immediately preceding the requirement ID.
⦁ Comparison of requirement versions is not case-sensitive.

@  New “Syntax+Full” extraction mode in Data Source tab
This new extraction mode considers any part of the document as a requirement. It extracts requirements using syntax and all other paragraphs extracted too. This mode provides a way to extract text for checking and traceability.

@  New “Limit text to first section” option
If enabled and if END_TEXT is defined, the extracted requirement text stops at the next section (next chapter or next sheet) or the next tag.

VALIDATION NEW FEATURES

@ Check engine
The check engine runs several checks on requirement titles and text to increase consistency and ease of reading. French, German, and English are the languages supported. The language used by checks is selected dynamically to match the main language of the analysed document.
Combined with the Syntax+Full parsing option, a full document, including requirements (if any) and other paragraphs, can be reviewed.
If a static or dynamic folder is used in the Data Sources tab, the check engine checks a batch of documents.
All errors are listed in the verification report and the PDF report. The requirements that are not compliant with rules have the VALIDATION_ERROR status.
Each check component can be fully enabled / disabled.

@ Blacklist check component
Blacklist check component finds all ambiguous (“most”, “often”, “at … level”) or forbidden (“ASAP”, “TBC”, “TBD” etc.) terms and expressions. Detection may or may not be case-sensitive. Wildcards can be used to specify the forbidden expression, or advanced regular expression.
Rules are executed in the declaration order. When part of the text does not comply with a rule, it will not be used for the next rules.
Several predefined lists of expressions are available for French, German, and English. Rules can be customized or extended to another language (PRO Version only).

@ Metrics check component
Metrics check component checks several metrics that make text hard to read or ambiguous:
⦁ Maximum Negation Count: checks the maximum number of negations included in a sentence. Sentences with too many negations are hard to read.
⦁ Maximum Sentence Length: checks the maximum number of words included in a sentence. Sentences which are too long are hard to understand.
⦁ Maximum Number of Conjunctions and Adverbs: too many coordination conjunctions (“and”, “or”, “for”, same for French and German, etc.), subordinate conjunctions (“after”, “though”, “unless”, same for French and German, etc.), link adverbs (“furthermore”, “unlike”, “besides”, same for French and German, etc.) and logical relation adverbs (“because”, “since”, “in order that”, same for French and German, etc.).

@ Deletion management for verification report (PRO Version only)
The report separates the DELETED status, and requirement deletion from documents. Requirements with DELETED status appear in the verification report with the “! DELETED!” prefix displayed in the title and in the text. Requirements removed from documents appear with a strike-through the text and the “(deleted)” value in the Result column.

NEW TRACEABILITY FEATURES

@ The new “Incomplete management” status instead of “Ambiguous coverage” is used whenever the management rate is below 100%.