Start with people and work
Requirements are not collected like objects from a shelf. They are discovered through conversations, observation, documents and repeated validation.
A stakeholder is any person or group affected by the problem, the process or the future solution. A stakeholder does not need to be a direct user of the application.
For the attendance case, stakeholders may include:
- teachers who record attendance
- students whose data is recorded
- administration staff who consolidate reports
- managers who define policies
- technical staff who operate the system
Each group sees a different part of the problem.
An edge case is an uncommon but possible situation near the limits of normal use, such as an empty class list or two people updating the same record. A constraint is a limit the solution must respect, such as existing equipment, budget, law or deadline.
Ask about facts before opinions
Weak question:
Would you like a dashboard?
Better questions:
- Show me how you complete this task today.
- What information do you use at each step?
- Where do mistakes occur most often?
- What happened the last time the process failed?
- Which decisions require approval?
- What must never happen?
- How do you know the task is complete?
These questions reveal evidence instead of encouraging feature ideas.
Map the current workflow
Teacher receives class list
↓
Teacher marks attendance on paper
↓
Administration collects sheets
↓
Data is entered into a spreadsheet
↓
Missing or unclear records are returned for correction
The map exposes delays, duplication and error points.
Discover different requirement types
| Type | Question | Example |
|---|---|---|
| Functional | What must the system do? | Record attendance for a session |
| Business rule | What policy controls the action? | Corrections close after 48 hours |
| Data | What information is required? | Student, session, status and timestamp |
| Quality | How well must it work? | Save a class list in under two seconds |
| Constraint | What limits the solution? | Teachers use existing personal phones |
Quality requirements are not limited to speed. They can also describe:
- Accessibility: every attendance action can be completed using a keyboard
- Availability: teachers can access the service during at least 99.5% of scheduled class hours
- Security: the system locks an account for ten minutes after five failed login attempts
- Reliability: a saved attendance record is not lost if the page is refreshed
Activity: conduct a mini interview
Choose a familiar process such as booking a classroom. Interview one person for ten minutes. Do not suggest features.
Capture:
- goal
- current steps
- information used
- pain points
- rules
- exceptions
- evidence of success
Check your understanding
Question: If two users request opposite behavior, which one is correct?
Neither request should be accepted automatically. Identify their roles, goals and applicable policies. The difference may reveal separate workflows, permissions or a decision that belongs to a product owner.
Practice the mindset: distinguish evidence from assumptions
A shop owner says: "Everyone complains that collecting an order is slow."
Pause and write: What does this statement establish? What would you need to observe before choosing a solution?
Examine the first answer
You know that the owner reports complaints. You do not yet know how many customers complained, how long collection takes or where the delay occurs. Repeating "everyone" as a measured fact would overstate the evidence.
New information
You observe three collections. Finding each order takes about one minute; preparing the items takes between eight and twelve minutes. These observations make preparation worth investigating. They do not prove that every collection has the same bottleneck.
| Note | Classification | Next step |
|---|---|---|
| Three observed orders took about one minute each to locate | Observation | Check other times and order types |
| The owner says everyone complains | Reported claim | Ask for recent examples |
| A faster search screen will fix the delay | Hypothesis | Check how much time searching actually takes |
| Preparation can start before arrival | Unconfirmed possibility | Ask about storage, timing and product constraints |
Independent practice: You may ask only two questions before another observation. Write them and explain which decision each answer would influence.
Review your reasoning
"Show me what happens between finding an order and handing it over" investigates the observed delay. "Which items cannot be prepared in advance, and why?" checks a possible constraint. Other questions are useful when their answers could change your next action.
Engineering habit: Keep observations, reported claims and hypotheses distinct. Confidence should reflect the evidence you actually have.
What you learned
- Stakeholders experience different parts of the same problem.
- Observation and factual questions reveal more than asking for desired features.
- Mapping the current workflow exposes delays, duplication and errors.
- Requirements include behavior, data, rules, quality expectations and constraints.
Knowledge check
- Why is “Would you like a dashboard?” a weak discovery question?
- What can observing a current workflow reveal that an interview may miss?
- Is “Corrections close after 48 hours” a feature or a business rule?
- It suggests a solution and encourages an opinion instead of investigating the current problem.
- It can reveal real shortcuts, interruptions, duplicate work and exceptions people forget to mention.
- It is a business rule because it defines a policy that controls system behavior.