Contributing to Requirements Documentation

Building Proficiency and Tool Fluency

1.Practice converting five real requests you encounter in daily life, not necessarily work-related, into requirement statements, to build the habit of separating need from solution.
2.Ask to shadow three stakeholder conversations before running one independently.
3.After each requirement is documented, ask a mentor whether it meets the clear, unambiguous, verifiable, and traceable standard, and revise it if it does not.

1.Begin noticing, even informally, that requirements differ by type (business, stakeholder, functional, non-functional).
2.Classifying them formally as a discipline becomes an expected practice at OFA 2, built on this same early noticing.

II.

Tool Category	Representative Tools	How an OFA 1 Uses Them
Requirements documentation	Word templates, confluence, Azure DevOps work items	Recording requirements in a structured, reviewable format
Diagramming & presentation	Visio, Lucidchart, Miro, PowerPoint	Representing a process or requirement visually, or summarizing discovery findings for a stakeholder audience
Requirements traceability	Azure DevOps linked work items, spreadsheets for small workstreams	Connecting a requirement back to the original stakeholder need
AI drafting assistance	Approved AI writing assistants	Turning a rough stakeholder quote into a candidate requirement statement for the OFA to verify
Data lookup	Basic reporting dashboards, read-only database views	Checking what data already exists before assuming a new requirement is needed

III.

A.Many requirements ultimately depend on what data already exists in a system.
B.A foundational OFA benefits from being able to read, though not necessarily write, simple database queries.
C.SQL is the standard language for retrieving data from relational databases.
D.A new OFA will encounter it in reports, in conversations with technical teammates, and eventually in their own basic lookups.

1.A stakeholder requests "a way to see which wards have not submitted their activity reports this month."
2.Before treating this as a new system requirement, an OFA benefits from knowing that this information may already be retrievable with a query such as the one below, which a technical teammate might write and explain.

SELECT WardName FROM Wards WHERE WardID NOT IN     (         SELECT WardID       FROM ActivityReports         WHERE ReportMonth = '2026-06'     );

3.SELECT WardName FROM Wards WHERE WardID NOT IN ( SELECT WardID FROM ActivityReports WHERE ReportMonth = '2026-06' );

4.An OFA 1 is expected only to read a query like this and describe in plain language what it does — in this case, listing wards with no matching report for the given month — when a technical teammate shares one.
5.Writing new queries independently, joining multiple tables, or modifying production data is outside the scope of this level and should always be done by, or with, a qualified technical resource.

IV.

A.AI assistants can help translate a stakeholder's plain-language request into a candidate requirement statement.
B.They can even suggest a plausible SQL query structure from a plain-language description of what data is needed.
C.Both uses are legitimate starting points, and neither is a finished, trustworthy answer.
D.An AI-suggested requirement must be checked against what the stakeholder said.
E.An AI-suggested query must be reviewed by someone qualified to run it before it touches any real system, since an incorrect query can return misleading results or, in the wrong hands, alter data it should not.