# 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 linked element section.

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

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 initial due date
  Respect of planned due date

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

> Button: 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.

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

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

Note

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 all the tests to be executed to reach a given target.

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

This section allows to manage test case runs.

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.

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.

Test case run section

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.

# Summary of test cases section

Summary test cases

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.

Summary of test case run status

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