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.
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.