Skip to content

Importing Requirements

Squash TM allows you to import a tree of requirements from an .XLS file.

To import requirements, you must complete an Excel file by following the procedure on completing a requirements import file. Then, you can import this Excel file by using the [Import] option in the Requirements workspace. It is possible to simulate the import to verify the coherence of the import file before importing it.

Learn more

For more details on this procedure, please visit this page: Importing/Exporting an object.

Completing a Requirements Import File

Importing requirements via an Excel file allows you to mass create or modify a portfolio of requirements. You can import requirements, their attributes as well as associated items (requirements and test cases).

This feature is very useful, especially in these cases: - when you have to migrate requirements from a third-party tool; - when you have to retrieve a portfolio of specifications from an existing document; - when you have to mass modify requirements already in Squash TM.

In Squash TM, you can import a tree of requirements from an .xls, .xlsx, or .xlsm file.

Info

The import feature is available to "Admin" and "Project Leader" profiles.
You can download an import template from the import pop-up in the Requirements space.

Import File Structure

The import file is composed of three tabs: REQUIREMENT, LINK_REQ_TC and LINK_REQ_REQ

  • The REQUIREMENT tab allows you to enter the information related to the requirements to import such as location, description, criticality, etc.;
  • The LINK_REQ_TC tab allows you to enter the information to link requirements to case tests already in Squash;
  • The LINK_REQ_REQ tab allows you to enter the information to link requirement versions to each other (either already in Squash, or in an import file).

Focus

The import file must follow these rules:

  • The name of the 3 tabs must not be changed;
  • The headings of columns must not be changed;
  • The blank rows are not interpreted;
  • The cells must not be merged;
  • The order of the rows does not mattter;
  • The import is done row by row.

REQUIREMENT Tab

Column name Description Expected value
ACTION Value that indicates the action that you want to do. Required Field
C: to create (Create)
U: to update (Update)
REQ_PATH Requirement path. It starts with "/project name" and ends with the requirement name (= current version name, in other words the last version). The name of the project is included because the import is cross-project. Required Field
For example :
- /project/folder/requirement
- /project/PARENTrequirement/CHILDrequirement
REQ_VERSION_NUM Version number of the requirement.
CREATE Mode: If the field is not filled in, two outcomes :
- There is only one requirement version with this REQ_PATH, so REQ_VERSION_NUM=1.
- There are several versions of requirements with the same REQ_PATH, so the versions are numbered by their apparition number starting from 1.
UPDATE Mode: this field allows you to identify which version to update.
CREATE Mode: Optional field.
UPDATE Mode: Required field
REQ_VERSION_REFERENCE Requirement version reference
REQ_VERSION_NAME Requirement version name.
- CREATE Mode: This field is optional because it is at the end of the path in the REQ_PATH column.
- UPDATE Mode: allows you to rename a requirement
REQ_VERSION_CRITICALITY Requirement criticality code - CRITICAL
- MAJOR
- MINOR
- UNDEFINED [Default value]
REQ_VERSION_CATEGORY Requirement version category code.
The list can be the default list or a custom list. During the import, if the value is incomplete or unrecognized, the default value will be assigned.
- CAT_FUNCTIONAL
- CAT_NON_FUNCTIONAL
- CAT_USE_CASE
- CAT_BUSINESS
- CAT_TEST_REQUIREMENT
- CAT_UNDEFINED [Default value]
- CAT_ERGONOMIC
- CAT_PERFORMANCE
- CAT_TECHNICAL
- CAT_USER_STORY
- CAT_SECURITY
REQ_VERSION_STATUS Requirement status code - APPROVED
- OBSOLETE
- UNDER_REVIEW
- WORK_IN_PROGRESS [Default value]
REQ_VERSION_DESCRIPTION Description of the requirement
REQ_VERSION_CREATED_ON Requirement creation date.
The date must be entered in date cells or in text cells in ISO 8601 format.
Format : YYYY-MM-DD
If not entered, import date is used.
REQ_VERSION__CREATED_BY Creator login. If not entered, login of the user who did the import is used.
REQ_VERSION_MILESTONE Name of the milestone(s) related to that requirement.
If an objet is related to several milestones, each of the milestones must be entered in the matching column, separated with a '|'.
UPDATE Mode: if the columns is empty, current related milestones are deleted.
For example if a requirement is related to two milestones:
Milestone 1 | Milestone 2
REQ_VERSION_CUF_<cuf code> One column per custom field.
In heading, replace \<cuf code> with the custom field code.
Value linked to custom field

If you want to link requirements and test cases in the repository, the three fields are mandatory.

Column name Description Expected value
REQ_PATH Requirement path from project name to requirement name (Current version) NB: current version name can differ from version to link name For example:
- /project/folder/requirement
- /project/PARENTrequirement/CHILDrequirement
REQ_VERSION_NUM Requirement version number to link
TC_PATH Test case path from project name to test case name For example: /project/folder/testcase

If you want to link requirements, the 5 fields are mandatory.

Column name Description Expected value
REQ_PATH Requirement path from project name to requirement name (current version) NB: current version name can differ from version to link name For example :
- /project/folder/requirement
- /project/PARENTrequirement/CHILDrequirement
REQ_VERSION_NUM Requirement version number
RELATED_REQ_PATH Related requirement path from project name to requirement name (current version)
NB: current version name can differ from version to link name
For example: /project/folder/name_requirement_current_version
RELATED_REQ_VERSION_NUM Related requirement version number
RELATED_REQ_ROLE Role code field value for link between the requirements For example :
to link Requirement A (PARENT) to Requirement B (CHILD) with a parent-child role, enter Requirement B role: CHILD

Importing Requirements

Importing allows you to create requirements with all the features available on the Requirements workspace:

Creating a Tree of Requirements

The tree is very important because it allows you to organize the requirements repository. Importing allows you to create a precise tree of items to import. You can do this in several projects at once: Requirements, Folders, [Parent and child requirements] (./creer-organiser-referentiel-exigences.md#hierarchie-dexigences), etc.

Importing a tree of requirements

If the folders are not in Squash during the import, they are created by the import.

For example :

For the path /Project1/Folder1/ParentRequirement/ChildRequirement:

  • If the parent requirement is already in the repository, the child requirement is added under the parent requirement;
  • If the parent requirement is not in the repository but in the import file BEFORE the child requirement, the child requirement is added under the parent requirement;
  • If the parent requirement does not exist in the repository nor after the child requirement, the child requirement is added to the parent requirement file, which is a sub-folder of Folder 1.

Importing Requirement Versions

To create several versions of the same requirement, in the Excel file, you must assign one line to one version. You must enter the number of the version you want to create in the "REQ_VERSION_NUM" column.

Focus

To create a version 3 of a requirement, there must imperatively be a version 2.

Importing requirement versions

To modify a requirement version's attributes, the "REQ_VERSION_NUM" column must be filled with the number of the version to modify and the "REQ_PATH" column the path of the requirement's current version.

Update requirements via import

Importing requirements with a custom list

If a custom list is set up for the project's requirements category, in the import file, fill in the option code wanted in the "REQ_VERSION_CATEGORY" column.

For example:

  1. To have a custom list with several options, including "Option 2" linked to the "Opt2".
    Custom list page
  2. In the Excel file, fill in the option code value in the "REQ_VERSION_CATEGORY" column: here "Opt2".
  3. The requirement is created when the file is imported. The "Category" field is filled by "Option2"

Importing requirements with custom fields

If custom fields (CUF) are set up for the project's requirements, in the import file, the "REQ_VERSION_CUF_<cuf code>" column can be filled. There must be one column for each custom field. The column's heading must contain the custom field's code, which is available on its consultation page.

"REQ_VERSION_CUF_<cuf code>" Column Content :

Custom field Type Expected value
Tag Tag1|Tag2
Checkboxes 'true' ou 'false'
Drop-down list Option label
Numerical digit For example : '50', '12,8'
Date 'YYYY-MM-DD'
Simple Text Unformatted text with 255 characters maximum
Rich Text To import the formatted text, it must be in HTML format

You must fill in the "LINK_REQ_TC" tab of the import file with the requirement path, the version number, as well as the path of the test case to be linked. For the linking to work, the test case must already be in the repository.

The information is visible after the import in the requirement's "Test case verifying this requirement" anchor.

You must fill in the import file's "LINK_REQ_REQ" tab with the path of the two requirements to be linked as well as their version number and the link type code. For the linking to work, the requirement to be linked must already be in the repository or in the import file.

The information is visible after the import in the requirement's "Linked requirements" anchor.

Back to top