About requirements workflows

A Requirement is something that is needed or desired for your project. These could be the physical specifications of the product you are delivering to your customer, a procedure that must be adhered to, a timeline that must be followed, etc. Your customers will outline everything that they need from you at the start of a project (and potentially throughout) and so it can be helpful to organize them in an indented list in the Business Processes section of the project.

A Requirement Workflow is used to move a requirement through each lifecycle status and can help you manage any necessary tasks that must be completed to mark a requirement as met.

Before you start

Before you start modeling QA process workflows, we recommend that you already have a process in mind. Mapping this process out in a diagram application gives you a solid base from which to start.

Things to consider include, but are not limited to:

• Will different requirement types need different workflows?
• Who will be in charge of completing each requirement?
• Who will be responsible for each step of completing the requirement?
• What would be some reasons why a requirement could not be met?
• What additional actions might need to be taken should a requirement not be met?
• Are there any additional actions that should occur at each step? (notifications, status updates, etc).

For example, you may have a set of mechanical requirements that the mechanical design team are in charge of following. The steps might be:

1. Lead mechanical designer creates the requirement and assigns it the workflow.
2. The workflow assigns the requirement to the mechanical design team.
3. A mechnical designer marks the requirement as In Progress.
4. The same mechanical designer considers the requirement as met and re-assigns it to the lead mechanical designer to review.
5. The lead mechanical designer reviews the requirement and considers it met and marks the requirement as Passed.

Make sure to include all the steps in your ideal process (happy path) as well as any possible roadblocks (exception path) that may occur. In the example above, it might be the case that the designer does not agree with the markup sent to them and assigns it back to the IR creator to change or discard. You should ensure this process is built into your workflow.

To help you in your planning, read through the list of available primitives to get a sense of what is possible.