Requirements in Squash
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 by a requirement that can be qualified ("Criticality", "Status", "Category"…) to constitute the desired referentials repository.
Info
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: high-level requirements and standard requirements. High-level requirements correspond to a macro-feature or block of features that can be cut into multiple standard requirements.
You can tell a high-level requirement by its color: high-level requirements are blue whereas standard requirements are black in the requirement tree.
Focus
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 requirement 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.
Info
The name and the reference (optional) are determined during the creation of the requirement. We highly recommend giving 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 .
Learn More
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 Standard 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:
Information
The information block displays the requirement's attributes: Status, Criticality, Category and Description as well as its custom fields.
Coverage Indicator
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.
Learn More
For more details, please visit the page: View Requirement Coverage and Validation
For more information on high-level requirements, please read the part Indicators
Standard requirements linked to that high-level requirement
The Standard requirements linked to that high-level requirement block is only there for high-level requirements. You can view the requirements linked to the high-level requirement via the requirement tree. You can also 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.
Linked requirements
The block Linked requirements enables you to link requirements to the requirement you are viewing. A table displays information on the linked requirements.
Modification history
The table Modification history contains all the modifications made to a requirement when its status goes from "In progress" to "To be approved".
Known Issues
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.