Upload
others
View
4
Download
0
Embed Size (px)
Citation preview
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
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.