In 2019, members of the Business Analysis Community of Practice identified their most used business analysis methods and gathered in workshops to share their knowledge about them. We continue to add to these pages and hope you'll contribute too!
Methods are a "toolbox" of common ways to do business analysis, known to help teams deliver value. Any team can get started with a method, even without a dedicated business analyst. Teams benefit from having a variety of tools available, and the more teams use similar methods, the more easily we can communicate across teams at the UW.
Teams make quite different choices of methods depending on their needs and experience. We've asked members of the community to share their perspectives on selecting methods; we'll continue to link these below.
Methods in context
How do various methods fit together in a typical business analysis effort? In 2019, the BACoP collaborated to draft two lifecycles for different kinds of business analysis work:
Perhaps the most fundamental method of business analysis is to gather information from people – their context, needs, and priorities. Traditionally called "requirements elicitation," this can include meeting with individuals or facilitating groups.
Even for projects focused on delivering a technology tool, understanding the business process that the tool will be used in is essential. A wide range of techniques, standards, and tools exist for documenting business processes.
This method provides systems context for a change – at a high level, what systems are involved and how do they interact?
Use cases focus on people – why and how they will interact with a system, product, or service.
A user story is a short description of functionality that someone wants, and why. Agile teams organize work around user stories from initial planning through testing.
All business processes and systems rely on information and data, which business analysis helps define. Data models can be very high level or very detailed (conceptual, logical, or physical).
Requirements describe what is needed or desired from a solution, as the basis for prioritizing what to work on, comparing alternative solutions, doing design, and validating a solution.
A product roadmap helps you, your team, and your customers be clear about where your product or service is headed and what changes are coming when.
By sketching what a software product might look like at different levels of fidelity, wireframes and prototypes help you clarify what is really needed and feasible to build.
A business model canvas is a tool for facilitating discussion of how an organization works – who it serves, and how it does that. It's useful when imagining or defining a new program or service, or for clarifying an existing one.
Perspectives from our community on choosing from among the business analysis methods:
- Coming soon
Thank You!The following BACoP members volunteered as editors on these references:
- Carl Gnome (UW Facilities) - Systems Diagrams
- Rebecca Gutierrez (UWC^2) - Data Models
- Linda Hornung (UW-IT CSS) - In-Person Elicitation, Interviews, and Workshops
- Jodi McKeeman (UW-IT Academic Services) - Product Roadmaps
- Piet Niederhausen (UW-IT EA) - Business Process Diagrams and Models, Use Cases, User Stories, Business Model Canvases
- Cara VanDyke (UW-IT Academic Services) - UI Wireframes and Prototypes
- Don Wilcox (UWFT) - Requirements Lists and Specifications
The following BACoP members contributed to these references in our workshops:
- Diane Branczeisz (ISC)
- Anne P. Danahy (UW-IT)
- Mary Friedmar (UW-IT IM)
- Will Giltner (OPB)
- Cole Guggenbickler (Housing & Food Services)
- Laura Jaurequi (UW-IT Infrastructure)
- Jennifer Lail (ISC)
- Karen Matheson (ISC)
- Jacob Morris (UW-IT)
- Anthony Nguyen (UW Facilities)
- Christine Noyes (Graduate School)
- Amee Patel (UW Facilities)
- Matt Portwood (UW-IT: BI Team)
- Tariq Rathore (UWFT)
- Stepanka Sirotek (Finance)
- Elise Wallick (UW-IT Infrastructure)
- Stephanie Wang (UW-IT Academic Services)
- No labels