...
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.