Requirement Analyzer

Requirement inputs arrive scattered across meeting notes, emails, and workshop scribbles. The failure modes are always the same: requirements go missing, the objective is fuzzy, and nobody wrote down the constraints. This skill turns that mess into a single structured brief that every downstream stage can rely on.

Instructions

Step 1: Read the input as-is

Take whatever the user provides — notes, a document, or a transcript. Do not ask them to reformat it. If several sources are given, merge them.

Step 2: Extract into the brief

Fill in this structure. Leave a field as an empty list only if the input genuinely says nothing about it; otherwise infer conservatively and mark the inference in assumptions.

• Project name and client — pull the literal names if stated.
• Objective — one sentence: the business outcome the client is buying.
• Goals — the measurable results that define success.
• Stakeholders — each person or group mentioned, with their role and interest.
• Functional requirements — what the system must do. One capability per line.
• Non-functional requirements — performance, security, compliance, availability, usability, localization. These are the ones teams forget; look for them deliberately.
• Constraints — budget, deadline, tech stack mandates, integrations, client data restrictions.
• Assumptions — anything you inferred that a human should confirm.
• Open questions — gaps that block estimation or design. Be specific.

Step 3: Separate signal from decoration

Discovery notes contain a lot of chatter. Keep only statements that change what gets built. A line like "the client seemed excited" is not a requirement; "the client needs SSO with their Azure AD" is.

Step 4: Flag, do not stall

If the objective or client is missing, record it as an open question and continue. A brief with clear gaps is more useful than no brief.

Output format

ALWAYS produce two things: a readable brief for humans, and the JSON object below so the next stage can consume it directly.

{
  "project_name": "",
  "client": "",
  "objective": "",
  "goals": [],
  "stakeholders": [{"name": "", "role": ""}],
  "functional_requirements": [],
  "non_functional_requirements": [],
  "constraints": [],
  "assumptions": [],
  "open_questions": []
}

See references/extraction-schema.md for field-by-field guidance and the checklist of non-functional requirement categories teams commonly miss.

Example

Input: "Met ClientCo. They run a chain of pharmacies in Dhaka and want an app so customers can reorder repeat prescriptions and get delivery. Must work on low-end Android. They mentioned bKash payment. Launch before Ramadan. Budget is tight."

Output (abridged):

• objective: "Let pharmacy customers reorder repeat prescriptions and arrange delivery from a mobile app."
• functional_requirements: ["Reorder previous prescriptions", "Schedule delivery", "bKash payment"]
• non_functional_requirements: ["Runs on low-end Android devices"]
• constraints: ["Launch before Ramadan", "Tight budget"]
• open_questions: ["Which Ramadan date is the hard deadline?", "Is prescription verification required by regulation?"]

Troubleshooting

• Everything looks like a requirement. Apply the Step 3 test: does removing this line change what gets built? If not, drop it.
• The input contradicts itself (common across multiple emails). Capture both versions in open_questions and let a human resolve it.