News

Reqchecker 1.8 is ready

Posted on by Reqchecker Admin

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

Reqchecker 1.7 is ready

Posted on by Reqchecker Admin

Automatic impact analysis

The software automatically creates a default version for each requirement. This version is available only if no explicit version is defined. The automatic version is a 6 characters length hash number. The hash is computed from the text and picture read from PDF and MS Word docx documents. The automatic version is not dependant from the following changes: case sensitive change, bullet modification, spaces.

Dynamic folders

The “Add Folder” button in “Data sources” tab now inserts either the files in batch mode, or lists the files at runtime. This works for folder and sub-folders. The advanced patterns allows filters like *.{cpp,h}.

Path update

The path of a file or a folder can be updated without changing other characteristics.

Regular expression conversion

When user switches from standard to advanced regular expression, the existing values are converted. Switch back to standard expression is not possible, then values are reset to default.

Java enum export

New export under Java enum format. This allows to reference requirements directly from Java language, for example as link in JavaDoc source code. (PRO version only)

Read comments for new languages

Read comments for new languages: Python (.py, .pyw), Windows and Linux script files (.bat, .sh), C include files (.inc). (PRO version only)

Bug fixed

Increased maximum length of requirement text. This allows to catch longer text, in particular for heading mode where paragraphs can be long.

(PRO version only) Fixed PDF reader: some cases of landscape page are now correctly read

(PRO version only) Fixed false differences presented in verification report in update mode when the text contains some unprintable characters

(PRO version only) Fixed verification report no more includes deleted requirements.

How to build the coverage matrix between your bid and an RFP with no formalized requirement

Posted on by Reqchecker Admin

RFP Request for Proposal

This tutorial solves a common problem for people who regularly write bids. The RFP – request for proposal – contains several requirements.

Introduction

A coverage matrix between your bid and the RFP helps your customer to:

  1. Check that the RFP he has carefully written has been fully read and covered
  2. Find exactly where a requirement is taken into account in your bid
  3. Check where your bid does not fully fit a requirement
  4. Navigate between his RFP structure and your bid structure

It is therefore good practice to send such matrices. Unfortunately most RFPs have no formalized requirements. The only way to identify a sub-part of the RFP is to use the chapter numbers. In this case, you have to create a table in your bid presenting where and how each RFP chapter has been covered.

For example:

RFP § BID § COMMENT
§1 Introduction §1.2 Context
§1.1 Overview §1.2 Context
… …
§2.4.2 Graphical User interface §2.2.3 Rich client application Windows platforms only are supported

With an RFP in MS Word with few chapters (less than 20 for example), this can be done manually by :

  • copying the table of contents in the first column
  • completing it with lower chapter levels that are not listed in the table of contents
  • manually completing the BID and COMMENT columns

However, with an RFP in PDF format where text cannot be easily copied, or with a huge RFP with hundreds of chapters, or whenever your boss asks you to update your bid chapter structure just before the end of RFP countdown time, this matrix becomes a dreadful nightmare…  🙁

Have you never dreamed of a simple method for automatically building and updating this matrix?

Reqchecker makes this possible.

Step 1 – Create a Reqchecker project

The first first step consists in creating a project and including the files: RFP and proposal.

Let’s take an RFP with the following chapter structure:

1.0 Company
2.0 Purpose
3.0 Objectives
4.0 Target Audiences
5.0 Criteria for Evaluating the Success of a PR Agency
6.0 Query Handling
7.0 Accuracy
8.0 Rights Reserved
9.0 Award of Contract
10.0 Confidentiality

First of all you must create the project file. To make things easier all documents can be stored in the same folder, for example called ‘matrix’. Right click on the RFP, then click on “Add to coverage” menu to create an empty project.

Double click on the .cover file to update the project settings:

  • Select the RFP in the file list.
  • Select ‘Heading’ in the ‘Data Source Information’ section.
  • Click on the ‘Edit’ button and force the file code to ‘RFP’.
  • Click on the ‘Add File’ button.
  • Select the bid file in the file browser. In this example the name is ‘My BID.docx’.
  • Select the BID file from the file list.
  • Select ‘None’ in the ‘Data Source Information’ section to skip the heading of the bid itself.
  • Click on the ‘File’ menu, then ‘Save’ to save your modifications.

Step 2 – Insert tags in your proposal

Insert a coverage tag wherever your proposal answers a chapter, or part of a chapter, of the RFP.

For example, the RFP text contains:

12.0 Project Duration
12.1 The project will commence on 1 February 2015, and will be completed by 31 July 2015.
12.2 Dates of commencement and completion of the project shall be stated in the contract.

Let’s imagine that the associated chapter in the proposal is:

1 Overview
2 Technical proposal
3 Administrative proposal
3.1 Schedule
The project duration is 6 months. The project starts 2 weeks after order.
The estimated schedule is:
- 15th January: order
- 1st February: project kick-off 
- 31th July: final delivery
<<RFP§12.0>> <<RFP§12.1>> <<RFP§12.2>>

The <<RFP§12.0>> text  is the tag indicating that this chapter fully covers the requirements of RFP chapter §12.0.

To keep the proposal legible, tags are usually written in grey in a small font. Good practice recommends using a Word style. In this way you can, if required, hide tags by selecting font size 1 and white.

Tag syntax is defined in the Reqchecker ‘Coverage’ tab and can be modified:

Coverage tags can embed more information. For example:

  • <<RFP§12.0>> #Partial means that not all requirements are covered here.
  • <<RFP§12.0>> #Uncovered means that requirements are not covered in the proposal. The final coverage rate will be reduced.
  • <<RFP§12.0>> #NA means that requirements are not applicable to the scope of the bid. They will be ignored and the the final coverage rate will not be reduced.
  • <<RFP§12.0>> #Uncovered 25% means that only 25% of requirements are not covered. This allows a fine tuning that presents the highest rate possible to the customer.
  • <<RFP§12.0>> #C this is a comment will register a comment in the coverage matrix. This is a custom coverage tag. It is possible to create several tags to manage coverage.

All of these can be combined. For example : <<RFP§12.0>> #Partial 50% <<RFP§12.0>> #NA 25% <<RFP§12.0>> #Uncovered 25% #C This will be covered by a another proposal. means that 50% of this chapter is covered, 25% is uncovered and 25% is inapplicable to the bid.

Step 3 – Generate the coverage matrix

Click on the ‘Report / Coverage Matrix’ menu to build the EXCEL matrix.

The first tab presents the coverage rate in a pie chart. Select the second tab ‘Matrix’ tab. Remove or hide unwanted columns and filter on the §12.0. The resulting display will be something like:

You can either copy the matrix into your proposal, or click on the ‘Report / Coverage Full Report’ menu to attach the detailed PDF version.

Step 4 – Update the coverage matrix

Here you can replace the RFP with an updated matrix, or update your proposal. Even if you move chapters of your proposal or text around, or if you make any other kind of modification, just re-compute the report to get an updated matrix within a few seconds.