Data sources Tab

This tab defines the list of analyzed files.

Overview

It is unnecessary to define which document creates a requirement (statement) or which document covers a requirement (coverage). The same document can contain both statements and coverages.

Commands

File list

• File list list: Double click on a file opens it with the default editor.
• Add File button : adds a new file to the list. The supported formats are described in Input formats page.
• Add Folder button : adds all file of the folder that matches the name pattern. The pattern can use: ? for a single character, * character matches zero or more characters of a name component without crossing directory boundaries, { , , } lists several sequences, [-] matches a character range, \ escapes a special character. For example: source*, s??rce.cpp, *.{h,cpp}, *test*\\*.java, [A-Z,a-z]ource.cpp. The folder can be either static, then the files are immediately found and inserted, or dynamic, then the file are found at runtime.
• Delete button : removes the selected file from the list
• Open button : opens the selected file with system editor
• Path button : opens the file or folder browser to update the path

Data source information

The selected files can be edited.

• Statement retrieval from list: defines how statement are found in source documents, see Extraction Modes. The file icon is decorated to show the parsing mode.
• Relative path check box: The value may be the full path or simply the file name. In the latter case, the software searches the file in the same directory that the coverage file. The check-box switches between the relative and the absolute paths.
• File ID text: identifier that is combined with the heading number to built automatically a REQUIREMENT ID. Only available for Heading mode. The file ID is automatically computed with 3 characters.
• Edit button: allows to manually update the file ID. This allows to customize how the file is referenced in coverage, for example <RFP§1.1>. The customized file ID can be 8 characters long.

Extraction Modes

The coverage of a document requires information to identify the requirements: titles, rule numbers, sentence patterns.

The software of the REQCHECKER™ family works with documents. The requirements repository is no longer a computer database but a set of Word documents, Google Doc, PDF etc. This approach allows to write requirements in a more intuitive and user-friendly way. On the other hand, it makes their identification more difficult by the software.

The most effective method is to use a pattern, i.e. a common format for all requirements, such as specific characters to delimit the different information. This principle is the most common and the most reliable. It corresponds to the Syntax mode of REQCHECKER™.

<REQ_01> Overheating
The system should shut down when the sensor measures a temperature above 50°C.
#Version 2.1

When the document has not been written with patterns, it is possible to use the chapters as requirements. It corresponds to the Heading mode of REQCHECKER™

§2.3.1 Behavior in case of overheating
The system should shut down when the sensor measures a temperature above 50°C.

There are also documents without any structure: no rule number, no chapter structure. The solution is to analyze the structure of the must, should, could sentences. It corresponds to the Auto mode of REQCHECKER™

The system should shut down when the sensor measures a temperature above 50°C.

Syntax mode

Extraction mode Syntax extracts the requirements using the syntax defined in the Statement tab, see Statement Tab.

Icon:

Heading mode

Extraction mode Heading extracts the requirements from the heading numbers. ID are automatically generated.

Icon:

Syntax+Full mode

Extraction mode Syntax+Full extracts the requirements using the syntax and all other paragraphs of the document or data source. This mode allows to get the full text for verification and/or coverage.

Icon:

Database mode

Extraction mode Database extracts the requirements directly for the table. For an Excel file, the format of [Reqchecker] report is used: a header line with columns names followed by data lines.

Column list is : DOCUMENT, ID, POSITION, TEXT, TITLE, VERSION, COVERAGE DOC, COVERAGE POS, COVERAGE STATUS, COVERAGE VERSION.

Only the column ID is mandatory, other columns are optional. The column order does not matter.

It requires to fill in the columns with the final value of the text, title etc. You must not use read syntax tags such as << in this Excel file.

Other columns can be extracted too if a corresponding custom tag has been created with the same tag as the EXCEL column name, see custom tags definition. They appear in the Matrix tab of the Coverage Matrix (in blue columns) if you check the Extended coverage matrix option .

Icon:

This mode can be used if you provide an EXCEL file with the required column names and content provided upstream:

• or imported by you;
• or exported by Reqchecker via the matrix.

The software does not make the difference.

Auto mode

The "Auto" reading mode is designed for documents without structure. Its general principle is simple: it creates a requirement for each paragraph of the document.

A paragraph does not have an identifier, it must be generated. We have a text, but not a unique identifier, which is essential for the implementation of traceability. Without it, it is not possible to trace the coverage of the requirement in a document. REQCHECKER™ generates a unique identifier for the document from a hash code linked exclusively to the text, whenever possible. In case of duplicate sentences in the document, a serial number distinguishes them. This principle ensures impact analysis: in the majority of cases where the upstream document is updated, an unmodified requirement remains correctly covered.

According to the form of the sentence REQCHECKER™ identifies two pieces of information: the priority and the probability.

Icon:

Priority

Three values are identified using the MoSCoW classification:

• MUST: The requirement must be satisfied for the solution to be considered a success.
• SHOULD: The requirement is important and should be included in the solution if possible, but it’s not mandatory to success.
• COULD: It’s a desirable capability, but one that could be deferred or eliminated. Implement it only if time and resources permit.

WONT is not used and merged with COULD. Its value is presented in PRIORITY field in REQCHECKER™ reports.

Probability

Automated requirement recognition is based on a probability. The higher the probability, the more reliable the identification. However, this mechanism is only an aid and cannot replace a review by the user, who must go through all the requirements to check which sentences are requirements to be covered and which are not.

Three level are identified:

• High: The sentence has a high probability of being a requirement.
• Medium: The sentence has a medium probability of being a requirement.
• Low: The sentence has a low probability of being a requirement.

Its value is presented in IS REQ PROBABILITY field in REQCHECKER™ reports.

None mode

Extraction mode None extracts no requirement. The document is only used for coverage definitions.