Requirements in Squash TM
What is a Requirement?
A requirement is "A condition or capability needed by a user to solve a problem or achieve an objective that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document." (ISTQB)1. A requirement describes the expected behavior from a system (software, website, app, etc.) previously defined in a specific document to answer a user's needs.
The term "requirement" covers multiple levels, from qualification requirements (macro) to test requirements (micro). Software project deliverables (specifications, functional specifications, detailed specifications, mock-ups) enable the extraction of requirements.
In Squash TM, a requirement is an object of the Requirement Workspace. Every requirement or managing rule qualifying a system can be represented in Squash TM by a requirement that can be qualified ("Criticality", "Status", "Category"...) to constitute the desired referentials repository.
A requirement must be unambiguous and testable: it must offer a way of proving that the system meets its description.
Each test requirement describes an expected behavior. It can be written under this form: "The app must allow [Action]"
There are two types of requirements in Squash TM: high-level requirements and classic requirements. High-level requirements correspond to a macro-feature or block of features that can be cut into multiple classic requirements.
You can tell a high-level requirement by its color: high-level requirements are blue whereas classic requirements are black in the requirement tree.
High-level requirements are available with Squash Premium license and the Squash TM Premium plugin.
Requirement Consultation Page
A requirement's consultation page appears when the requirement is selected in the requirements library.
A requirement's consultation page consists of:
- the requirement's name and reference;
- its status, criticality, and version number indicated with small icons;
- its attributes and links in dedicated retractable blocks.
The name and the reference (optional) are determined during the creation of the requirement. We highly recommend that you give your requirement a reference for the good organization of your repository.
You can modify a requirement's reference and name from its consultation page.
You can add a new version of a requirement, turn a requirement into a high-level requirement, and print a requirement by clicking on the button on the top right of the page: . You can add an attachment by clicking on the button .
To learn more about versioning requirements, please visit the page: Version Requirements.
To learn more about how to turn a requirement into a high-level requirement, please visit this page Turn a Classic Requirement into a High-Level Requirement.
The anchor bar on the left allows you, by clicking on an anchor, to access to the corresponding block:
The information block displays the requirement's attributes: "Status", "Criticality", "Category" and "Description" as well as its custom fields.
The "Coverage indicators" block contains the following indicators:
- "Redaction rate": indicates the percentage of test cases with the statuses "To be approved" or "Approved", amongst all the test cases covering the requirement, its subrequirements, or its linked requirements in the case of a high-level requirement;
- "Verification rate": indicates the percentage of executed test cases, amongst the cases covering the requirement, its subrequirements, or its linked requirements in the case of a high-level requirement;
- "Validation rate": indicates the percentage of test cases with a conclusive execution status (Success or Settled). It only takes the last execution into account, amongst the executed test cases covering the requirement, its subrequirements, or its linked requirements in the case of a high-level requirement.
Classic requirements linked to that high-level requirement
The "Classic requirements linked to that high-level requirement" block is only there for high-level requirements. It enables you to view the requirements linked to the high-level requirement via the requirement tree. It also enables you to associate this high-level requirement with other requirements from another location in the library. A table displays the information of the linked requirements.
Test Case Verifying This Requirement
The block "Test case verifying this requirement" enables you to link test cases to the requirement. A table displays information on the linked test cases.
The block "Linked requirements" enables you to link requirements to the requirement you are viewing. A table displays information on the linked requirements.
The table "Modifications history" contains all the modifications made to a requirement when its status goes from "In progress" to "To be approved".
The table of the "Known Issues" anchor 2 lists the issues declared during the execution of the tests linked to the requirements. This table is automatically updated in real time by the bugtracker. It cannot be modified. There are three links you can click to access:
- the consultation page of the issue in the bugtracker;
- the consultation page of the execution during which the issue was identified;
- the consultation page of the requirement or subrequirement impacted by the issue.
If there are multiple versions of the requirement, only the requirements linked to the requirement's current version are displayed.
If there is a hierarchy of requirements, the parent requirement's "Known issues" table lists all the requirements linked to both the parent requirement and its children requirements.