Requirements and test scenarios must go through a review process in which multiple stakeholders can approve or reject. Spec-TRACER offers user-defined review workflows to facilitate the review process, where the project admin can assign review rights to specific user groups. For instance, each requirement may have to be reviewed by different stakeholders in the project. Analysts write the requirement, customers must decide if they agree on what the analysts wrote, technical people must decide if the requirement is feasible, project managers must decide if the requirement can be implemented taking into account project restrictions such as time and resources, the quality department must decide if the requirement agrees with the corporate rules for writing requirements, etc. If this (or anything similar to this) is the case, the best way to address this issue is to define a workflow for requirements.This application note explains in detail how to create workflows and as well as how to implement them.
A workflow is directly associated to an attribute with a set of predefined values. The attribute could be called Requirements Status, with values such as Proposed, Reviewed, Accepted, Analysed, Approved, etc. Each requirement must go through these levels of reviewing in order to be eventually accepted as part of the specification. There is a logical sorting of the different levels according to the characteristics of the organization and/or the project. The consequence of this sorting is that not all transitions between the different values of the attribute are possible: for instance, a requirement should only go from Proposed to Analysed, then to Accepted, then to Reviewed and, eventually to Approved (this is the simple picture; in practice, backward transitions and not-approval situations have also to be considered). A workflow allows the project’s administrators to define the set of allowed transitions between different values of a listed attribute, and restricting these transactions from being carried out, only to user groups that are authorised for it. A workflow is thus associated to a listed attribute. Concrete elements that are affected by workflow-defined restrictions are those that take values for the attribute associated to that workflow; i.e., the scope of the workflow is the same as for the attribute. In this way, workflows can affect the following element types:
For example, if the scope of the attribute is an items block, the workflow will only affect items that belong to that block. Transactions among values of the attribute allowed by a workflow are graphically represented using a state diagram. The user can define and consult workflows from text views.
Attributes with a set of defined values are created by the user to utilize within workflows. A simple example would be an attribute defined as Requirement Status with the values of Review, Needs Modification, Approved, and Rejected. Before defining the attribute, users need to define the values.
Go to the Project Organization | Attribute Types. This will open the Attribute Types Management window.
Click on the New Item icon () and create a new attribute type with the values mentioned above.
NOTE: Color coding the values is optional
Attribute Type: Defining Values
Once the user checks in the newly created attribute type, the user can then create the Requirement Status attribute.
Go to Project Organization | Attributes.
Click on the New Item icon () and create the attribute Requirement Status.
New Attribute: Requirement Status
NOTE: Only the default value needs to be added in the attribute window.
Once the attribute is checked in, it will be available to use in the workflow.
Users can create a new workflow by doing the following:
Go to Project Organization | Workflows.
Clicking on the New Item icon (). This will open the Add Workflow window which will allow users to define the name of the workflow, the access partition, and the attribute.
Creating a New Workflow
By default, the workflow is checked-out. In the Details tab of the Workflow Management Properties Panel, users can edit the workflow diagram.
In the Details tab, click on Edit. Users will be able to move the blocks around to the desired position.
Arranging the Workflow Diagram
Once the diagram is arranged to the user’s preference, the transitions can then be created. Click on the Create an external transition icon ().
Click and drag the transition from Needs Modification to Pending for Review. The Transition window will appear.
In this window, users have the ability to authorize which user groups have the permission to carry out the given transition.
NOTE: User Groups and Users assigned to User Groups are created in the Administration Center. For more information, see the Users and Groups section of the Administration Center User Manual.
The Event and Condition fields are optional and describe what causes the transition to occur i.e. A requirement that has been modified needs to be reviewed again.
Click OK once all of the necessary information has been provided.
Continue making the necessary transitions until the diagram is complete.
Completed Workflow Diagram
Once the diagram is complete, the user can check-in the workflow. In the Grid Panel, users can observe which requirements fall under which status category of the workflow.
Requirement Status for each FPGA Requirement
Users can change the status of the requirements by doing the following:
Check-out the requirement
In the Properties Panel, switch to the Blocks and Attributes tab.
Under the Requirement Status field, change the status.
Changing the Requirement Status
IMPORTANT NOTE: In order to change the Requirement Status, the user must be a member of the User Group that is permitted to perform the desired transition. If the user is NOT a member of the permitted User Group, the transition will not be available to select as shown below:
Limited Requirement Status Selection