Definition of Need

Requirements is an important artifact that is associated with tasks for completion and test cases for verification.  Currently, all Spira editions (SpiraTest, SpiraTeam, and SpiraPlan) support 16 requirement statuses. These include the following. 

  1. Requested
  2. Under Review
  3. Rejected
  4. Accepted
  5. Planned
  6. In Progress
  7. Developed
  8. Tested
  9. Completed
  10. Obsolete
  11. Ready for Review
  12. Ready for Test
  13. Released
  14. Design In process
  15. Design Approval
  16. Documented

Customers sometime want to have a new requirement status or modify the existing status names. While providing some level of automation of requirement card movement in the Kanban approach, this is a limitation as allowing these statuses to be modified or new statuses to be added also requires deeper level of status association with other artifacts. So, what if we want to have a new definitions like "Blocked" or "On Hold"? This is why Spira platform provides additional custom properties (up to 99 properties at each level) to customize the business process as appropriate.  Let us evaluate how we can do this.

Define Custom List

First Let us Define a Custom List that has this definition of what we would like to add.  We have added two custom list values (Blocked, On-Hold) to a new Custom List (Requirement Sub-Status).

Map a new Custom Property

Now, let us add a new custom property in the requirement artifact and map it to this newly defined custom list.

 

Update Requirement Workflow

Among the 16 requirement statuses, use one of the requirement statuses as a placeholder for this requirement sub-status identification. Update the requirement workflow to mandate that sub-status as a required entry when this placeholder status is used in any transition.  For instance, a good candidate for this placeholder requirement status is the "Documented" which is an indication of anything that is documented, such as things having an obstacle, put on hold, blocked, impeded, etc.  

Create a Transition to the Placeholder Requirement Status

In the following diagram, we have created a transition step (Park Requirement) in the "Default" workflow to move it from "Requested" to "Documented" state. This transition can be defined on any input state so long as it is resulting in the "Documented" state, which is our placeholder requirement state.  For the brevity of the diagram, the transitions that move from an input state to the "Documented" state (Shown in Red box) and the move from this "Documented" state to another state (Shown in Green box) is shown below. 

Make the Requirement Sub-Status Required

Next, you will have to ensure that this sub-status customer property is a required field in the "Documented" state. You can hide this sub-status field for all other transitions (not shown again for brevity).

Associate Workflow with Requirement Type 

It is imperative that the requirement type is appropriately connected with this artifact. For instance, for workflow name is "Default". Otherwise, you will not see the new transition steps.

Invoke Workflow on the requirement

Then, invoke the workflow on the requirement to ensure that the appropriate operation is invoked. Here, we are invoking the "Park Requirement" moving the requirement from "Requested" to "Documented". 

Update Sub-Status

As you invoke this transition step, we can see that the "Requirement Status" moved to "Documented" and the "Sub-Status" field became required (note the asterisk). We can now fill the new requirement sub-status.

 

 

Use Custom Property to eliminate requirement in releases

In the requirement grid view, we now can use the combination of the "Release" and the newly added Custom List (Sub-Status) property to filter those requirements that are now in a sub-status. If these requirements were not associated with a release (as is our case) or removed from the release when it moved to the Documented State, then, the release can be made optional and is not relevant for filtering purposes. 

 

Custom SQL Query

Given below is a simple SQL query. It only brings the requirement id, name, requirement status, the requirement sub-status name from the custom list. As the requirement entity only stores a key to the custom list, in the SQL query below, a join is required with the custom list values entity. 

select 
  R.REQUIREMENT_ID, 
  R.NAME, 
  R.REQUIREMENT_STATUS_NAME, 
  C.NAME as REQUIREMENT_SUB_STATUS 
from 
  SpiraTestEntities.R_Requirements as R 
join SpiraTestEntities.R_CustomListValues as C on 
   C.PROJECT_ID = R.PROJECT_ID and 
   cast(R.CUST_01 as int32)= C.CUSTOM_PROPERTY_VALUE_ID
where 
  R.PROJECT_ID = ${ProjectId} and 
  R.REQUIREMENT_STATUS_NAME = "Documented"

Report Requirements

Given below is an example of the report.