use$cases,$business$rules,$data$and$user$interface$ mockups… ·...

Use cases, Business Rules, Data and User Interface Mock-‐ups -‐ How it All Ties Together

Natasha Kordonska, CBAP

Meet Laura

§  Laura is a Business Analyst assigned to a project to automate reques>ng computer equipment for Investment branches through Equipment Portal

What is the Problem or Opportunity?

n  Laura meets with Business Sponsor and interviews her to understand the problem project is to solve

n  She analyzes her interview notes, conducts root cause analysis and comes up with the following problems:

Problem/Opportunity DescripHon PO01 – Manual equipment order process is error prone and causes delays

Currently, equipment order is a manual process where users complete paper forms, scan and email or fax these forms to ini>ate the process; as a result, many requests have errors, are returned for incompleteness or are lost. This causes delays and lost produc>vity.

PO02 – No visibility to order status and fulfilment

Users have no way to see whether their request has been approved, and if/when it will be fulfilled which leads to user frustra>on and lost produc>vity as they are trying to call and find out where their request is.

Who Are Our Stakeholders?

1. Business Context Diagram

Branch Manager

Equipment Portal

Cost Estimate, Request Status

Branch Administrator

Request Info

Notification Equipment Group

Fulfilment Status

Investment Advisor

Approve/Decline, Expense Allocation

Notification

Approve/Decline

Notification

Based on current state procedures, Laura draUs the stakeholders and their involvement with the new automated process – she knows she has to include par>cipants from all groups into her requirements sessions

What is Our Scope? n  Based on further discussions with Business Sponsor and Business SMEs, Laura draUs Scope

statements, invites Business and Technology SMEs and facilitates a session to elicit High Level Requirements

n  Session goes well, and aUer updates to the draU, Laura’s High Level Requirements are complete:

HLR# HLR DescripHon HLR01 Branch Administrator must be able to create, update and cancel a request* for a computer equipment electronically

HLR02 Branch Administrator must be able to view the status of the submiZed request electronically

HLR03 Branch Administrator must be able to receive no>fica>on of the request approval, decline, and comple>on electronically

HLR04 Branch Manager must be able to approve/decline and allocate expense to Branch or Advisor electronically

HLR05 Investment Advisor must be able to approve/decline expense allocated to Advisor electronically

HLR06 Equipment Group user shall receive no>fica>ons of requests ready for fulfillment through the system based on rules

HLR07 Equipment Group user shall be able to update final expense and fulfillment date in the system

*Request can include: new computer, reimage exis>ng computer, remove old computer

What is Our Plan? §  Now that Laura understands the scope and stakeholders, she can create Business Analysis Plan §  Laura plans each of her deliverables (Use Cases, Data, Rules, UI) and ac>vi>es to get them elicited, analyzed, reviewed

Task%and%Milestones%Effort

hrs%BA% Resources% Technique%

Business'Process','Iteration'1'Prepare%draft%Business%Process%Diagram%for%BP01?%Place%

Equipment%Request%

4% Laura% % %

Trace%High%Level%Requirements%to%Business%Process%

Diagram%as%applicable%

2% Laura% % %

Elicitation%session%for%BP01%–%Place%Equipment%Request% 3% Laura% Jim,%Clara,%Dan,%Tim% Elicitation%Workshop%

Analyze%and%document%BP01%–%Place%Equipment%Request% 7.5% Laura% % %

Review%BP01%–%Place%Equipment%Request% 1% Laura% Jim,%Clara,%Dan,%Tim' Walkthrough%

Update%and%distribute%Business%Process%Diagram%for%

BP01%–%Place%Equipment%Request%

2% Laura% % %

Use'Case'Diagram','Iteration'2'

Draft%Use%Case%Diagram%for%Equipment%Portal% 7.5% Laura% % %

Trace%Business%Process%Diagram%to%Use%Cases%as%

applicable%

1% Laura% % %

Elicit%Use%Case%Diagram%for%Equipment%Portal% 3% Laura% Jim,%Clara,%Dan,%Tim% Elicitation%Workshop%

Analyze%and%document%Use%Case%Diagram%for%Equipment%

Portal%

3% Laura% % %

Review%Use%Case%Diagram%for%Equipment%Portal% 2% Laura% Jim,%Clara,%Dan,%Tim% Walkthrough%

Update%and%distribute%Use%Case%Diagram%for%Equipment%

Portal%

1% Laura% % %

Use'Cases','Iteration'3'

Draft%UC01%–%Place%Equipment%Request%% 15% Laura% % %

Trace%Business%Process%Diagram%to%Use%Cases%as%

applicable%

2% Laura% % %

Elicit%UC01%–%Place%Equipment%Request% 4% Laura% Jim,%Clara,%Dan,%Tim% Elicitation%Workshop%

Etc.% % % % %

!

What is Future State Business Process?

Laura draUs and reviews with stakeholders future state process – everyone is in agreement!

Advisor

What is Our System Scope? Laura draUs, reviews with stakeholders, updates and obtains agreement on Use Case Diagram

ID Use Case Description UC01 Manage Request This use case describes a process where user can create,

view, update, cancel equipment request. System provides preliminary estimate and delivery of the request and routes the request for approval or fulfillment according to the rules.

UC02 Decision Request This use case describes a process where user can approve or decline equipment request and allocate costs to branch or IA. System routes approved or declined request to another approver, the requestor or for fulfillment according to the rules.

UC03 Fulfill Request This use case describes a process where user can update the status of the request and final estimate and delivery after fulfillment.

Actor Description Requestor An employee user who can create, update,

cancel and view equipment request. This role can be played by Branch Administrator.

Approver An employee user who depending can approve/decline equipment request and allocate expense based on their authority level. This role can be played by Branch Manager.

Fulfillment User An employee user who can fulfill request for equipment and update the system accordingly. This role can be played by Market Data and Equipment Group user.

Use Case Now Laura draUs her first Use Case: UC01-‐Manage Equipment Request

Basic Flow Step AlternativeFlow1. Thisusecasestartswhenuserrequeststocreateanew

requestAF001–WorkWithExistingRequest

2. Systempromptsforrequestinformation 3. Userprovidesrequestedinformation 4. Systemsuccessfullyvalidatesprovidedinformation AF002–InvalidUserInput5. Systempresentsuserwithfulfillmentestimateandprompts

forconfirmation

6. Userconfirmsrequestsubmission AF003–UpdateRequest7. SystemsendsrequestforapprovaltoBranchManagerand

informsuserthatrequestissentforapproval

8. Usecaseends.

AF001–WorkWithExistingRequestStep AlternativeFlow1. Thisflowstartsatstep1ofthebasicflowwhenuser

requeststoworkwithexistingrequest

2. Systempromptsusetosearchforrequest 3. Userprovidesrequestinformation 4. Systempresentssearchresults AF005–NotFound 5. Userselectsdesiredrequest 6. Systempresentsdetailedrequest 7. Userreviewsrequestandexits AF003–UpdateRequest8. Usecaseends.

Step 2: What informa>on?

Step 4: Validates how?

Step 5: How will cost es>mate be calculated?

Step 2: How can we search?

Step 4: What search results are presented?

Step 6: What details of the request are presented?

Now What?

Complete FuncHonal Requirements

11

User Interface

Data

Use Case

Rules

Laura recalls from her training that complete func>onal requirements have these four components

User Interface: requirements for content presenta>on (screens, forms, reports, naviga>on, user messages) that system uses in the process of achieving a goal

Rules: requirements for logic that system uses in the process of achieving a goal

Data: requirements for informa>on system uses in the process of achieving a goal

Use Case: interac>on process between actor and system in the process of achieving a goal.

Data Requirements

Laura starts with Data requirements – what is the request informa>on user needs to populate to create new request?

ID Business Name DescripHon Valid Values Sample Data

DE01 Part Number Equipment part number of from catalogue

See Part Number List -‐ Number Column

r38930

DE02 Part Descrip>on Descrip>on of equipment requested

See Part Number List -‐ Descrip>on Column

Laptop

DE03 Need By Date Date by which the request needs to be fulfilled

>= DE10_Current Date+1 business day

May 16, 2012

DE04 Request Type Descrip>on of request type New Reimage Removal

New

Now Laura can indicate which data will be used at which step of the use case

She updates the use case

13

Linking Data and Use Cases

Basic Flow

Step Alternative Flow/Data

1. This use case starts when user requests to create a new request

AF001 – Work With Existing Request

2. System prompts for request information DE01 – Part Number (M)* DE02 – Part Description (M) DE03 – Need By Date (O)** DE04 – Request Type (M)

3. User provides requested information 4. System successfully validates provided information based on

data validation rules – see Data Dictionary AF002 – Invalid User Input

5. System presents user with cost estimate and prompts for confirmation

6. User confirms request submission AF003 – Update Request 7. System sends request for approval to Branch Manager and

informs user that request is sent for approval

8. Use case ends.



Step 5: How will cost es>mate be calculated?

*M-‐ Mandatory **O -‐ Op>onal

Business Rules and Requirements

n  Laura recalls her training on business rules §  Business rule: specific, testable direc>ve to guide behaviour, shaping judgments, or making decisions (BABOK, V3).

§  Business Rule Requirement: what func>onality needs to be included to enable business rule

14

Rules enabled by FuncHonal Requirements

Business Rules -‐ Defini>onal -‐ Behaviourial

Technology Enabled

Process Rule Data Rule

Manual

Rules enabled by OperaHng Procedures

Manual Business Rules n  Non automated rules govern, enable and constrain the manual business processes

n  They are part of the procedures, job aids and employee training which is followed by the business workers, e.g.

§  A customer is any individual that does business with the bank

§  A government issued photo id such as a drivers license is required to open an account

§  If minimum payment is not received on a credit card within 15 days of statement date then the account is considered delinquent

n  Refer to these rules in the Business Process Diagram(s)

15

Technology Enabled Rules

Process Rule

Enables or Constraints actor or system ac>on, e.g. User Permissions

Affects the flow of process, e.g. Approval

Data Rule

Evaluates data, e.g. is it valid?

Sets data, e.g. calcula>on

16

DocumenHng Business Rules Laura documents the business rule to calculate cost es>mate

ID Name Business Rule BR01 Determine

Cost Es>mate

17

CondiHon: DE04 –Request Type Outcome: DE05 – Cost EsHmate

New $500

Reimage $250

Remove $50

Now Laura can indicate how fulfillment es>mate will be determined at the use case step

She updates the use case

18

Linking Rules and Use Cases

Basic Flow

Step Alternative Flow / Data / Business Rule

1. This use case starts when user requests to create a new request

AF001 – Work With Existing Request

2. System prompts for request information DE01 – Part Number (M)* DE02 – Part Description (M) DE03 – Need By Date (O)** DE04 – Request Type (M)

3. User provides requested information 4. System successfully validates provided information based on

data validation rules – see Data Dictionary AF002 – Invalid User Input

5. System determines cost estimate and presents user for confirmation

BR01 – Determine Cost Estimate

6. User confirms request submission AF003 – Update Request 7. System sends request for approval to Branch Manager and

informs user that request is sent for approval

8. Use case ends.



Step 5: How does fulfilment es>mate look like?

*M-‐ Mandatory **O -‐ Op>onal

Linking Use Cases and UI

§  Laura remembers that use cases must be UI agnos>c, but how does she make sure all the use case requirements are addressed by her UI?

§  The answer comes to her when she remembers Use Case scenarios: §  Use Case describes all possible paths through the process §  Use Case Scenario describes one specific path through the process

§  She realizes she needs to create UI storyboards for each use case scenario! §  Storyboard is sequence of screens to complete business scenario

§  She iden>fies all different business scenarios by going through use cases and creates a storyboard for each (some storyboards will be addressing mul>ple scenarios)

Use Case Scenario Name DescripHon

UC01 -‐Basic Flow à End Use Case

SB01-‐Input Request and Exit

User creates new request, views request summary, submits it and exits

UC01 -‐Basic FlowàAF04 -‐ Con>nue

SB02-‐ Input Request and Con>nue

User creates new request, views request summary, submits it and con>nues with requests

UC01 –AF01 -‐ Work With Exis>ng Request

SB03-‐ View Exis>ng Request and Exit

User searches for request, views it and exits

UC01 -‐AF01 -‐ Work With Exis>ng RequestàAF03 -‐ Update Request

SB04-‐Update Exis>ng Request and Exit

User searches for request, views it, updates and exits

Etc.

Storyboards Laura now documents iden>fied storyboards…

20

SB001 -‐ Input Request and Exit

UI001-Home Page

UI002-Input Request

UI004-Request Summary

SB002 -‐ Input Request and ConHnue

UI001-Home Page

UI002-Input Request


SB003 -‐ View ExisHng Request and Exit

UI001-Home Page

UI003-Search Results


SB004 -‐ Update ExisHng Request and Exit

UI001-Home Page

UI003-Search Results


UI002-Input Request


User Interface Requirements

21

ID Name Data Element Reference

UI Type Displayed Y / N /

<CondiHon>

Enabled Y / N /

<CondiHon>

Default Value PresentaHon Format

User AcHon NavigaHon/UI Response

C01 Select New

Request Radio

BuZon Y Y N/A N/A Select Navigate to UI002 Input Request

C02 Search for Request Radio BuZon Y Y N/A N/A Select Display C003,

C004, C005

C03 Search by Date

DE03 – Need By Date

Single Select Drop Down

List

Y when C002 is selected

Y when C002 is selected Current Date dd/mm/yyyy Select

Navigate to UI004 Request

Summary

Etc.

UI001-Home Page

Equipment Portal

New Request

Search for Request

Search by Need by Date:

Search by Status:Drop Down

[Submit]

Search by Assigned to:Drop Down

1

2

3

4

5

6

7

Day Month Year

§  Finally, Laura completes UI mock-‐ups with the help if Tim – UI expert

§  She supplements each mock-‐up with detailed descrip>on

§  She documented good deal of informa>on in data dic>onary which she does not want to repeat, so she includes reference to data elements

Cross-‐Model ValidaHon is Complete!

Laura now has closed all the gaps and is comfortable her requirements will be approved by stakeholders

In Conclusion: Pu`ng it All Together

Use Case References Data and Rules

Data Includes Data Defini>ons and

Rules

Business Rules References Data

User Interface References Use Case and Data

§  Some system ac>ons (never actor!) in Use Case flow need Business Informa>on, or Data

§  Use Case documents

the acHon of using the data and

the reference to the data used in the step

§  Data is typically reused across mul>ple use cases, it is best to document in Data Dic>onary

24

How it All Ties Together

Use Cases and Data Use Cases and Rules

§  Some system ac>ons (never an actor!) need to make a decision or apply some logic

§  Use Case documents

the acHon of using the rule, i.e. the logic and

the reference to the rule used in the step :

Use Cases and UI

§  Use Case does not reference storyboards or mock-‐ups. Use Case is User Interface agnos>c §  User Interface and Use Cases are linked through storyboards §  Create a list of all viable use case scenarios:

§  Use Case describes all possible paths through the process §  Use Case scenario describes one specific path through the process

§  Create a storyboard for all use case scenarios: §  Relates Use Case scenario to corresponding order of mock-‐ups §  Explicitly refers to Use Case scenario by lis>ng the Use Case flows the scenario includes §  Mul>ple per Use Case – need to create for majority of viable scenarios

use$cases,$business$rules,$data$and$user$interface$ mockups… ·...

Documents