SE311 · Annotated SlidesChapter 3 — The Requirements Elicitation Process
Chapter 3 · Annotated slides

The Requirements Elicitation Process

Elicitation goals and sources of requirements, the process (plan, prepare, perform, follow up), classifying customer input, knowing when you are done, challenges and best practices.

Slide text Study notes Highlight: key words Tips, tricks & traps Seen again elsewhere How it can come up
Slide 1: Slide 1
Exam weight Low

    Outline

    • Elicitation goals
    • Sources of Requirements
    • Requirements Elicitation Process
    • Elicitation Challenges
    • Elicitation Best Practices
    2
    Exam weight Low

      Elicitation Goals

      • Determine sources of requirements and select appropriate techniques
      • Elicit information on domain, problem, needs, and constraints
      • Produce a first document
        • Mainly user requirements and elicitation notes
        • Potentially incomplete, disorganized, and inconsistent but one must start somewhere
      3
      Exam weight Low
      1. Elicitation: discovering requirements from stakeholders and other sources (not just "gathering").

      Sources of Requirements

      • Stakeholders
      • Existing systems
      • Existing documentation
      • Competing systems
      • Documentation about interfacing systems
      • Standards, policies, collective agreements, and legislation
      4
      Exam weight Low
      1. Sources: stakeholders and users, documents, existing systems, regulations, competitors, problem reports.
      Slide 5: Sources of Requirements - Stakeholders
      Exam weight Low
        Slide 6: Requirements Elicitation Process
        Exam weight Low
        1. Process: plan → prepare → perform → follow up (organize, share notes, record open issues).
        Slide 7: Planning for Elicitation
        Exam weight Low
          Slide 8: Prepare for Elicitation
          Exam weight Low
            Slide 9: Prepare for Elicitation
            Exam weight Low
              Slide 10: Performing Elicitation Activities
              Exam weight Low
                Slide 11: Following up after Elicitation
                Exam weight Low
                  Slide 12: Following up after Eliciation
                  Exam weight Low
                    Slide 13: Classifying Customer Input
                    Exam weight Low
                    1. Classify input as: business requirement, user requirement, business rule, functional, quality attribute, external interface, constraint, data definition, solution idea.
                    ★ Past exam

                    When are we done?

                    U sers can’t think of any more use cases or user stories

                    • U sers propose new scenarios that don’t lead to any new functional
                    • requirements
                    • Users repeat issues that were previously covered
                    • Suggested new features or requirements are all out of scope
                    • Proposed new requirements are all low priority
                    • Developers and testers review the requirements have few questions
                    14
                    Exam weight High
                    1. Done when: users can’t think of more use cases; new ideas are out of scope or low priority; proposed requirements repeat earlier ones; ideas are future, not current; the remaining issues are understood.

                    Asked in a real exam

                    ★ Quiz 1 (Ch. 1–3) · Q11: when elicitation is done
                    🎯 How this can come up · 1 question
                    Written

                    When do you know you are done with elicitation? Give two signs.

                    Slide 15: Elicitation Challenges
                    Exam weight Low
                    1. Challenges: stakeholders unavailable, don’t know what they want, use jargon, conflict; scope creep; solution ideas disguised as requirements.

                    Final Remarks

                    • Requirements elicitation is perhaps the most challenging, critical, error-prone, and communication-intensive aspect of software development
                    • Try to extract the essence of stakeholders’ requirements and invent new ways for them to better perform their tasks
                    • Remember, elicitation is incremental
                    Final Remarks
                    16
                    Exam weight Low
                      Slide 17: Requirements Elicitation Best Practices
                      Exam weight Low
                      1. Best practices: define scope first, identify user classes, select product champions, use several techniques, document as you go.

                      ↩

                      18
                      Exam weight Low
                        Slide 19: Slide 19
                        Exam weight Low