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

  • Icon planned Planned: Test to be executed.
  • Icon passed Passed: Test passed with success (result is conform to expected result).
  • Icon blocked Blocked: Impossible to run the test because of a prior incident (blocking incident or incident on preceding test) or missing prerequisite.
  • Icon failed 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

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

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 Note 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 Icon description will display the test case description.
  • Moving the mouse over the icon Icon result will display the test case expected result.
  • Moving the mouse over the icon Icon prerequisite 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 Button add to add a test case run. The Test case run dialog box will be appear.
  • Click on Button edit to edit a test case run. The Test case run detail dialog box will be appear.
  • Click on Button icon delete to remove a test case run.
  • Click on Icon passed to mark test case run as passed.
  • Click on Icon failed to mark test case run as failed. The Test case run detail dialog box will be appear.
  • Click on Icon blocked 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

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

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

  • Icon not planned Not planned: No test case planned.
  • Icon planned Planned: No test failed or blocked, at least one test planned.
  • Icon passed Passed: All tests passed.
  • Icon failed Failed: At least one test failed.
  • Icon blocked 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.