Q11: when elicitation is done
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.
How to read this page
Every original slide is shown unchanged. Yellow marks on a slide point to a numbered note: hover or tap a mark to jump to its note, and hover a note to see its marks. Questions tagged Past exam appeared on a real paper; Prediction questions are likely angles, not confirmed. Pick an answer to each question: a wrong pick tells you why it is wrong, so you can try again.
All 19 slides
- 1 Slide 1
- 2 Outline
- 3 Elicitation Goals
- 4 Sources of Requirements
- 5 Sources of Requirements - Stakeholders
- 6 Requirements Elicitation Process
- 7 Planning for Elicitation
- 8 Prepare for Elicitation
- 9 Prepare for Elicitation
- 10 Performing Elicitation Activities
- 11 Following up after Elicitation
- 12 Following up after Eliciation
- 13 Classifying Customer Input
- 14 When are we done?
- 15 Elicitation Challenges
- 16 Final Remarks
- 17 Requirements Elicitation Best Practices
- 18 Slide 18
- 19 Slide 19
Elicitation Goals
Notes
Elicitation: discovering requirements from stakeholders and other sources (not just "gathering").
Sources of Requirements
Notes
Sources: stakeholders and users, documents, existing systems, regulations, competitors, problem reports.
Classifying Customer Input
Notes
Classify input as: business requirement, user requirement, business rule, functional, quality attribute, external interface, constraint, data definition, solution idea.
When are we done?
Notes
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.
Exam angle
When do you know you are done with elicitation? Give two signs.
Compare with the model answer
Users can’t think of any more use cases or user stories; new suggestions are out of scope or already captured (repeating earlier requirements); remaining ideas are “nice to have” for future releases; the team can explain the requirements well enough to build and test.
Elicitation Challenges
Notes
Challenges: stakeholders unavailable, don’t know what they want, use jargon, conflict; scope creep; solution ideas disguised as requirements.
Requirements Elicitation Best Practices
Notes
Best practices: define scope first, identify user classes, select product champions, use several techniques, document as you go.