A request to add an approval button sounds precise. In a hypothetical purchasing system, though, it leaves several questions open: who has authority, what happens during absences and whether the real problem is delay, missing records or unclear responsibility.
Gathering requirements involves discovering and recording what a change needs to achieve, including its rules and constraints. The requested feature is a starting point for that investigation.
Investigate the task behind the request
Speak to someone who submits purchase requests, someone who approves them and the process owner who can confirm the rules. A sponsor can explain the business objective; everyday users can show where work gets stuck.
Ask a requester to walk through a recent purchase, from submission to decision. Note the people, systems and information involved.
For technical professionals working in English as a second language, IT English practice can support clear explanations and follow-up questions. Agree local definitions as well: ‘approved’ might mean permission to purchase or confirmation that budget is available. Record which meaning applies before discussing how the software should behave.
Match the discovery method to the question
Interviews help explain decisions and frustrations. Observation reveals working practices, including workarounds people might forget to mention. Forms, policies and existing records provide documented rules; check that they are current.
Use a workshop when teams need to resolve conflicting expectations. Separate interviews can uncover a disagreement, while a shared discussion gives the people responsible a chance to settle it.
For the purchasing example, combine a requester walkthrough with a review of approval rules. Use current practice as evidence while questioning which parts the new process should retain.
Find the rules and exceptions
Once the normal route is understood, investigate its exceptions. What happens if the approver is absent? Who is authorised to act instead? What should happen if nobody suitable is available?
Suppose the walkthrough reveals that staff chase absent managers by email. That points to a need for a defined approval route during absences. Confirm delegation authority with the process owner before proposing who should receive those requests.
A routing rule is a functional requirement: it describes system behaviour. Also investigate quality requirements, such as performance and accessibility. Turn vague expectations such as ‘fast’ into agreed, measurable conditions where relevant.
Keep confirmed rules and unresolved questions visibly separate, so a guess cannot quietly become part of the specification.
Write a requirement someone can check
Give each requirement a reference and retain its source. Someone reviewing it later should be able to understand why it exists and whom to consult if the rule changes.
With cover arrangements agreed by the process owner, the example could be recorded as follows:
- Reference: PUR-01, approval routing during absence.
- User need: Purchase requests need an authorised review route when the usual approver is away.
- Source: Requester walkthrough and cover rules confirmed by the purchasing process owner.
- Required behaviour: On submission, route the request to the usual approver unless a recorded absence applies. During that absence, route it to the nominated authorised deputy.
- Exception: If no authorised deputy is configured, retain the request as pending and flag it to the purchasing team, with no automatic approval.
- Open question: Should requesters receive an email when their request is routed to a deputy? The process owner must decide before notification work is estimated.
- Acceptance criteria: With an absence recorded and an authorised deputy configured, a new request appears in the deputy’s queue rather than the absent approver’s. Without a deputy, it remains pending and is flagged to purchasing.
Record permissions, usability and other requirements separately, each with appropriate checks.
Validate the behaviour and agree priorities
Walk users through the proposed behaviour using both an ordinary request and an absence scenario. Ask the process owner to confirm authority and fallback rules, then involve developers to assess feasibility and dependencies, including where absence information comes from.
Separate essential behaviour from convenience features. An authorised approval route may be necessary for this change; an additional email could wait. Where priorities conflict, ask the accountable owner to weigh the requests against the agreed objective.
The change is ready to progress when users recognise the workflow, the rules are confirmed and developers can assess the work. Resolve unknowns affecting core behaviour before implementation, and give other open questions an owner. As understanding develops, preserve the reason for each revision so later decisions remain traceable.
