Was this helpful?
Was this helpful?
This document provides details on how to model the requirements for workflows, user stories and process indicators.
Given the requirements document from your business analyst, create a process model that looks as follows. It captures who (role) does what (activity) in what sequence to accomplish the outcome.
Start by identifying the users. The users could be citizens, vendors or employees. It is important to identify the roles the users are playing e.g. in the above the citizen is the "Applicant", Vendor is the "Verifier" and the Head of Department is the "Approver".
For each role draw a swim lane (grey horizontal bar in the above diagram) which contains all the activities (boxes and rhombus). The activities should ideally be expressed in a "Verb Noun" pattern e.g. pay charges, verify application and so on.
Activities can be elaborated in two ways - as a user story or a use case. User Stories are an informal way of expressing what the user wants e.g. “As a [persona], I [want to], [so that].”
As an Applicant, I want to be able to provide enter the form as quickly as possible. I want to know the process and when the certificate will be available to me.
Use Case is a more formal way of capturing exact steps and alternate flows the user can follow e.g.
The Applicant logs into the system by entering the user name and password. The applicant then enters the following fields - child's name, mother's name, father's name, date of birth, and place of birth. All these fields are mandatory.
If you are following an agile process then the user story-based approach works fine. Agile also works well when you are not clear about the end outcome and want to iterate. However, if you are clear about what you want and also want to avoid too much back & forth communication between the product and engineering team during development with predictable outcomes then go with the use case-based approach.
Identify the process performance indicators that an administrator may want to see to monitor and identify areas of improvement. For example, the administrator may want to see the following metrics and compare them over various time periods and administrative hierarchies.
Number of applications
Number of applications by status
Average time to deliver the applications
Average time by status
Average feedback
Number of complaints
Number of complaints by status
Average time to resolve complaints
Number of reopened complaints
Steps to model requirements for workflows, user stories
