Activity: Elicit Stakeholder Needs

Determine Sources for Requirements

Look for partners, users, customers, domain experts, and industry analysts who can represent your stakeholders. Determine which individuals you would work with to collect information, considering their knowledge, communication skills, availability, and "importance". These individuals will act as stakeholders of your project—in effect, an "extended project team". In general, it is better to have a small (2–5) group of people that can stay with you for the duration of the project. Also, the more people there are in your extended team, the more time it will take to manage them and make sure that you use their time effectively. These people do not work fulltime on the project—they typically participate in one or a few requirements gathering workshops in the inception and elaboration phases, and later on in review sessions.

Find a way to learn how others do what you are trying to do. If you are developing a software product, this would mean to gather competitive information. If you are developing a new version of an in-house information system, you need to schedule site visits to see how people are using the current system and find out what can be improved.

An important source is any existing descriptions of the organization in which the system is to be used. These could either be business models produced as described in the business modeling workflow, or any other form of business definition.

Gather Information

Interviews

A direct person-to-person interview technique requires that you have prepared a list of questions designed to gain an understanding of the real problems and potential solutions. To get as unbiased answers as possible, you need to make sure the questions you ask are context free. The context-free question is a high-level, abstract question that can be posed early in a project to obtain information about global properties of the user’s problem and potential solutions.

A context-free question is:

• Always appropriate.
• Formulated so that it helps you understand stakeholder perspectives.
• Not biased with solutions knowledge or your opinion of what the solution should be.

Examples of context-free questions used to find actors:

• Who is the customer?
• Who is the user?
• Are their needs different?
• What are their backgrounds, capabilities, environments?

Examples of context-free questions that help you understand business processes:

• What is the problem?
• What is the reason for wanting to solve this problem?
• Are there other reasons for wanting to solve this problem?
• What is the value of a successful solution?
• How do you solve the problem now?
• What is the trade-off between time and value?
• Where else can the solution to this problem be found?

Examples of context-free questions that help you understand requirements on the system or product to be built:

• What problem does this product solve?
• What business problems could this product create?
• What hazards could exist for the user?
• What environment will the product encounter?
• What are your expectations for usability?
• What are your expectations for reliability?
• What performance/precision is required?

Examples of context-free meta questions:

• Am I asking too many questions?
• Do my questions seem relevant?
• Are you the right person to answer these questions?
• Are your answers requirements?
• Can I ask more questions later?
• Would you be willing to participate in a requirements review?
• Is there anything else I should be asking you?

Examples of non-context-free questions are:

• Leading questions: "You need a larger screen, don't you?"
• Self answering questions: "Are fifty items about right?"
• Controlling statements: "Can we get back to my questions?"
• Too long and too complex: "I have a three part question, ..."

When you formulate a set of questions, you also should consider the following:

• Don't ask people to describe things they don’t usually describe.
• Don't ask questions that assume that users can describe complex activities. Example: tying your shoelace.
• In general, people can do many things they cannot describe.
• Empirical evidence - poor correlation.
• Ask open-ended questions.
• Avoid questions that begin with "Why…?", since such question can provoke a defensive posture.

When you conduct an interview session, think about:

• Don’t expect simple answers.
• Don’t rush the interviewee for answers.
• Listen, listen, listen!

Questionnaires

This is a widely used technique. You send out a list of questions to a select set of people, and have them answer and send them back to you. This allows you to reach a much wider range of people than if you do direct interviews, but you have less control of the results. You are not there to directly communicate with the person answering the questions to clarify any issues or misunderstandings. Questionnaires can be a very powerful tool, but they do not replace a direct interview. Also, an assumption is that relevant questions can be determined in advance, and that you can phrase them so that the reader hears them in the intended way.

Conduct Requirements Workshop

To conduct a requirements workshop, means to gather all stakeholders together for an intensive, focused period. A System Analyst acts as facilitator of the meeting. Everyone attending should actively contribute, and the results of the session should be made immediately available to the attendants.

The requirements workshop provides a framework for applying the other elicitation techniques, such as brainstorming, storyboarding, role playing, review of existing requirements. These techniques can be used on their own or combined. All can be combined with the use-case approach. For example, you can produce one or a few storyboards for each use case you envision in the system. You can use role playing  as a way of understanding how actors will use the system and help you define the use cases.

A facilitator of a requirements workshop needs to be prepared for the following difficulties:

• Stakeholders know what they want but may not be able to articulate it.
• Stakeholders may not know what they want.
• Stakeholders think they know what they want until you give them what they said they wanted.
• Analysts think they understand user problems better than users.
• Everybody believes everybody else is politically motivated.

The results of the requirements workshops are documented in one or several Stakeholder Needs documents. Provided you have good tool support, it is often good to allow the stakeholders to enter this information. If you have chosen to discuss the system in terms of actors and use cases, you may also have an outline to a use-case model.

Before the Workshop

The facilitator needs to "sell" the workshop to stakeholders that should attend, and to establish the group that will participate in the workshop. The attendees should be given "warm-up" material to review before they arrive. The facilitator is responsible for the logistics surrounding the workshop, such as sending out invitations, finding an appropriate room with the equipment needed for the session, as well as distributing an agenda for the workshop.

Conduct the Session

The facilitator leads the session, which includes:

• Giving everyone an opportunity to speak.
• Keeping the session on track.
• Recording the findings.
• Summarizing the session and working out conclusions.

Consolidate Results

After the requirements workshop, the facilitator (together with fellow system analysts) need to spend some time to synthesize the findings and condense the information into a presentable format.

Tricks of the Trade

The table below lists a collection of problems and suggested solutions that could come in handy for the facilitator. The solutions are referring to a set of "tickets" that may sound unnecessary to have, but in most cases turn out to be very effective:

Evaluate Your Results

Especially if you have conducted more than one requirements workshop, it is a good habit for the project team to walk through the results and:

• Make sure there is a priority given to each request.
• Make sure that there is information about what or who is the source of the request.
• Note and maybe clarify obvious inconsistencies between the requests.

The results of the requirements workshop need to be presented to a select set of customers or users in a review or follow-up session. In this session, you will identify if there are any issues that need to be clarified, which in turn means you will identify tasks that need to be completed, and assign people to those tasks.