Model Requirements
Overview
This document provides details on how to model the requirements for workflows, user stories and process indicators.
Steps — Model the Service Process Workflow
Given the requirements document from your business analyst, create a process model that captures who (role) performs what (activity) in what sequence to achieve the desired outcome.
Start by identifying the users. The users could be citizens, vendors or employees. It is essential to identify the roles users play — e.g., in the above example, the citizen is the "Applicant", the 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).
Activity Details
Activities can be elaborated in two ways — as a user story or a use case.
User Story (informal)
Format: “As a [persona], I [want to], [so that].”
Example: As an Applicant, I want to be able to enter the form as quickly as possible. I want to know the process and when the certificate will be available to me.
Use Case (formal)
Captures exact steps and alternate flows.
Example: 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 well. 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-and-forth communication between the product and engineering team during development with predictable outcomes, then go with the use case-based approach.
Process Performance Indicators
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.
Last updated
Was this helpful?