Requirements Elicitation Techniques

Requirements Elicitation Techniques
Interviewing and questionnaires
   -Simple direct technique
   -Context-free questions can help achieve bias-free interviews
   -Then, it may be appropriate to search for undiscovered requirements by exploring solutions.
   -Convergence on some common needs will initiate a “requirements repository” for use during the project.
   -A questionnaire is no substitute for an interview.

Interview: Context free question
Goal is to prevent prejudicing the user’s response to the questions.
Examples:
Who is the user?
Who is the customer?
Are their needs different?
Where else can a solution to this problem be found?
Context-free questions also parallel the questions salespeople are taught to ask as part of a technique called “solutions selling.”
After context-free questions are asked, suggested solutions can be explored.

Interview: Show time
Establish Customer or User Profile
Assessing the Problem
Understanding the User Environment
Recap the Understanding
Analyst’s Inputs on Customer’s Problems
Assessing Your Solution (if applicable)


Requirements workshops
Technique: Requirements Workshop
   -The requirements workshop is perhaps the most powerful technique for eliciting requirements.
   -It gathers all key stakeholders together for a short but intensely focused period.
   -The use of an outside facilitator experienced in requirements management can ensure the success of the workshop.
   -Brainstorming is the most important part of the workshop.

Preparing for the workshop
   -Selling the workshop concept to stakeholders
   -Ensuring the Participation of the Right Stakeholders
   -Logistics
   -Try and prevent Murphy’s law
   -Includes travel, lighting, and even “afternoon sugar filled snacks.”
   -Warm-up materials
   -Project-specific information
   -Out-of-box thinking preparation

Braining Storming and idea reduction
   -Brainstorming involves both idea generation and idea reduction.
   -The most creative, innovative ideas often result from combining, seemingly unrelated ideas.
   -Various voting techniques may be used to prioritize the ideas created.
   -Although live brainstorming is preferred, web-based brainstorming may be a viable alternative in some situations

Storyboards
   -The purpose of storyboarding is to elicit early “Yes, But” reactions.
   -Storyboards can be positive, active, or inactive.
   -Storyboards identify the players, explain what happens to them, and describes how it happens.
   -Make the storyboard sketchy, easy to modify, and unshippable.
   -Storyboard early and often on every project with new or innovative content.

Use Cases
   -Use Cases, like storyboards, identify the who, what, and how of system behavior.
   -Use Cases describe the interactions between a user and a system, focusing on what they system “does” for the user.
   -The Use Case model describes the totality of the systems functional behavior.
   -Early stages: After you have an overview of the use cases, perhaps only by a phrase apiece, expand 10% of them in detail.
   -More later …


Role Playing
Technique: Role Playing – variant on use cases
   -Role playing allows stakeholders to experience the user’s world from the user’s perspective.
   -A scripted walkthrough may replace role playing in some situations, with the script becoming a live storyboard.
(Class-Responsibility-Collaboration (CRC) cards, often used in object-oriented analysis, are a derivative of role playing.)

Prototyping
   -Prototyping is especially effective in addressing the “Yes, But” and the “Undiscovered Ruins” syndromes.
   -A software requirements prototype is a partial implementation of a software system, built to help developers, users, and customers better understand system requirements.
   -Prototype the “fuzzy” requirements: those that, although known or implied, are poorly defined and poorly understood.