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.

Its purpose is to read both requirements and other text to cover everything in downstream documents. This is useful, for example, when responding to a call for tenders where the customer slips obligations between formal requirements.

The text before the first chapter number does not have a number; its identifier is <file code>§-.

For example, consider the following text.

1 Writing requirements
This chapter presents writing requirements. 
Each requirement must be verified by cross-checking.
1.1 Language requirement
<REQ_01> The text must be written in English.

Reqchecker will then identify two requirements:

• DOC§1 “This chapter presents writing requirements. Each requirement must be verified by cross-checking.”
• REQ_01 The text must be written in English.

Icon:

Database mode

Extraction mode Database extracts the requirements directly from a table.

It requires to fill in the columns with the final value of the text, title etc. You shall not use statement tags such as << with this mode.

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. When importing from an Excel file, the recognized format is the same as that of the Coverage Matrix report: a header line with the column names, followed by the data rows. Only the first compatible EXCEL workbook sheet is loaded.

The list of predefined column titles is as follows : 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. Other columns not named with predefined values are also extracted. For each one, a corresponding custom tag is automatically created with the same name as the table column. They appear in the Matrix tab of the Coverage Matrix (in blue columns) if you check the Extended coverage matrix option .

Icon:

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.