# 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`

Section: Description

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.

* Required field

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.

Section: Treatment

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.

* Required field

Field: Target version

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

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

Test case run status

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

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.

Section: Description

Field | Description
--- | ---
Id | Unique Id for the test case.
Name | Short description of the test case.
Test type | Type of test case.
Project | The project concerned by the test case.
Product | The product concerned by the test case.
Version | Version of the product or component concerned by the test case.
External reference | External reference for the test case.
Environment | List of 3 items describing the context of the test case.
Description | Complete description of the test case.

* Required field

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.

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

* Required field

Field: Prerequisite

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

Section: Test case runs

- 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

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 on the progress data.
- See: Monitoring indicator

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

* Required field

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.

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

* Required field

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

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

Dialog box - Test case run

Fields - Test case run dialog box
Field | Description
--- | ---
Test cases | Test cases list.
Allow duplicate | Check the box, if you allow this test case can be used more than once in a test session.

Diaglog box - Test case run detail

Fields - Test case run detail dialog box
Field | Description
--- | ---
Test case | Selected test case.
Status | List of test case run status.
Ticket | List of ticket.
Comments | Comments of test case run.

Field: Ticket

- Field appear only whether status of test case run is failed.

# Summary of test cases section

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.

> Note

> Field: Total

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

- Not planned: No test case planned.
- 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.

Fields - Summary of test cases
Field | Description
--- | ---
Total | Number of test case runs whatever the status.
Planned | Number of test case runs with the status Planned.
Passed | Number of test case runs with the status Passed.
Blocked | Number of test case runs with the status Blocked.
Failed | Number of test case runs with the status Failed.
Summary | Summary of test case run status.
Issues | Number of tickets linked to the requirement or the test session.

Note

- Percent to each status is displayed.