Business Use Cases
Business Use Cases differ from the standard Use Case in that they do not describe a set of work by a system so much as a departments response to a Business Event.
...
The final business use case should take into account acceptable variations in the workflow. If there are multiple paths to the same end result for the outside entity, then those should be captured within the business use case.
Creating a Business Use Case
Business Use Cases should comprise a single body of work describing how a department responds to an external request. These are most often documented using workflow diagrams. However, it is possible to describe the basic flow of work using a set of steps with branches to the work represented by subsections. Below is an example of a simplified workflow for the ITS Faculty Lab responding to a faculty request for scanning.
...
While this document lacks some of the ease of flow that a standard workflow diagram has, it can serve as a starting point as part of the discussion between the customers and the requirements analyst. The analyst should take these documents from the customer and begin diagramming them into standard workflow diagrams, and using them to ask more probing questions about the workflow. All information should be used to immediately feedback to the customer some kind of diagram or rephrased explanation to ensure that both sides of the discussion are talking about the same process.
User Stories
Business Use Cases are a great way to collect the over all picture of how a department responds to their customer's requests. However, the detail of the work can sometimes get a bit lost in that wide-angle view. To help combat that loss of detail, analysts should combine the Business Use Case technique with the gathering of User Stories. User Stories are small, single events within the scope of the project.
...