...
Each business event will have a use case associated with it. This use case is the business's response to the event. It will include a set of identifiable processes, data stored and retrieved, and any information communicated in and out of the business. Each Use Case should be a single event with almost no direct connection to any other Use Case, this allows different analysts to move along their avenues of inquiry without an overwhelming amount of communication constantly necessary.
Trawling for Requirements
The text provides several methods for gathering the requirements that make up the various use cases. They also provide several suggestions when each method they list can be best employed. Upon reading through the text, there are a few methods that jumped out as most likely to be applicable to Drew's situation.
Interviewing the Stakeholders
Interviews are the most common method of requirements gathering. The authors suggest that even without a fully prepared interview guide, it is important to send the customer an agenda so that the interviewee will have the chance to have needed material close by.
The other major suggestion on interviewing the Stakeholders is to actively involve the Stakeholders in actively building models and use cases and scenarios while engaged in the discussion. This allows them to correct any misunderstandings and incorrect assumptions by the designers.
The authors also caution against allowing ambiguous language passing into the actual requirements document. Patterns of speech and language can lead to several different interpretations. They suggest reading about the field of Neurolinguistic Programming with the text Introducing Neurolinguistic Proamming by Joseph O'Connor and John Seymour.
Apprenticing
While apprenticing is a highly work and time-intensive process, it can be very useful to learn about how a person actually does their work. As quoted from Hugh Beyer and Karen Holtzblatt in their text Contextual Design: Defining Customer-Centered System. Amazon.com "Nobody can talk better about what they do and why they do it than they can while in the middle of doing it"
An analyst practicing apprenticing sits with the customer and watches them do their work, diagramming it and occasionally asking questions as to "Why did you do that?" or "What does this mean?" or "How often does this happen?" And thus learns more about the full picture of what a customer really does and how it happens.
Essence of the Work
One of the interesting aspects of this text is how much they suggest divorcing the problem from any actual technology or solution. They make frequent references to getting to the Essence of the Work. The example they cite is using an ATM to withdraw money from an account. While there are a set of actions, such as using a bank card, typing a PIN, and such, the ESSENCE of the work is "Access your account and withdraw money from it" They suggest that by removing any potential solution from the requirements at this stage, you gain a level of flexibility and the chance for real innovation with your product design. The general rule in using this method of trawling is that
If a requirement contains the means of implementation, then it is a solution, not a requirement.
Innovative Products
The important aspects of this section are summed up as Don't rely on your stakeholders knowing exactly what they want. We as the requirements gatherers should be able to look beyond today's work and start to suggest improvements. Reducing the number of steps in a process for our customers or their customers, creating new connections between people and the work they do, even empowering the customers to do as much of the work for themselves as possible.
Business Use Case Workshops
Business Use Case Workshops are JAD-style workshops where the participants work with the Business Events mentioned earlier and design scenarios and processes to show the correct responses to the business events. These workshops use general discussion, business rules, process diagrams to help build low-fidelity prototypes to gather appropriate requirements.
Each workshop gathers information about the business use case:
- The desired outcome (NOT output, outcome) of the business use case.
- A set of scenarios that describe the work.
- Exception scenarios that describe what can go wrong and how to fix it.
- Alternative scenarios if there are allowed variations to the work
- An business or regulatory rules that apply
- The product use case - where the work is done by the designed product
- Characteristics (profiles) of likely users
- Low-fidelity prototypes so stakeholders can give immediate feedback about the analysts understanding of their work.