Model Requirements
In this step we will model the requirements as workflows, user stories and process indicators.
Model the Service Process Workflow
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.
Workflow diagram for birth certificate registration
Start by identifying the users. The users could be citizen, vendor or employee. Its important to identify the roles the users are playing e.g. in the above the citizen is the "Applicant", Vendor is the "Verifier" and Head of Department is the "Approver".
DIGIT Concepts
Tenant - DIGIT is a hierarchical multi-tenant system. State can be a tenant. Departments can be the next level tenant. So Punjab can be a tenant denoted by pb. Education Department can be denoted by pb.education.
Role - Role can be configured to provide a set of access to the user. "Approver" Role allows user to approve or reject the application but does not allow the user to edit the application.
User - When a user is created in DIGIT, they are mapped to Tenant and Role. So they have access only to those data that belong to that Tenant and can perform only those activities as defined in the role.
Workflow - Workflow is defined as a set of states e.g. New, Submitted, Verified, Approved. At each state, different roles can perform different actions e.g. Verifier can verify an application only when the application is in the "Submitted" state. Abstracting workflows allows DIGIT to configure different workflows for different tenants. E.g. if Jalandhar wants to configure additional roles and steps in the Birth Certificate process (as compared to Amritsar) then it will be possible to do so.
For each role draw a swim lane (gray horizontal bar in the above diagram) which contains all the activities (boxes and rhombus). The activities should ideally be expressed as "Verb Noun" pattern e.g. Pay Charges, Verify Application and so on.
Elaborate Activities
Activities can be elaborated in two ways - as a user story or a use case. User Stories are 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 more formal way of capturing exact steps and alternate flows the user can follow e.g.
The Applicant logs into the system by entering user name and password. The applicant then enters the following fields - child's name, mother's name, father's name, date of birth, 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 of the end outcome and want to iterate. However, if you are clear what you want and also want to avoid too much back & forth communication between the product and engineering team during development with predictable outcome then go with the use case based approach.
Elaborate Process Performance Indicators
Identify the process performance indicators that an administrator may want to see to monitor and identify areas of improvement. Example, the administrator may want to see the following metrics and compare them over various time periods and administrative hierarchies.
  1. 1.
    Number of Applications
  2. 2.
    Number of Application by Status
  3. 3.
    Average Time to Delivery the Applications
  4. 4.
    Average Time by Status
  5. 5.
    Average Feedback
  6. 6.
    Number of Complaints
  7. 7.
    Number of Complaints by Status
  8. 8.
    Average Time to Resolve Complaints
  9. 9.
    Number of Reopened Complaints
All content on this website by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
Copy link