Requirements

Concepts

• Product

• Project

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.

Requirements screen

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.

List of test cases section

• Click on to add a test case that will cover the requirement or part of the requirement.

Add a test case

• Click on to search for an item that is not in the list

• Click on to create a new item from the popup

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.

Summary test cases

This section summarizes the status of test case runs to requirement and test session.

• Planned: No test failed or blocked, at least one test planned.

• Passed: All tests passed.

• Failed: At least one test failed.

• Blocked: No test failed, at least one test blocked.

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

Required fields

Field	Description
Id	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	External reference for the requirement.
Requestor	Contact who requested the requirement.
Origin	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.

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.

Treatment

Required fields

Field	Description
Top requirement	Parent requirement, defining a hierarchic structure.
Status	Actual status of the requirement.
Responsible	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.
In progress	Box checked indicates the requirement is taken over.
Done	Box checked indicates the requirement has been treated.
Closed	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.
Result	Description of the implementation of the requirement.

Field Target version

Contains the list of product versions available according to the project and product selected.

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.

Fields when the requirement is locked

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.

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.

Test cases screen

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.
Responsible	Resource who is responsible of the test case.
Priority	Level of priority for the test case.
In progress	Box checked indicates the test case is taken over.
Done	Box checked indicates the test case has been treated.
Closed	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.
Expected result	Description of expected result of the test.

Field Prerequisite

If left blank and test case has a parent, parent prerequisite will automatically be copied here.

Test case run

Test case run

• Planned: Test to be executed.

• 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.

• Failed: Test has returned wrong result.

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 Summary

• An icon whose presents the run status of the test case.

• For detail, see: Summary of test case run status.

• To go, click on the corresponding test session.

Fields - Test case runs list

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

Test session screen

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

Other sections

• Assignment

• Progress

• Predecessor and Sucessor

• Linked element

• Attachments

• Notes

Description

Field	Description
Id	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	External reference for the test session.
Description	Complete description of the test session.

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.

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.
Responsible	Resource who is responsible of the test session.
In progress	Box checked indicates the test session is taken over.
Done	Box checked indicates the test session has been treated.
Closed	Box checked indicates the test session is archived.
Cancelled	Box checked indicates the test session is cancelled.
Result	Summary result of the test session.

Test case runs

Test case run section

This section allows to manage test case runs.

Test case runs list management

• Click on to add a test case run. The Test case run dialog box will be appear.

• Click on to edit a test case run. The Test case run detail dialog box will be appear.

• Click on to remove a test case run.

• Click on to mark test case run as passed.

• Click on to mark test case run as failed. The Test case run detail dialog box will be appear.

• Click on to mark test case run as blocked.

Fields - Test case runs list

Field	Description
Test case	Information about test case (type, Id and name).
Detail	Detail of test case.
Status	Status of test case run.

Field Test case

• This icon appears when the test case run comment field is filled.

• Moving the mouse over the icon will display the test case run comments.

Field Detail

• Moving the mouse over the icon will display the test case description.

• Moving the mouse over the icon will display the test case expected result.

• Moving the mouse over the icon will display the test case prerequisite.

Field Status

• If status of test case run is failed, information about selected ticket is displayed too.

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.