This page is maintained for older versions of Spira only. The latest documentation can be found at: https://spiradoc.inflectra.com

Spira 4.2 User Manual Help Viewer

1. Introduction
2. Functionality Overview
3. User/Project Management
4. Requirements Management
5. Test Case Management
6. Incident Tracking
7. Release Management
8. Task Tracking
9. Resource Tracking
10. Document Management
11. Reports Center
12. Source Code
13. Planning Board
14. Mobile Access
Search:
1. Introduction
2. Functionality Overview
3. User/Project Management
4. Requirements Management
5. Test Case Management
6. Incident Tracking
7. Release Management
8. Task Tracking
9. Resource Tracking
10. Document Management
11. Reports Center
12. Source Code
13. Planning Board
14. Mobile Access

4.1. Requirements List

When you click on the Planning > Requirements link on the global navigation bar, you will initially be taken to the requirements list screen illustrated below:

The requirements list consists of a hierarchical arrangement of the various requirements and functionalities that need to be provided by the system in question. The structure is very similar to the Work Breakdown Structure (WBS) developed in Microsoft Project®, and users of that software package will find this very familiar to use. When you create a new project, this list will initially be empty, and you will have to start using the <Insert> button to start adding requirements.

Requirements come in two main flavors: summary items shown in bold-type, and detail items shown in normal-type with a hyperlink. When you indent a requirement under an existing requirement, the parent is changed from a detail-item to a summary-item, and when you outdent a child item, its parent will return to a detail-item (assuming it has no other children). This behavior is important to understand, as only detail items are assigned a status themselves; the summary items simply display an aggregate of the worst-case assessment of their children’s status. Both summary and detail items can be mapped against test-cases for test-coverage, in addition the summary items display an aggregate coverage status.

Each requirement is displayed along with its importance/priority (ranked from “Critical” to “Low”), its completion status (from “Requested” to “Completed”), the version of the software that the requirement is planned for, and graphical indicators that represents its test coverage status and its task progress.

For those requirements that have no test-cases covering them (i.e. validating that the requirement works as expected) the indicator consists of a white solid bar, bearing the legend “Not Covered”. For those requirements that have at least one test-case mapped against them, they will display block graph that illustrates the last execution status of each of the mapped test-cases. Thus if the requirement is covered by two test cases, one of which passed, and one of which wasn’t run, the graph will display a green bar (50% passed) and an equal length gray bar (50% not run). To determine the exact requirements coverage information, position the mouse pointer over the bar-chart, and the number of covering tests, along with the pass / fail / blocked / caution / not-run breakdown will be displayed as a “tooltip”.

For those requirements that have at least one task associated with them, they will display a block graph that illustrates the relative numbers of task that are on-schedule (green), late-starting (yellow), late-finishing (red) or just not-started (grey). These values are weighted by the effort of the task, so that larger, more complex tasks will be change the graph more than the smaller tasks. To determine the exact task progress information, position the mouse pointer over the bar-chart and the number of associated tasks, along with the details of how many are in each status will be displayed as a “tooltip”.