What Use Case to Use?
The Use Case is a standard tool in the BA toolkit, and like most tools they come in different shapes and sizes for different jobs.
During Business Analysis Planning it is important to identify the appropriate use case format for the project needs. At the high end we have a multi-page highly regulated requirements template. The base model is a single actor and basic flow. Between these is the textbook version with complex flows. This article looks at these use case formats and design influences to consider during your Business Analysis Planning.
Use Case Formats
- Simple Flow Use Case
- Complex Flows Use Case
- Highly Prescribed Use Case
Simple Flow use cases describe the interaction of a single actor along one basic flow. This format can be used as the starting point for a more complex effort, as a placeholder for planning purposes, or as the final deliverable for a simple project. This format is similar to a user story, with post conditions instead of benefits.
Complex Flow use cases include alternate flows, triggers, business rules, post and exit conditions. The degree of complexity should be determined by the stakeholder needs and perspectives. For business users the documentation must be readable so that they can follow and agree that you have captured their needs correctly. For the architects and developers, the details must be specific enough to translate into units of development. For the testing teams the documentation must provide clear inputs and outputs of success so that they can formulate test cases.
Highly Prescribed use cases have a multi-page template with approved instructions to complete each section. There are projects which require such discipline, but I have also worked on projects where the template became the end rather than the means, and the degree of detail slowed down the project and produced wasteful documentation.
Design Factors
Use Case formats will be influenced by:
- Funding model
- Requirements complexity
- Rate of change
- Regulatory environment
- Project methodology
- Project phase
- Build or Buy
Funding Model
Organizational funding models may impose a need for provide for detailed requirements well in advance of the project development phase, in order to compete for funding. A use case that identifies all potential steps, alternate flows, business rules and usage estimates can be useful to assist with cost estimates. Tight funding oversight models will ask for more detailed documentation than open models.
Requirements Complexity
Retail web pages for major sellers can be large and complex because of the product offerings, but the system requirements themselves are repetitive and reusable and changes easily delivered with a user story or simple use case.
A new system with complex requirements needs more detailed documentation than an informational web page. A new system with many business rules needs detailed documentation and requirements tracing to ensure proper coverage. Integrated systems need a degree of rigor ad traceability to ensure that front end changes do not break upstream or downstream systems such as integrated re-order or delivery systems.
Rate of Change
The retail web pages are repetitive but require rapid changes to meet demand and marketing plans. The requirements documentation cannot stand in the way of rapid delivery.
From another perspective, detailed requirements documentation that can be reviewed in the change management process can help slow down a rush delivery and prevent embarrassing releases.
Regulatory Environment
Systems that are governed by external regulations need detailed requirements documentation that can be read and understood by multiple stakeholders so that all affected parties are able to understand and approve the inputs and outputs of the system to be delivered. Systems that collect personal information must be able to demonstrate that the correct information is being captured and the appropriate security will be in place to protect this information from misuse.
Project Methodology
Waterfall projects tend to require detailed requirements. Agile projects prefer minimal documentation, user stories, and simple use cases if any.
Project Phase
Documentation detail may expand or contract during the project phases. As discussed above, projects may require detailed requirements documentation for early feasibility and cost analysis exercise, but they may then drop down to user stories for the development and delivery. Other projects may require only simple use cases to outline a concept, and then expand on the use case flows and details during the requirements phase.
Build or Buy
If the project includes a build or buy decision, then a simple use case format that can be transferrable to a matrix of acceptance and evaluation criteria will be most useful when comparing solution options.
Summary
Use Cases are a valuable business analysis tool that come in multiple flavors. As part of the Business Analysis Planning step the Business Analyst should identify the degree of rigor and detail that the project and the stakeholders require and select the appropriate use case format(s) to use during the project.