Importing Requirements
Squash 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.
In Squash, 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 workspace.
Import File structure
The import file is composed of three tabs: REQUIREMENT, LINK_REQ_TC, and LINK_REQ_REQ. If you have a Squash Premium license, there is a fourth tab: LINK_HIGH_LEVEL_STANDARD_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);
- The LINK_HIGH_LEVEL_STANDARD_REQ tab allows you to enter the information to link high-level requirements to standard requirements (either already in the Squash or in the import file).
Structure of the file
The import file must follow these rules:
- The name of the tabs must not be changed.
- The headings of columns must not be changed.
- The blank rows are ignored.
- The cells must not be merged.
- The order of the rows does not matter.
- If you use any "Classify and protect" method for your data, check that the file is public so Squash can read it.
- The import is done row by row.
Data in HTML
Some columns must contain text in HTML format.
If this format is not respected (for example, if special HTML characters are not encoded), the import will be incorrect or rejected.
Moreover, to avoid security vulnerabilities, only certain HTML elements and attributes are allowed. Their list can be found here.
REQUIREMENT Tab
| Column name | Description | Expected value |
|---|---|---|
| ACTION | Value that indicates the action that you want to do. | Required FieldC: 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 outcome: - 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 | HTML text, see below for the constraints on this one. |
| 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, see below. |
LINK_REQ_TC Tab
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 |
LINK_REQ_REQ Tab
If you want to link requirements, the five 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 |
LINK_HIGH_LEVEL_STANDARD_REQ Tab
If you want to link high-level requirements to standard requirements, the two fields are mandatory.
| Column name | Description | Expected value |
|---|---|---|
| HIGH_LEVEL_REQ_PATH | High-level requirement path from project name to requirement name (current version) | For example: /project/folder/highLevelRequirement |
| STANDARD_REQ_PATH | Standard requirement path from project name to requirement name (current version) | For example: /project/folder/standardRequirement |
Importing Requirements
Importing allows you to create requirements with all the features available in 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, etc.
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.
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.
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:
- To have a custom list with several options, including
Option2linked to theOpt2ENcode.
- In the Excel file, fill in the option code value in the REQ_VERSION_CATEGORY column: here
Opt2EN. - 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 | HTML text, see below for the constraints on this one |
Importing Requirements related to Test Cases
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.
Importing Requirements related to other Requirements
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.
Importing Requirements with links between high-level and standard requirements
You must fill in the LINK_HIGH_LEVEL_STANDARD_REQ tab of the import file with the high-level requirement path and the standard requirement path. For the linking to work, the requirements to be linked must already be in the repository or in the import file.
The information is visible after the import in the high-level requirement's Standard requirements linked to this high-level requirement anchor and in the standard requirement's High level requirement field.
Here's the translation of the Kramdown text to English:
Constraints on imported rich texts
Imported rich texts (HTML text) should only contain basic elements and attributes. The list of these is:
| Element | Attributes ( class and style can be used for all elements) |
|---|---|
a |
accesskey, charset, dir, lang, name, tabindex, target, title, type |
blockquote |
|
center |
|
figure |
dir, lang, longdesc |
font |
color, face, size |
h1 |
|
h2 |
|
h3 |
|
h4 |
|
h5 |
|
h6 |
|
hr |
|
img |
dir, lang, longdescThe protocol of the image URL must be src, cid, data, http, or https. |
li |
|
ol |
|
p |
|
s |
|
span |
|
strong |
|
table |
align, border, cellpadding, cellspacing, dir, id |
td |
|
tr |
|
ul |
Any other element or attribute may be ignored by Squash TM.
(Additionally, future Squash TM releases may reject the import of a file containing HTML elements or attributes not present in this list.)