...

Commercializing Great Products with Design for Six Sigma

Safari Online Link

While this text is primarily concerned with the generation of software for commercial sale/use, the sections on preparing and conducting Guided Interviews are very appropriate.

...

The text recommends that the interview team all now begin brainstorming sets by each writing their set of questions for the project on post-it notes. The team should be keeping in mind using the general guidelines of Category, Current Situation or Today, and Where We Want To Be or Tomorrow. The table below is an example of that from the text.

The resulting post-its are organized onto a board or table together by groups and duplicates are eliminated. When possible similar questions may be combined to ensure that the interview is kept to a reasonable time frame. The goal it to have five or six large groups of questions, covering major areas where the customer needs to articulate their requirements.

The set of questions is then documented, and can be adjusted to match the customer being interviewed. While these questions cover the major goals of the interview, there will be some that can be dropped or new ones added as follow ups based on experience with the interviews.

Conducting the Interviews

The text recommends teams of three conduct the interviews. Team leaders actually asks most of the questions, one team member is the scribe to catch verbatim the customer's responses and the third team member is an observer/asks additional follow-up/probing questions.

Mastering the Requirements Process, Second Edition

Safari Online

The authors of this book suggest that the beginnings of Requirements Gathering should focus on delving into the work of the organization. That you should be focused on learning what the actors in the scenarios will do as a whole, and not just how they will work with an automated system. That by learning the scope of the work for the whole organization you will be better able to provide opportunities for innovation. They also feel that you can best target the needs of organization by partitioning the work and the use cases according to externally facing categorizations, not internal ones. Basically how do the Customers see the organization and where the business flows should go should drive the work instead internal structures.

Business Events and Use Cases

Business Events are events which drive the work. The authors suggest taking a step back from your business events to think about where and what the real event it. When a customer calls a helpdesk, that is the event, however the authors suggest that frequently designers and requirements gatherers will consider the logging of the call the event. This change in focus and divorcing the technology from the business events allows you to start thinking about the requirements from new perspectives and come up with innovative solutions.

The authors suggest building a set of business events for each of the major elements of work. These business events will allow you logically group together aspects of the work which the system is designed to support.

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.