Requirements¶
Requirement is a rule defined for a project or a product.
In most IT projects, requirement can be a functional rule for a software.
It allows to define and monitor cost and delays.
It can be linked to test cases, it’s used to describe how you will test that a given requirement.
Rights management
Linking requirements to a project will limit the visibility, respecting rights management at project level.
Requirement link to test cases
Test cases can be linked to a requirement in List of test cases.
Linking a requirement to a test case will display a summary of test case run (defined in test session). This way, you will have an instant display of test coverage for the requirement.
This section summarizes the status of test case runs to requirement and test session.
Requirement
Summarizes the status of test case runs for test cases are linked to the requirement.
Because a test case can be linked to several test sessions, total can be greater than linked to the requirement.
Test session
Summarizes the status of test case runs in the test session.
Requirement link to tickets
When test case run status is set to failed, the reference to a ticket must be defined (reference to the incident).
When the requirement is linked to a test case with this run status, ticket is automatically linked to the requirement.
Predecessor and successor elements
Requirements can have predecessors and successors.
This defines some dependencies on the requirements.
The dependencies don’t have specific effects. It is just an information.
Monitoring indicator
Possibility to define indicators to follow the respect of dates values.
Respect of validated end date
Respect of planned end date
Respect of requested start date
Respect of validated start date
Respect of planned start date
% final use of validated costs (revised/validated)
% final use of assigned work (revised/assigned)
% final use of validated work (revised/validated)
% final use of assigned work (revised/assigned)
% progress of validated work (real/validated)
% progress of assignated work (real/assigned)
% real progress
Description
Field |
Description |
---|---|
Unique Id for the requirement |
|
Name |
Short description of the requirement. |
Requirement type |
Type of requirement. |
Project |
The project concerned by the requirement. |
Product |
The product concerned by the requirement. |
External reference for the requirement. |
|
Contact who requested the requirement. |
|
Element which is the origin of the requirement. |
|
Urgency |
Urgency of implementation of the requirement. |
Initial due date |
Initial due date. |
Planned due date |
Planned due date. |
Description |
Long description of the requirement. |
Treatment
Field |
Description |
---|---|
Top requirement |
Parent requirement, defining a hierarchic structure. |
Status |
Actual status of the requirement. |
Resource who is responsible for the requirement. |
|
Criticality |
Level of criticality of the requirement for the product. |
Feasibility |
Result of first analysis to check the feasibility of the implementation of the requirement. |
Technical risk |
Result of first analysis to measure the technical risk of the implementation of the requirement. |
Estimated effort |
Result of first analysis to measure the estimated effort of the implementation of the requirement. |
Box checked indicates the requirement is taken over. |
|
Box checked indicates the requirement has been treated. |
|
Box checked indicates the requirement is archived. |
|
Cancelled |
Box checked indicates the requirement is cancelled. |
Target version |
Version of the product for which this requirement will be active. |
Description of the implementation of the requirement. |
Lock
A requirement can be locked to ensure that its definition has not changed during the implementation process.
Lock/Unlock requirement
Button to lock or unlock the requirement to preserve it from being changed.
Only the user who locked the requirement or a habilitated user can unlock a requirement.
Requirement locked
When a requirement is locked the following fields are displayed.
Field |
Description |
---|---|
Locked |
Box checked indicates the requirement is locked. |
Locked by |
User who locked the requirement. |
Locked since |
Date and time when the requirement was locked. |
Vote on requirement
It is possible to vote on requirement. In the detail tab of each requirement, find the voting section. The target value, current value, number of votes and fill rate are displayed.
Click on the vote button to assign a vote on the selected item.
In the voting window, several pieces of information such as the maximum point limit of the vote that you can use on the vote of the item in question.
Your personal vote which is not necessarily identical to the maximum points that you can award.
And finally the number of points that you have left to spend in the period of use set upstream in the rules for awarding and using votes.
Once you have validated your vote, if the specific access dedicated to voting have been activated, a table appears to display the names of the voters and the points that each of them has assigned to the element.
If several people have voted, the cumulative number of their points is displayed in the current value.
You continue to see the number of your points already assigned, directly in the vote button or in the table if you have the right to see it.
In the specific access, if the display of the table is deactivated, you can display at least the names of the voters.
In any case, the names of the voters and the points they have assigned are necessarily displayed in the table.
Test cases¶
Test cases are elementary actions executed to test a requirement.
You may define several tests to check a requirement, or check several requirements with one test.
The test case is defined for a project, a product or one these components.
Rights management
Linking test case to a project will limit the visibility, respecting rights management at project level.
Predecessor and successor elements
Test case can have predecessors and successors.
This defines some dependencies on the test case.
Dependencies don’t have specific effects. It is just an information.
Description
This section allow you to describe the test to run.
Fields Project and Product
Must be concerned either with a project, a product or both.
If the project is specified, the list of values for field “Product” contains only products linked the selected project.
Field Version
Contains the list of product and component versions available according to the project and product selected.
Field Environment (Context)
Contexts are initialized for IT Projects as “Environment”, “OS” and “Browser”.
This can be easily changed values in Contexts screen.
Field Description
The description of test case should describe the steps to run the test.
Treatment
Field |
Description |
---|---|
Parent test case |
Parent test case, defining a hierarchic structure for test cases. |
Status |
Actual status of the requirement. |
Resource who is responsible of the test case. |
|
Priority |
Level of priority for the test case. |
Box checked indicates the test case is taken over. |
|
Box checked indicates the test case has been treated. |
|
Box checked indicates the test case is archived. |
|
Cancelled |
Box checked indicates the test case is cancelled. |
Prerequisite |
List of steps that must be performed before running the test. |
Description of expected result of the test. |
Test case run
Passed: Test passed with success (result is conform to expected result).
Blocked: Impossible to run the test because of a prior incident (blocking incident or incident on preceding test) or missing prerequisite.
This section allows to display a complete list of test case runs. These are links of the test to test sessions. This list also displays the current status of the test in the sessions.
Field |
Description |
---|---|
Test session |
Composed of session type, Id and description. |
Status |
Current status of the test case run in the test session. |
Test sessions¶
A test session defines the set of tests to be executed to achieve a given objective, such as covering a requirement.
Define in the test case runs all test cases will be running to this test session.
For each test case run sets the status of test results. (See: Test case run status)
The test session is defined for a project, a product or one these components.
Rights management
Linking test session to a project will limit the visibility, respecting rights management at project level.
Test sessions regroupment
Test session can have parents to regroup test sessions.
Planning element
A test session is a planning element like Activity.
A test session is a task in a Gantt type project planning.
Allows to assigned resource and follow up progress.
Predecessor and successor elements
Test sessions can have predecessors and successors.
This defines some dependencies on test cases or planning constraints.
Monitoring indicator
The indicators can be defined in the List of Values.
See: Health status and Overall progress
Description
Field |
Description |
---|---|
Unique Id for the test session. |
|
Name |
Short description of the test session. |
Session type |
Type of test session. |
Project |
The project concerned by the test session. |
Product |
The product concerned by the test session. |
Version |
Version of the product or component concerned by the test session. |
External reference for the test session. |
|
Complete description of the test session. |
Treatment
Field |
Description |
---|---|
Parent activity |
Parent activity, to define hierarchic position in the Gantt. |
Parent session |
Parent session, to define session of sessions. |
Status |
Actual status of the test session. |
Resource who is responsible of the test session. |
|
Box checked indicates the test session is taken over. |
|
Box checked indicates the test session has been treated. |
|
Box checked indicates the test session is archived. |
|
Cancelled |
Box checked indicates the test session is cancelled. |
Summary result of the test session. |
Test case runs
This section allows to manage test case runs.
Field |
Description |
---|---|
Test case |
Information about test case (type, Id and name). |
Detail |
Detail of test case. |
Status |
Status of test case run. |
Note
When status is set to failed, the reference to a ticket must be defined (reference to the incident).
The referenced ticket is automatically added in linked element.
Field ticket appear only whether status of test case run is failed.