How to Gather Really Great Requirements

Brian Melville, MBA, PMP, CSM

IIBA Sacramento Valley Chapter

September 19, 2019

About me

I love to learn

I enjoy making things simple

I value efficiency

I like consulting

I try to be agile

I love to teach

I’m optimistic

I create positive change in people and organizations

How this works

Thirteen steps for gathering great requirements

But we learn by doing

So, in less than 60 minutes, lets practice the most important steps in Business Analysis

Ready, Set, Go!

I C U

V I S I O N

C E N T E R

Dr. Kim Wu OD

I C U V I S I O N

C E N T E R

• Eye examinations• Prescribe glasses and contacts• Sell lenses, frames and contacts

I C U

V I S I O N

C E N T E R

Dr. Kim Wu OD

Dr. Lisa Grantham OD

I C U

V I S I O N

C E N T E R

The Optical Staff

I C U

V I S I O N

C E N T E R

The Office Manager

The Office Assistants

Concerns

Dr. Wu is concerned with the number of errors in the ordering

process which causes customer dissatisfaction when their eyewear

is not ready when promised.

The opticians want immediate access to exam results without

waiting for the doctors to finish their updates and release the

chart.

The office staff wants to independently handle customer

questions about when glasses will be ready for fitting.

Current Process

The office currently uses a paper-based system for

charting eye exam results.

A part of the exam results are passed on to the

Opticians so they can help the patient order

appropriate lenses and frames or contact lenses.

After the patient has left, the Optician will place the

order using the lab’s online order entry system.

Options

Dr. Wu is interested in buying an optical office management

system that will automate the interaction between Optometrists,

the Opticians, the office staff, and the labs that make the glasses

and contacts.

However, there are many types of systems to choose from. There

are pre-built systems that automatically collect data from the

testing equipment, track patients and appointments, and

interface with the labs.

Other development companies specialize in custom applications

for Optometrists.

1

Ownership

Dr. Kim Wu OD

Dr. Lisa Grantham OD

2Business Case

Help your customer understand what they want and why?

Help your project owner write:

1. The business case in 1-2 sentences Why does she want to do this and what will she gain?

If you have a few more minutes, convert it into a Project Charter

2. How to measure success A few SMART Objectives

3. Constraints Time Money People Untouchables

4. In-Scope & Out of Scope

3Stakeholders

Who will be affected by the project

1. Create a stakeholder list including the following people or groups:

Direct

Optometrists

Opticians

Office Staff

Indirect

Labs

Patients

4Context Diagram

1. Meet with your stakeholders and draw a context diagram (I usually draw a data flow diagram on the white board)

2. Identify the people, organizations and systems (external entities) that touch the current or proposed system.

3. Identify and label the inputs and outputs from the system to these groups

5Process Flows

1. Meet with your stakeholders and draw their current (as-is) business process flow. I usually just use rectangles and arrows.

2. Then highlight with a different color pen what will be different in the future (to-be) business process.

The more people you have, the longer this can take because everyone sees the process differently and no one sees the whole picture. Coming to a common understanding is often the most valuable part of the whole project.

6Capture

Requirements

User Story

As a (user-type) ,

I want (to be able to, the system to, etc.)

so that ___________.

7Write

Requirements

The requirements belongs to the project owner; the business analyst only assists in their discovery

1. Write the requirements in a format that your customer will recognize and understand.

2. Organize them so they make sense By function By organizational unit Sequential business process Most important to least

3. Requirements be further subdivided or labeled as: Functional (things the system does) Non-functional (like performance) Technical (like security) Transitional (temporary requirements like converting data)

8Screen

Mock-ups

1. Use screen mock-ups to help your customers imagine how they will use the system.

These can be created using: Whiteboard Paper and pencil PowerPoint Word Visio or other quick drawing tools

Don’t spend extra time to make these documents pretty. These mock-ups are temporary deliverables that only exist to clarify requirements and improve the design.

Prioritize

Invite your customer to play a game that will help you prioritize the most important requirements.

1. Ask your business owner to invite key stakeholders to be his advisors for this activity

2. Make a set of MoSCoW cards (M, S, C, W) for each participant

3. Have the Project Owner read the requirement and ask everyone to raise the card that describes the appropriate priority.

4. If they are different (and they will be) she can ask for clarification

5. The team can re-vote as many times as needed, but the project owner ultimately decides.

6. The exercise can go further by having the teams force rank the requirements within each category (M, S, C, W)

Summary

1. Owner Who cares?

2. Business Case About what?

3. Stakeholders Who else cares?

4. Context Diagram

5. Process Flow

6. Capture Requirements

7. Write and Organize

8. Screen mockup

9. Review & Approval

10. Prioritize

11. Technical Review

12. Procurement

Review

13. Traceability

Thank you!

Brian Melville

btmelville@gmail.com

linkedin.com/in/brianmelville

Appendix

Detailed Step-by-Step

Instructions for Gathering

Great Requirements

1

Ownership

1. Who owns the project? Who cares?

Who hates the problem?

Who has the most to gain from the solution?

2. Make sure they are on board Will they spend time to plan for it?

Will they provide resources?

Will they pay for it?

3. Get commitment for a project owner and an executive sponsor Without at least one of these, you don’t have a project

Until you have both, the project is likely to fail

2Business Case

Help your customer understand what they want and why?

Help your project owner write:

1. The business case in 1-2 sentences Why does she want to do this and what will she gain?

If you have a few more minutes, convert it into a Project Charter

2. How to measure success A few SMART Objectives

3. Constraints Time Money People Untouchables

4. In-Scope & Out of Scope

3Stakeholders

Who will be affected by the project

1. Create a stakeholder list including the following people or groups:

Users Beneficiaries Subject Matter Experts Builders Bill Payers Maintainers Complainers

2. Analyze their level of involvement

Responsible, Accountable, Consulted, Informed (RACI) Their influence on the solution The impact of the solution on them

4Context Diagram

1. Meet with your stakeholders and draw a context diagram (I usually draw a data flow diagram on the white board)

2. Identify the people, organizations and systems (external entities) that touch the current or proposed system.

3. Identify and label the inputs and outputs from the system to these groups

5Process Flows

1. Meet with your stakeholders and draw their current (as-is) business process flow. I usually just use rectangles and arrows.

2. Then highlight with a different color pen what will be different in the future (to-be) business process.

The more people you have, the longer this can take because everyone sees the process differently and no one sees the whole picture. Coming to a common understanding is often the most valuable part of the whole project.

6Capture

Requirements

Ask your stakeholders what they want

Interviews

JAD Sessions

Surveys

WebEx

Brainstorming

Business Process Analysis

7Write

Requirements

The requirements belongs to the project owner; the business analyst only assists in their discovery

1. Write the requirements in a format that your customer will recognize and understand.

2. Organize them so they make sense By function By organizational unit Sequential business process Most important to least

3. Requirements be further subdivided or labeled as: Functional (things the system does) Non-functional (like performance) Technical (like security) Transitional (temporary requirements like converting data)

8Screen

Mock-ups

1. Use screen mock-ups to help your customers imagine how they will use the system.

These can be created using: Whiteboard Paper and pencil PowerPoint Word Visio or other quick drawing tools

Don’t spend extra time to make these documents pretty. These mock-ups are temporary deliverables that only exist to clarify requirements and improve the design.

9Review & Approval

The requirements belongs to the project owner; the business analyst only assists in their discovery

1. Meet with your customer (and select stakeholders) to present and explain the draft requirements.

2. Allow them time to understand and make corrections.

3. Ask for their approval that the requirements reflect their needs and wants.

10Prioritize

Invite your customer to play a game that will help you prioritize the most important requirements.

1. Ask your business owner to invite key stakeholders to be his advisors for this activity

2. Make a set of MoSCoW cards (M, S, C, W) for each participant

3. Have the Project Owner read the requirement and ask everyone to raise the card that describes the appropriate priority.

4. If they are different (and they will be) she can ask for clarification

5. The team can revote as many times as needed, but the project owner ultimately decides.

6. The exercise can go further by having the teams force rank the requirements within each category (M, S, C, W)

11Technical

Review

If you are building the solution in-house:

1. Meet with your technical team to review the requirements document.

Let them ask any questions to make sure they understand what the customer needs and wants

They will likely have suggestions for improving the requirements. Express appreciation and accept their ideas when it makes sense (even if it means going back and getting approval from your customer). Remember, any defect corrected now costs much less than fixing it later.

2. Be available to help them as they develop their estimates. Estimating brings up lots of questions about how the solution will actually be built. And keep communicating ideas and changes with your customer.

12Procurement

Review

If you are going out to bid to find a vendor:

1. Meet with your procurement team to review the

requirements document.

Let them ask any questions to make sure they

understand what the customer needs and wants

They will be looking at the rquirements from the

perspective of vendors and they may request they

be reformatted to fit their needs.

Prioritization is very important, since no COTS

solution will meet all your customer’s needs. And it

is very expensive to maintain customized software.

13Traceability

Maintain a Requirements Traceability MatrixThere are tools available, but you can easily use a spreadsheet.

Include the following columns showing where the requirement came from:

Author

Source

Owner

Include the following columns to ensure that the requirement doesn’t get lost or accidently eliminated:

Designed

Developed

Tested

Implemented

Documented

The RTM reduces value leakage and allows for communication with the requirement owner whenever there is a possible change to their requirement. But the documents don’t communicate, Business Analyst do.