The Requirements module is where your process should start. Even though you can always add requirements later, if you want to work by the book, the application life cycle management process will start with the definition of requirements. Only then you should proceed to write and execute the tests, and report the issues detected by them. Each requirement may be linked to Tests and/or Issues in order to create traceability links (explained below on this page).

The requirements should list the items that need to be part of your product. They can also list the non-functional attributes of your AUT such as scalability, reliability, portability, and so on.

We recommend that you use the Requirements Filters Mode, which is fully customizable. Just like in the other modules (issues, tests, etc.), the filters mode allows you to organize your requirements using dynamic and cascading filters (hierarchical tree structure). You can organize your requirements by any criterion (field) assigned to requirements. For example, you can create a filter that will display all the requirements that belong to a certain product component, a certain version, etc.

Click here to learn more about Custom filters.

Requirement Parent Field

Another way to view your requirements is by using the Requirement Tree Mode, where each requirement can have a parent and can also have multiple child requirements, denoting the relationship and association between the different functional and non-functional aspects of your system.
To switch to the Requirements Tree mode, click on the “Requirements Tree Mode” link at the top of the view tree.

requirements_tree

As we explained above, requirements can be represented as a hierarchical tree, meaning that each requirement can have a parent and multiple children, denoting the relationship between the different attributes listed.

In order to manage this relationship, in addition to the regular fields and the Custom Fields that may be added to the requirements (and to any entity in PractiTest), a requirement also has a parent field.

This field will be the one to determine the specific tree structure for your requirements

Requirement Status field for full traceability

The Requirement’s status is derived from the Tests that are linked to it, and it’s essential for full traceability.
Requirement statuses are automatically set by PractiTest according to the following cases:

  • NOT COVERED – There are no tests linked to this requirement.
  • NO RUN – There is at least one test linked to the requirement. None of the linked tests ran.
  • STARTED – There is at least one test linked to the requirement that started running. None of them failed or was set to blocked.
  • PASSED – All linked tests ran and passed.
  • BLOCKED – At least one of the linked tests was set as blocked. None of the linked Tests failed.
  • FAILED – At least one of the linked tests failed.
  • N/A – All tests linked to this requirement are marked as N/A.

You may link as many Tests and Issues to each Requirement

requirement_traceability

Adding a New Requirement

To add a requirement in PractiTest, follow these simple steps:

  1. Go to the Requirements tab.
  2. Click the New Requirement.
  3. Fill out the fields for your requirements.
  4. link the Requirements to relevant tests/issues (optional).
  5. Click ‘Save Changes’ or ‘Save & Close’ to get immediately back to the Requirement Grid.

Creating a Test Set based on Requirements' traceability

A Test Set can be created directly from the requirements grid. If you want to create a test set that will cover the tests associated with a requirement, choose the requirement in the requirements grid and press the “Create a Test Set” button. A new test set will be created, and once you save it, you will see test instances pre-populated based on the tests linked to the chosen requirement.
create-testset-from-req

All articles
Next >>