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 non-ambiguous 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]"
Requirement consultation page
A requirement's consultation page appears when the requirement is selected in the requirements library.
A requirement's consultation page contains 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. Giving your requirement a reference is highly recommended for the organization your repository.
You can modify a requirement's reference and name from its consultation page.
You can add a new version of a requirement or attachment by using the buttons located on the top right of the page: and
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: - "Coverage rate": indicates the percentage of test cases with the status "To be approved" or "Approved", amongst all the test cases covering the requirement or one of its subrequirements; - "Verification rate": indicates the percentage of executed test cases, amongst the cases covering the requirement or one of its subrequirements; - "Validation rate": indicates the percentage of test cases with a conclusive execution status (Success or Settled ). It only takes the last execution into account, among the executed test cases covering the requirement or one of its subrequirements.
For more details, please consult the page: View Requirement Coverage and Validation
Test Case Verifying This Requirement
The block "Test case verifying this requirement" allows you to link test cases to the requirement. A table displays information on the linked test cases.
The block "Related requirements" allows 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. Three clickable links allow the user to access: - the consultation page of the issue in the bugtracker; - the consultation page of the execution during which the issue has been 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.