REQUIREMENTS ELICITATION

Requirements Sources

• Stakeholders:
  • Users (internal & external Personas, Data driven, Imagination)
  • Sponsors
  • Developers
  • Authorities
  • Customers
• Documents:
  • Company-, domain- and project-related documents
  • Product and process descriptions
  • Legal and regulatory documentation, etc.
• (Other) Systems:
  • Legacy systems
  • Competitor systems
  • Comparable systems used in other organizations
• Importance of Identifying Sources:
  • If relevant sources are not identified or considered, requirements may remain undetected.
  • The quality and completeness of requirements depend greatly on the requirements sources involved.
  • Missing a relevant source will lead to an incomplete understanding of the requirements or to incomplete requirements.
  • Check the validity and relevance of a document.
  • Requirements derived from invalid or outdated systems would normally lead to system failure.

Elicitation Techniques

• Categories:
  • Gathering
  • Questioning
  • Collaboration
  • Observation
  • Artifact-based
  • Design & idea-generating
• Techniques List:
  *Interview
  *Workshops
  *Questionnaire
  *Crowd-based RE
  *Field observation
  *Feedback analysis
  *Apprenticing
  *Reuse of requirements
  *Brainstorming
  *Analogy technique
  *Scenarios & storyboards
  *Prototyping
  *System archaeology

Selecting Elicitation Techniques

• Factors to Consider:
  • Type of system
  • SDLC model
  • People involved
  • Organizational setup
• Best Practice:
  • The best results are usually achieved with a combination of different techniques

The Kano Model

• Categories:
  • Delighters
  • Satisfiers
  • Dissatisfiers
• Note:
  • Change over time

The Kano Model Explained

• Delighters:
  • Excitement factors, unconscious requirements.
• Satisfiers:
  • Performance factors, conscious requirements.
• Dissatisfiers:
  • Basic factors, subconscious requirements.

Camera Function on Cell Phones Example

• Evolution:
  • Initial introduction as a delighter.
  • Transition to a satisfier based on picture quality.
  • Became a dissatisfier as camera function became standard.

Gathering Techniques: Questioning

• Methods:
  • Interview
  • Questionnaire

Interviewing Users & Other Stakeholders

• Process:
  • Prepare detailed questions.
  • Meet with individuals or groups of users.
  • Obtain and discuss answers to the questions.
  • Document the answers.
  • Follow up as needed in future meetings or interviews.

Interview - Question Theme

• Questions to users:
  • What do you do?
  • How do you do it?
  • What steps do you follow?
  • How could they be done differently?
  • What information do you use?
  • What inputs do you use?
  • What outputs do you produce?
• Theme:
  • What are the business operations and processes?
  • How should those operations be performed?
  • What information is needed to perform those operations?

Interview – Question Types

• Open-ended questions:
  • Encourages discussion and explanation.
  • Example: How do you do this function?
• Close-ended questions:
  • To get specific facts.
  • Example: How many forms a day do you process?

Interview - Checklist

• Before:
  • Establish the objective for the interview.
  • Determine correct user(s) to be involved.
  • Determine project team members to participate.
  • Build a list of questions and issues to be discussed.
  • Review related documents and materials.
  • Set the time and location.
  • Inform all participants of objective, time, and locations.
• During:
  • Arrive on time.
  • Look for exception and error conditions.
  • Probe for details.
  • Take thorough notes.
  • Identify and document unanswered items or open questions.
• After:
  • Review notes for accuracy, completeness, and understanding.
  • Transfer information to appropriate models and documents.
  • Identify areas needing further clarification.
  • Thank the participants.
  • Follow up on open and unanswered questions.

Interview Session Agenda Example

• Objective of Interview:
  • Determine processing rules for sales commission rates
• Date, Time, and Location:
  • April 21, 2012, at 9:00 a.m. in William McDougal's office
• User Participants:
  • William McDougal, vice president of marketing and sales, and several of his staff
• Project Team Participants:
  • Mary Ellen Green and Jim Williams
• Interview/Discussion:
  • Example questions:
    • Who is eligible for sales commissions?
    • What is the basis for commissions? What rates are paid?
    • How is commission for returns handled?
    • Are there special incentives? Contests? Programs based on time?
    • Is there a variable scale for commissions? Are there quotas?
    • What are the exceptions?
• Follow-Up:
  • Important decisions or answers to questions: See attached write-up on commission policies
  • Open items not resolved with assignments for solution: See Item numbers 2 and 3 on open items list
  • Date and time of next meeting or follow-up session: April 28, 2012, at 9:00 a.m.

Interview - Sample Open Item List

• Includes example issues like partial shipments, returns and commissions, and extra commissions with details such as date identified, target end date, responsible project person, user contact, and comments.

Distributing and collecting questionnaires

• Collect information from large number of stakeholders
• Not suitable for understanding business processes, workflows or techniques

Gathering Techniques: Collaboration

• Workshops:
  • A structured meeting in which a carefully selected group of stakeholders and content experts work together to define, create, refine and reach a closure on deliverables
• Crowd-based RE

Gathering Techniques: Observation

• Methods:
  • Field observation
  • Apprenticing

Artifact-Based Gathering Techniques

• Methods:
  • System archaeology
  • Feedback analysis
  • Reuse of requirements

Ridgeline Mountain Outfitters - Customer Order Form

• An example of reviewing inputs, outputs, and procedures

Observing and Documenting Business Procedures

• Watch and learn business processes.
  • Understand the business processes and see how to improve them (system archaeology)
• Document with Activity diagram (Topic 3)

Design & Idea-Generating: Creativity

• Brainstorming:
  • Classical – Moderator initiates ideas and leads discussion to assess the ideas.
  • Variations – Participants initiate ideas and gathered by the moderator. Moderator provides criteria for appraisal, later appraised by the participants on group level.
• Analogy Technique:
  • Two ways:
    • Hidden – Participants know only the analogy
    • Open – Analogy and real problem are known

Design & Idea-Generating: Design

• Methods:
  • Prototyping
  • Scenarios & storyboards

Correlation of Elicitation Techniques with Kano Model

Kano Model and Requirements Types

• Delighters:
  • Excitement factors, unconscious requirements
  • System properties that the stakeholder does not know or expect and discovers only while using the system (unconscious knowledge).
• Satisfiers:
  • Performance factors, conscious requirements, explicitly demanded
  • If some demanded properties are missing, the stakeholders probably will not accept the product.
• Dissatisfiers:
  • Basic factors, subconscious requirements, properties of the system that are self-evident and taken for granted (subconscious knowledge).
  • Must be fulfilled by the system, otherwise, stakeholders will be disappointed/dissatisfied.
• The Kano model looks at requirements from the perspective of the customer. It focuses on differentiating features, as opposed to expressed needs
• Gathering Techniques such as questionnaire, Artifact based Design andIdea-Generating Technique Gathering Technique, Observation, Artifact based

Prioritize Requirements

• Determining crucial requirements
• Desirable vs essential requirements
• Why prioritize?
  • Limited resources, thus need to justify system scope
  • To avoid scope creep
  • Help determine number of project iterations
• High priority requirements are often included in early iterations to allow ample opportunity for refinements

Develop User-Interface Dialogs

• Old system replaced by new systems
• Automating functions that were previously manual – users are not certain of requirements
• Users are not able to interpret and validate models such as use cases, activity diagrams, and interaction diagrams
• User interface validation is simpler and more reliable
• Use storyboard or user interface prototype

Evaluate Requirements with Users

• Ideally – evaluation and documenting requirements are integrated
• Practice - System users have other responsibilities besides developing systems, evaluation and documentation is an iterative process
  • Elicit → build models & prototypes → evaluate

Challenges of Requirements Analysis

• Stakeholders don’t know what they really want.
• Stakeholders express requirements in their own terms.
• Different stakeholders may have conflicting requirements.
• Organisational and political factors may influence the system requirements.
• The requirements change during the analysis process. New stakeholders may emerge and the business environment change.

Results of Incorrect Requirements

• The system may cost more than projected.
• The system may be delivered later than promised.
• The system may not meet the users’ expectations and that dissatisfaction may cause them not to use it.
• Once in production, the costs of maintaining and enhancing the system may be excessively high.
• The system may be unreliable and prone to errors and downtime.
• The reputation of the IT staff on the team is tarnished because any failure, regardless of who is at fault, will be perceived as a mistake by the team.