Approval phase

Polarion makes the process of approving requirements simple and efficient. The following features are the ones to take a closer look at to support this phase:

• Workflow — Review and approval is just one or two steps in a larger process. That process is defined in the Project's workflow configuration. Polarion comes with several Project Templates that support requirements elicitation, authoring, and management. These have preconfigured Document types and Document workflows suitable for many requirements projects. If the defaults don't reflect your exact process, Project Templates, and/or individual projects can be customized by administrators to map your process into the workflows of both Documents and Work Items.

  When your process is mapped into the project workflow, then people always know the current status of a requirement, and what the next step is. For example, when a requirement is created, workflow might assign it a status of Draft, and define the next possible action as Send to review. When a user invokes that action, the requirement transitions to a new status — Under review, for example. Then, the workflow might present possible next actions such as Approve and Reject.

  Polarion automatically sends notifications to the relevant stakeholders when transitions occur. The workflow defines what happens when any action is invoked. For example, the Reject action might set the status back to Draft. The change can trigger a notification to the author, the assignee, and others. The Approve action could set a new status like Approved, also resulting in notifications.

  The foregoing is a relatively simple scenario. It is also possible to set up Document-specific workflows that make Document content read-only when the Document has a given status — In Review or Approved, for example. It is also possible to configure the workflow to require an electronic signature by users transitioning a Document from one status to another, and/or to provide an electronic signature when approving an entire Document.

• Auto-assignment — Again, Auto-assignment comes in handy. For example, you could configure Auto-assignment to reassign requirements to someone when the status changes — to Approved, for example. Possible assignees might include a developer in engineering, and/or a tester in QA. Again, appropriate notifications are sent when the status changes, so everyone who must do something with approved requirements automatically knows it's time to move forward.

  Tip:

  Be sure to have a project administrator look at the Notifications configuration to ensure that your scheme of notifications works the way you need it to work and notifications always go to all the right people for every system event, such as the status of a requirement changing.