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