Requirements Elicitation Techniques

  • Requirements Elicitation

Lecture 11 focuses on specific elicitation techniques for gathering system requirements.

Specific Elicitation Techniques

  • Interviews: Direct discussions with stakeholders to understand their requirements.

  • Scenarios: Developing stories that describe how a system might be used.

  • Observations and social analysis: Observing people at work to understand actual work processes.

  • Requirements reuse: Reusing requirements from existing systems to save time and effort.

Interviews

  • Requirements engineers or analysts discuss the system with various stakeholders.

  • Aims to build an understanding of stakeholder needs.

  • Can be less effective for understanding application domains and organizational issues due to terminology and political factors.

Types of Interviews
  • Closed interviews:

    • The interviewer seeks answers to a predefined set of questions.

  • Open interviews:

    • No predefined agenda.

    • The interviewer discusses openly what stakeholders want from the system.

Interviewing Essentials
  • Essential #1:

    • Interviewers should be open-minded.

    • Avoid preconceived notions about requirements.

    • Provide stakeholders with a starting point for discussion (e.g., a question, a requirements proposal, or an existing system).

  • Essential #2:

    • Interviewers must be aware of organizational politics.

    • Real requirements might not be discussed due to political implications.

    • Example:

      • Stated Requirement: "The marketing and sales teams should have access to customer data."

      • Unstated Political Requirement: The IT department controls data access and is reluctant to grant full access due to internal conflicts over ownership and security concerns.

Interview Steps
  • Prepare

  • Conduct

    • Opening

    • Body

    • Closing

  • Follow through

Prepare for the Interview
  • Before developing questions:

    • Define the purpose and objectives of the interview.

    • Determine whether the interview should be conducted by one person or a team; define roles for team members.

    • Contact the interviewee to arrange the time, place, and logistics; outline the purpose and format.

    • Obtain background information.

  • After contacting the interviewee:

    • Develop the interview guide.

      • List the name and title of the interviewee and the date of the interview.

      • List questions in order, moving from general to specific.

      • Include open questions to elicit essay-type responses (e.g., "Describe…", "Tell me…", "How…").

      • Include closed questions to obtain specific information (e.g., "Who?", "How much?", "Where?").

Conduct the Interview
  • Opening:

    • Establish rapport and build trust and credibility.

    • Make eye contact.

    • Shake hands.

    • Introduce yourself (and your team); provide information about roles in the interview process.

    • Clarify purpose, timeframe, and key objectives.

    • Transition to the core of the interview by leading into the first question.

  • Body:

    • Follow the interview guide while asking questions.

    • Use probes to follow up on responses.

    • Be flexible and open-minded.

    • Listen actively.

    • Monitor voice and body language.

    • Identify the interviewee’s main concerns.

    • Maintain rapport.

    • Take accurate notes.

    • Use silence and pauses effectively.

    • Ask for and obtain relevant documentation.

    • Ask “catch-all” questions at the end.

  • Closing:

    • Summarize findings and link to the purpose.

    • Answer any questions the interviewee has.

    • Determine and agree on the next steps.

    • Set the next meeting, if necessary.

    • Thank the interviewee for their input and time.

Follow Through
  • Immediately after the interview, fill in the notes; jot down impressions and important ideas.

  • Review any documentation received from the interviewee.

  • Write an interview report, if necessary.

  • Follow up on leads obtained during the interview.

    • Contact other potential interviewees.

    • Research other data sources.

  • Follow up on agreed-upon next steps.

  • Send a thank-you note to the interviewee, if appropriate.

Listening

  • The art of listening is crucial.

  • Impress clients by actively listening and giving due attention to what they are saying.

  • Requires effort on the part of the interviewer.

Listening Steps
  • Hear

  • Interpret

  • Respond

  • Evaluate

Hear the Message
  • Listen to learn as much as possible to inform the response.

  • Give the speaker undivided attention; avoid waiting for a turn to speak.

  • Concentrate on the message, not the person.

  • Do not interrupt.

  • Tune out distractions such as noises, wandering thoughts, and emotional reactions.

  • Suspend judgment until all facts are heard.

  • Take notes on the speaker’s key points, if appropriate.

  • Learn to manage emotional filters, personal blinders, and biases that can prevent accurate hearing.

Interpret the Message
  • Observe the speaker’s nonverbal cues (gestures, facial expressions, and tone of voice) and factor them into the interpretation.

  • Listen for the attitudes and motives behind the words.

  • Listen for the speaker’s needs and wants.

  • Put the message in a broader context.

  • Integrate what is heard with existing knowledge about the speaker or subject.

Nonverbal Response to the Message
  • Make eye contact.

  • Nod affirmatively.

  • Use facial expressions and gestures to indicate attentiveness.

Verbal Response to the Message
  • Ask questions and probe to get more specific information and ensure understanding.

  • Rephrase the message using different words to check the meaning.

  • Make empathetic remarks to acknowledge understanding of the speaker’s feelings without offering opinions or judgment.

Evaluate the Message
  • Identify the main point of the message and its supporting evidence.

  • Clarify facts, perceptions, and opinions.

  • Distinguish between fact and opinion.

  • Group facts in like categories and logical order (importance, chronology).

  • Base opinions on facts.

  • Use the total message – the needs, the context, and the content – to follow through on what is heard.

Brainstorming

  • Also know as facilitated application specification technique (FAST).

  • It's a group activity.

  • All members are equal.

  • Off-site meeting location is preferred.

  • Brainstorming is a group-based elicitation technique used to generate creative ideas and identify potential requirements in a short period.

  • It is particularly useful when stakeholders are unsure of their needs or when exploring innovative solutions.

Steps to Conduct Brainstorming
  • Define the Problem/Objective

    • Clearly state the goal of the brainstorming session (e.g., "Identify key features for a new online learning platform").

  • Assemble a Diverse Group of Stakeholders

    • Include end-users, business analysts, developers, project managers, and other relevant stakeholders.

  • Set Ground Rules

    • Encourage open thinking (no idea is too silly).

    • Avoid criticism or evaluation during idea generation.

    • Keep the session time-bound (e.g., 30–60 minutes).

  • Generate Ideas

    • Use different brainstorming techniques:

      • Free Writing (everyone writes ideas independently).

      • Round Robin (each participant shares one idea at a time).

      • Mind Mapping (group visually organizes ideas).

  • Categorize and Prioritize Ideas

    • Group similar ideas and identify high-priority requirements.

  • Document Results

    • Record all ideas and finalize potential system requirements.

Scenarios

  • Stories explaining how a system might be used.

  • Should include:

    • A description of the system state before entering the scenario.

    • The normal flow of events in the scenario.

    • Exceptions to the normal flow of events.

    • Information about concurrent activities.

    • A description of the system state at the end of the scenario.

  • Examples of interaction sessions describing how a user interacts with a system.

  • Discovering scenarios exposes possible system interactions and reveals required system facilities.

Scenarios and Use-Cases
  • The term use-case (i.e., a specific case of system usage) is sometimes used to refer to a scenario.

    • A use-case is a scenario.

    • A scenario is a collection of use-cases. Therefore, each exceptional interaction is represented as a separate use-case.

    • A use-case is a collection of scenarios.

Observation and Social Analysis

  • People often find it hard to describe what they do because it is so natural to them.

  • Sometimes, the best way to understand it is to observe them at work.

  • Ethnography is a technique from the social sciences which has proved valuable in understanding actual work processes.

  • Actual work processes often differ from formal, prescribed processes.

  • An ethnographer spends an extended time observing people at work and building up a picture of how work is done.

Ethnography Guidelines
  • Assume that people are good at doing their job and look for non-standard ways of working.

  • Spend time getting to know the people and establish a trust relationship.

  • Keep detailed notes of all work practices. Analyze them and draw conclusions from them.

  • Combine observation with open-ended interviewing.

  • Organize regular de-briefing sessions where the ethnographer talks with people outside the process.

  • Combine ethnography with other elicitation techniques.

Requirements Reuse

  • Reuse involves taking requirements developed for one system and using them in a different system.

  • Saves time and effort, as reused requirements have already been analyzed and validated in other systems.

  • Currently, requirements reuse is an informal process, but more systematic reuse could lead to larger cost savings.

Reuse Possibilities
  • Where the requirement is concerned with providing application domain information.

  • Where the requirement is concerned with the style of information presentation. Reuse leads to a consistency of style across applications.

  • Where the requirement reflects company policies such as security policies.

Prototyping

  • An initial version of a system which may be used for experimentation.

  • Prototypes are valuable for requirements elicitation because users can experiment with the system and point out its strengths and weaknesses. They have something concrete to criticize.

  • Prototyping will be discussed in a later lecture.

Summary

  • There are various techniques of requirements elicitation which may be used, including interviewing, scenarios, prototyping, and participant observation.

  • This lecture focused on different aspects of conducting interviews.

References

  • ‘Requirements Engineering: Processes and Techniques’ by G. Kotonya and I. Sommerville, John Wiley & Sons, 1998

  • Software Requirements: Objects, Functions, and States by A. Davis, PH, 1993