flying an analytical kite

Kirk Bridger B.Sc.Functional AnalystMcKesson Medical Imaging Group

Flying an Analytical KiteCapturing Business-Level Requirements in a Software Engineering Process

04/12/23 2

Learning Points

Discuss the value of formally documenting business-level requirements.

Understand how business-level requirements translate into system-level requirements.

Identify potential challenges to introducing business-level requirements within your organization.

04/12/23 3

Overview

Introductions Documenting Business Requirements Our Methodology

─ Cockburn’s Sea Metaphor

─ Specific Approach and Definitions

Methodology Challenges Organizational Challenges Future Directions

04/12/23 4

Introductions

My name is Kirk Bridger─ McKesson’s Medical Imaging Group (MIG)─ Picture Archiving and Communication System (PACS)

product─ Technology management and support background

I am a Functional Analyst─ Product Management Department─ Responsible for Business Requirements

Now please raise your hand if …

04/12/23 5

Overview

Introductions Documenting Business Requirements Our Methodology

─ Cockburn’s Sea Metaphor

─ Specific Approach and Definitions

Methodology Challenges Organizational Challenges Future Directions

04/12/23 6

Role-play

Imagine, if you will, that we are all sitting in a Change Control Board meeting.

We are reviewing a requested feature for our patient barcode wristband product:

PatientMatch

04/12/23 7

Background - Patient Wristbands

Barcoded wristbands are commonplace in the hospital setting

Considered a vital practice by most hospitals and healthcare regulatory bodies

Allows quick and easy patient identification

Aimed at improving patient safety by reducing frequency of medication errors

04/12/23 8

Our Product: PatientMatch

PatientMatch can─ Track wristbands using unique

internal IDs─ Print new wristbands

• We sell the printers and consumables

─ Interface with Electronic Medical Record (EMR)

• Track what treatment was given, when, by whom, etc

Care providers use our product for─ Point of care scanning of the patient, drugs, and supplies─ Confirming patient identity, appropriate supplies, and drugs dispensed─ Automatically tracking patient-drug dispensing times

04/12/23 9

Change Request Under Review

“A local hospital administrator has asked if we

could provide them with a means to expire or

cancel wristband IDs.”

They estimate they will run out of wristband IDs within a year Would like to expire or retire IDs older than 7 years

Systems Architect Comments: Next release in 9 months moves to a 64 bit database Virtually unlimited wristband IDs if they upgrade Re-using wristband IDs could introduce patient safety risk

04/12/23 10

Question to the Audience

Do you think we should accept this change request, and if so with what priority?

04/12/23 11

What Just Happened

We made a decision on system scope We did so without being certain of the

repercussions in the business domain

Consider:

How rare of an occurrence is this in software development?

04/12/23 16

Real Life Scenario Summary

Patient receives incorrect wristband when admitted Mistake is lost in hustle bustle of the ward Incorrect test results sent to unlucky patient’s EMR Potentially fatal “treatment” prescribed for unlucky

patient Staff diligence discovers the error before it is too late

04/12/23 17

Change Request Revisited

“A local hospital administrator has asked if we could provide them

with a means to expire or cancel wristband IDs.”

Imagine if you had access to business requirements with titles like these:

Might your evaluation of the change request change with the additional domain insight?

Might your confidence in your decision be different?

Use Cases

Admit patient to hospital

Transfer patient to ward

Business Rules

Each patient’s wristband uniquely identifies them within the hospital

At least two patient identifiers are used when providing care, treatment, and services

Data retention expectations

04/12/23 18

Can A Good BA or SME Suffice?

Why not just rely on a BA or subject matter expert?─ May be hard to find the right skill set─ Relies on people-based knowledge sharing

• Bottleneck• Risk management

─ Do stakeholders know when to ask for clarification? Resource management and prediction can be difficult

Question:If the business workflows and requirements are a vital part of product

design, then why are they not captured in the product’s requirements documents?

Answer:They should be!

04/12/23 19

Documented Requirements - Summary

Documented business requirements:─ Mitigate people-based risk

─ Allow proper impact analysis

─ Provide business knowledge to all stakeholders

─ Support strategic efforts via early analysis

Business knowledge is vital to system design throughout software lifecycle

04/12/23 20

Overview

Introductions Documenting Business Requirements Our Methodology

─ Cockburn’s Sea Metaphor

─ Specific Approach and Definitions

Methodology Challenges Organizational Challenges Future Directions

04/12/23 21

Our Goals

We wanted something that would help increase our ability to─ Address customer’s real-world problems

─ Leverage business and domain knowledge when making system and design decisions

─ Determine “Did we build the right product?”

04/12/23 22

Our Approach

Formally instantiate business-level requirements in our Requirements Management Plan─ Dedicated resources

• Product Management describes the Business

• Engineering describes the System

─ Specific artifacts

• Leverage Cockburn’s Sea-level Metaphor

• Define business requirement artifacts

04/12/23 23

Cockburn’s Sea-level Metaphor

“The sky goes upwards for a long distance above sea level, and the water goes down for a long distance below sea level, but there is

only one level where sky and sea meet: at sea level.

The same holds true for goals. There are many goal levels above the user goal and many below, but the user goals are important

ones to write.”

04/12/23 24

Cockburn’s Goal Levels Explained

3 goal levels─ Summary

─ User

─ Subfunctions

Ask “Why” to raise your goal level

Ask “How” to lower your goal level

04/12/23 25

Example Goal Level Continuum

04/12/23 26

Categorizing The Requirement Levels

04/12/23 27

Business Requirements (Kite Level)

Business-level requirements─ Capture business workflows─ Identify business policies, regulatory information, and environmental factors─ Capture user information and organization specifics─ Helps define product goals and strategic direction─ Include usability analysis

Formal Requirements─ Structured─ Evaluation criteria─ Tracing model

Examples─ Business Problems─ Business Briefs─ Business Use Cases─ Business Rules─ Personas

04/12/23 28

System Requirements (Sea Level)

System-level requirements─ Elaborate on Business Requirements

─ Define necessary software details

─ Precisely define what to develop and test

─ Focus development effort on customer needs

─ Include usability design

Examples─ System Use Cases

─ Nonfunctional Requirements

─ Functional Requirements

─ UI Design Documents

04/12/23 29

Where The Sea Meets The Sky

Natural progression from business to system level requirements

─ Define requirements at increasing levels of detail

Maintain tight coupling between the two artifact levels

Requires cooperation─ Avoid “throwing it

over the fence”

04/12/23 30

Example Transitions - BUC

Business Use Case to System Use Case

─ Each line in a BUC flow could be a potential System Use Case

─ Explicitly crosses to a different goal level

04/12/23 31

Example Transitions - BR

Business Rules describe “the way things are”

─ Naturally lead to Nonfunctional and Functional requirements

─ Explicitly crosses to a different goal level

04/12/23 32

Planned-For Problems

Potential problems that were explicitly addressed and avoided via implementation planning and training─ System Details in Business Artifacts

• Avoid unnecessary system constraints

─ Analysis Paralysis

• Too deep too early

04/12/23 33

Our Approach - Summary

Cockburn’s metaphor─ Easy to incorporate and apply

─ Pertinent

─ Learnable

Business requirements lead fluidly to system requirements

Some problems can be avoided if considered ahead of time

04/12/23 34

Overview

Introductions Documenting Business Requirements Our Methodology

─ Cockburn’s Sea Metaphor

─ Specific Approach and Definitions

Methodology Challenges Organizational Challenges Future Directions

04/12/23 35

Methodology Challenge 1

Where is sea level?

04/12/23 36

Methodology Challenge 2

Is it kite or cloud?

04/12/23 37

Methodology Challenge 3

Yes … but what’s new?

04/12/23 38

Methodology Challenge 4

Where does usability fit in?

Image courtesy of Hatti Jahunen

04/12/23 39

Methodology Challenges - Summary

Plan ahead for challenges Work towards satisfying the needs of the project,

not the process Flexibility is key when instituting methodology

changes─ Personal

─ Professional/Organizational

04/12/23 40

Overview

Introductions Documenting Business Requirements Our Methodology

─ Cockburn’s Sea Metaphor

─ Specific Approach and Definitions

Methodology Challenges Organizational Challenges Future Directions

04/12/23 41

Organizational Challenge 1

Even more analysis ?!??

Project timeline looks longer

04/12/23 42

Organizational Challenge 2

Not everyone will want to cooperate─ Current SMEs

• “Why are you writing down my thoughts?”

─ Participants and stakeholders

• “If it ain’t broken, don’t fix it”

04/12/23 43

Organizational Challenge 3

Fundamental process changes should be considered as organizational changes

Manage appropriately

04/12/23 44

Organizational Challenges - Summary

Don’t expect everyone to be on board Work to ensure root causes of complaints are

addressed Requirements Management touches a lot of

people – change it with care, attention and preparation

04/12/23 45

Overview

Introductions Documenting Business Requirements Our Methodology

─ Cockburn’s Sea Metaphor

─ Specific Approach and Definitions

Methodology Challenges Organizational Challenges Future Directions

04/12/23 46

Future Directions

Usability Personas Further streamlining Better estimates using

Business Artifacts Adaptation to various

project types─ Strategic─ Tactical─ Integrations

04/12/23 47

Learning Points - Revisited

Discuss the value of formally documenting business-level requirements.

Understand how business-level requirements translate into system-level requirements.

Identify potential challenges to introducing business-level requirements within your organization.

04/12/23 48

Your “Next Day Back” Tool

What’s Old Is New Again!─ The tools you already use work perfectly within the

business realm

Examples─ Workflow/activity

diagrams

─ Use cases and use case diagrams

─ Actor/Stakeholder list

─ Context diagrams

─ UML or BPM

Go Fly Your Analytical Kite!

04/12/23 49

Conclusions

Documenting Business Requirements─ Benefits the entire organization─ Mitigates risks surrounding vital domain knowledge─ Supports an organization’s ability to understand the market and

their customer’s needs

Cockburn’s Sea Metaphor provides a useful means of approaching and capturing formal business requirements

Instantiating business-level requirements in an established requirements process is an important and substantial change for an organization

04/12/23 50

Questions or comments?

Comic courtesy of xkcd

Contact me at

Kirk.Bridger@McKesson.com