Eliciting and Documenting Requirements
I.
A Reliable Set of Questions
A small set of reliable questions surfaces most of what a new OFA needs:
- A.What problem does this solve?
- B.Who is affected if this does not happen?
- C.What happens today without this?
- D.How will we know it worked?
An OFA 1 asks these questions with the support of a mentor or senior OFA, preparing them in advance and reviewing what was learned afterward.
A.
Looking Ahead to OFA 2
- 1.At the next level, an OFA asks these same questions independently, without a senior OFA present.
- 2.An OFA 2 is expected to recognize on their own when an answer is too vague to document as-is.
- 3.That independence is not expected of an OFA 1, but is worth knowing as the next step built on this same skill.
II.
Writing for Someone Not in the Room
- A.A requirement should be written so that someone unfamiliar with the conversation can understand what is needed and why.
- B.Vague language (for example, "make it easier" or "improve performance") should be pushed back on gently until it can be stated in terms that could be verified later.
III.
Common beginner mistakes
- A.Recording a stakeholder's proposed solution as if it were the requirement itself.
- B.Leaving vague language in a requirement rather than asking a follow-up question.
- C.Assuming silence means agreement, rather than confirming understanding explicitly.
- D.Failing to note who said what, making it hard to follow up on ambiguous points.