Requirements elicitation
Elicitation techniques (interview, questionnaire, observation, workshop, analysis of existing material, mock-up), choosing the right one for a situation, types of questions and the stakeholders to ask.
- 23 cards
- 4 topics
- Free
The outline, topic by topic
Each topic is weighted the way the exam weighs it.
- Concepts
- Questions
- Sort and link
- Scenarios
A few cards from the deck
Requirements elicitation: what is it?
Show the answer
The activity that discovers, from the people concerned and in existing documents, what the future system must provide.
Needs are not simply “collected”: many go unspoken, because the user finds them obvious or cannot put them into words.
Order pickers sort parcels very quickly and cannot explain their method. Which elicitation technique should be used to understand it?
- Observation at the workstation
- A questionnaire sent to all the pickers
- A workshop with the warehouse management
- Analysis of the company's written procedures
Show the answer
Observation at the workstation
A gesture that has become automatic can be seen but not described. Written procedures show the prescribed work, not the real work, and management does not do it themselves.
An … question lets the person answer in their own words; a … question expects “yes”, “no” or a choice from a list.
Show the answer
An open question lets the person answer in their own words; a closed question expects “yes”, “no” or a choice from a list.
The open one serves to discover (“How do you do it?”), the closed one to confirm or to quantify (“How many times a week?”).
Stakeholder: what is it?
Show the answer
A person or group affected by the system or able to influence the project: users, sponsor, operators, lawyers.
Forgetting a stakeholder means forgetting their needs: the team that will run the application has requirements that neither the sponsor nor the users state.
The client approved the specification, then rejects the delivery: “this is not what we wanted”. Which cause should be retained, and what should change on the next project?
- The specification was too short: write a longer, more detailed one
- No user ever saw a mock-up: show one to real users early
- The client approved too quickly: have them initial every page before coding
- The client changed their mind: forbid any change after approval
Show the answer
No user ever saw a mock-up: show one to real users early
Approving a text is not approving a way of using the system: with no mock-up and no talk with those who will use it, the gap only shows at delivery. More text, more signatures or a frozen document teach nothing about real use; only early feedback from users facing something concrete corrects course.