Applied Requirements Work
I.
Cost of skipping the underlying requirement
Scenario
- A.A ward asked for "a way to print name tags faster" before a large activity.
- B.An OFA who took the request at face value might document "the system needs a faster name tag printing button" as the requirement.
A more careful OFA asked why printing was slow, and learned the actual bottleneck was that the attendee list had to be manually re-typed from a sign-up sheet before printing could even begin - the printing itself was not slow at all.
OFA Interpretation Questions
- C.What assumption did the surface request make about where the problem was?
- D.What would have happened if a "faster printing" feature had been built without uncovering the real bottleneck?
Stewardship Application
- E.Had the surface request been documented as-is, the eventual solution would have solved the wrong problem entirely, wasting development effort and leaving the ward no better off.
- F.This is the clearest possible illustration of why this module insists on separating request from requirement before anything is documented as final.
II.
Applied Practice and Evaluation
A.
Applying What was learned
- 1.Scenario Context
- a.The learner is given a stakeholder request such as "Can we add a search bar to the volunteer portal?"
- 2.Required OFA Reasoning
- a.Identify that this is a proposed solution.
- b.Determine the underlying requirement through follow-up questions (real or hypothetical).
- 3.Required Output
- a.A short document stating the underlying requirement separately from the proposed solution
B.
Performance Indicators
- 1.Strong Performance Indicators
- a.The underlying need is clearly separated from the proposed solution.
- b.Follow-up questions target the actual gap, not surface details.
- c.The final requirement is specific enough to be verified later.
- 2.Weak Performance Indicators
- a.The proposed solution is documented as the requirement without question.
- b.Follow-up questions are generic or absent.
- c.The requirement remains too vague to verify.
III.
Business Case Applications
A.
Case 1 — CRM Change
- 1.Scenario
- a.A volunteer coordinator says, "We just need a button to email all our volunteers at once," while replacing the department's contact tool.
- 2.Task
- a.Identify that this is a proposed solution, and ask follow-up questions to determine the underlying requirement (for example, what problem repeated manual emailing is currently causing).
- 3.Deliverable
- a.A short note stating the underlying requirement separately from the proposed "button" solution.
- 4.Evaluation Notes
- a.The requirement is stated in terms that could be verified later, not just restated as "an easier way to email people."
B.
Case 2 — Website Platform Change
- 1.Scenario
- a.A stakeholder says the new event pages need to "look better and be easier to use" than the current platform.
- 2.Task
- a.Push back gently on the vague language and ask questions until the requirement is specific enough to verify (for example, what specific task is currently hard to complete, and for whom).
- 3.Deliverable
- a.A documented requirement with the vague language replaced by something specific.
- 4.Evaluation Notes
- a.The final requirement no longer contains words like "better" or "easier" without a concrete definition attached.
C.
Case 3 — Mobile App
- 1.Scenario
- a.A stakeholder requests "a notification so people don't forget the activity sign-ups."
- 2.Task
- a.Determine the underlying requirement (what specifically is being missed today, and how it is discovered when it happens), and document it distinctly from the notification solution.
- 3.Deliverable
- a.A documented requirement with follow-up questions listed for anything still unclear.
- 4.Watch For
- a.The note does not simply restate "add a notification" as the requirement.