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.
When creating a business use case, the focus of the analysis should be from the outside in. This is to say that the Business Use Case should be determined as the response to some event triggered from outside the department (e.g. A student submits registration request to the registrar, a student pays their bill or a customer requests equipment for an event from the MRC). Each of these events should have a standard response from the Business Unit and by examining the response from the perspective of the outside entity, it becomes clearer how to partition the work within the system to maximize the efficiency and success of the overall process.
Another important factor in examining things from an outside perspective is that it reduces the chance of creating a "System" in a vacuum or perpetuating inefficient/legacy thinking into the next iteration. By thinking of the system from this higher, business process standpoint it is possible to question "Why do we do it this way?" and make potential improvements to the whole process not possible in a product-centric requirements gathering/analysis.
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.
- Faculty Fills Out the Scanning Request Form
- Is the form filled out completely?
- Yes - Proceed to Step 2
- No - Student requests more information from the Faculty and proceeds to step 1
- Student logs the incident in MI6
- What format does the faculty want the finished product in?
- PDF - Student scans document using Adobe Acrobat Professional
- Word or Excel - Student scans document using Omnipage
- JPG, GIF or TIFF - Student scans images using using Photoshop
- Student saves the resulting files.
- Student emails the files to the Faculty or saves them in the network folder the Faculty listed on the Scanning Request form.
- Student returns the originals through intra-campus mail.
- Student closes MI6 incident.
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.
A few user stories within the scope of the CNS Helpdesk tracking system could be:
- A Helpdesk Employee can search for open calls
- A customer can look up the status of their call.
- A customer can submit a new question.
- A Helpdesk Employee can change the status of a call.
- A customer will be notified of status changes to a call.
Notice that all of these User stories are very technology agnostic. That is to say that they do not specify exactly HOW a customer can look up the status of their call. This requirement could be implemented with a standard web-browser interface, an interactive touch screen around campus, or a phone-in interface. All user stories should remove the specifics of technology as much as possible from the description. This allows for the requirements analysts and designers to be as creative as possible. It also reduces the chance of creating a system that is so tied to a specific technology that it becomes quickly out of date.