PLAINREADS — REQUIREMENTS GATHERING
Source: https://plainreads.com/blog/requirements-gathering-template

INTERVIEW PROMPTS
What were you trying to accomplish?
What happened immediately before you started?
What information or access did you need?
Where did work become uncertain or stop?
What did you do instead?
How would you know the task was completed correctly?

REQUIREMENT RECORD — REPEAT FOR EACH REQUIREMENT
ID:
User and situation:
Task and reason:
Evidence/source, date, and limits:
Required behavior:
Acceptance check and relevant conditions:
Priority and rationale:
Confirmation owner:
Open question and answer owner:
Decision, date, and reason:
Related delivery task and verification evidence:

FICTIONAL EXAMPLE — EXPENSE FAQ
These are scenario assumptions, not actual user research.
R-01: New starter reaches approved submission instructions from welcome message.
Check: With new-starter access, follow published link and locate submission steps.
R-02: Reader can identify current policy source.
Check: Every FAQ answer links to version confirmed by policy owner.
R-03: Reader knows how to ask a question not answered in FAQ.
Check: FAQ names responsible team and agreed contact route; ownership confirmed.

REVIEW CHECKLIST
- Each requirement connects to a real task and stated reason.
- Evidence is distinguished from assumptions and preferences.
- Acceptance checks can fail and reflect intended user conditions.
- Access, accessibility, maintenance, and device needs are considered.
- Conflicting requests have an authorized decision and recorded rationale.
- Deferred requests are not silently treated as delivery commitments.
- Current requirements link to the approved brief and delivery plan.
- Changes are assessed before the commitment is revised.