Convert Notes to Requirements

What this skill is for

Raw notes are full of ambiguity: conflicting statements, unclear ownership, opinions mixed with facts, and solutions masquerading as needs. This skill uses AI to classify, structure, and trace note content into a requirements brief where every item has a source, a type, and an owner. The goal is not to replace the analyst but to accelerate the tedious parts while preserving the nuance that determines project success.

When to use this skill

• After a stakeholder workshop where multiple people gave conflicting descriptions of the same process.
• When you have pages of interview transcripts and need to extract structured needs quickly.
• When reviewing a long support ticket thread to find the actual problem beneath the proposed fixes.
• When consolidating workshop notes into a format that can be reviewed by stakeholders who did not attend.
• When AI summarization has flattened important detail and you need to recover it.

Real work situations

Workshop notes contain conflicting ownership claims

A workshop on SAP vendor master governance produces notes where the procurement lead says "we own the vendor create process," the finance lead says "we approve payment terms," and the MDG team says "we gate all changes." An AI that simply summarizes this as "vendor master has multiple owners" loses the critical detail that each team owns a different stage. The structured output must preserve the stage-level ownership so the governance design can assign rights correctly.

Support ticket thread mixes symptoms with solutions

A ticket thread about billing blocks contains 23 comments. Some users propose workarounds, others describe symptoms, and one comment reveals a recent configuration change. A simple summary might say "billing blocks are causing delays." The structured requirements output must classify the configuration change as a potential root cause, the workarounds as temporary solutions, and the symptoms as evidence for a diagnostic requirement.

Interview transcript buries needs under complaints

A 45-minute interview with a warehouse manager contains complaints about the goods receipt process, the RF device, and the integration with WMS. Buried in the complaints is a real need: real-time visibility of inbound shipments before the truck arrives. A generic summary loses this because the word "need" never appears in the transcript. The structured output must extract the underlying need and separate it from the surrounding complaints.

Inputs required

• Raw notes or transcripts — the source material, unedited.
• Attendee or commenter list — who said what, if identifiable.
• System context — which SAP modules, processes, or integrations are in scope.
• Existing requirements — if a baseline exists (optional).
• Stakeholder roles — to identify decision-makers versus observers.

Questions to ask

• Who said this — a decision-maker, an observer, or someone repeating hearsay?
• Is this statement a need, a solution, an assumption, a risk, or a complaint?
• What business rule or process step is being referenced?
• Which SAP system touchpoints are mentioned, and are they accurate?
• Does this statement conflict with another statement in the same notes?
• What is the underlying need if this is only a complaint or a solution?

Working method

1. Collect raw notes. Gather all source material: transcripts, tickets, handwritten notes, whiteboard photos. Do not paraphrase before analysis.
2. Identify and tag speakers. If the source identifies who made each statement, tag each paragraph with the speaker. If not, flag unattributed statements for follow-up.
3. Classify each statement. Use AI to label each significant statement as: Need, Solution, Assumption, Risk, Fact, Complaint, or Unknown.
4. Extract needs. From every statement classified as Need or Complaint, derive the underlying need. For Complaints, ask "what would have to be true for this complaint to go away?"
5. Separate solutions from needs. For every Solution statement, capture the solution but also derive the need it serves. If the need is unclear, flag it as an open question.
6. Capture assumptions and risks. Collect every Assumption and Risk into a register. Link them to the needs they affect.
7. Structure requirements. Rewrite each extracted need as a requirement in the format: "The system must [capability] so that [business outcome]." Include the source statement ID.
8. Add traceability. For every requirement, record the source note, the speaker, and the classification. For conflicts, record both sides and flag for resolution.
9. Produce the brief. Assemble the requirements, assumptions, risks, conflicts, and open questions into a single document.

Decision rules

• If two stakeholders conflict, document both positions and flag for a decision session; do not let the AI pick a winner.
• If a statement describes a solution, always derive the underlying need; if the need cannot be derived, discard the solution.
• If a need has no owner, add it to the open questions list and assign a stakeholder to find the owner.
• If a statement is unattributed, flag it as "source unknown" and do not use it as the sole basis for a requirement.
• If a complaint contains no actionable need, log it as context but do not create a requirement.
• If the AI misclassifies a statement, correct it manually and note the correction.

Deliverables

• Structured Requirements Brief — needs rewritten as requirements with traceability.
• Source Traceability Matrix — links each requirement to the original note, speaker, and classification.
• Assumption and Risk Register — extracted assumptions and risks linked to requirements.
• Conflict Log — documented stakeholder conflicts awaiting resolution.
• Open Questions List — missing owners, unclear needs, or unknown sources.

Templates

Structured Requirements Brief

---
title: Structured Requirements Brief
source: [workshop notes / interview transcripts / ticket thread]
project: [project name]
analyst: [name]
date: [YYYY-MM-DD]
---

## Requirement N-001
- **Statement**: The system must [capability] so that [business outcome].
- **Source**: [Note ID, Speaker, Original quote]
- **Classification**: [Need / Derived from Complaint / Derived from Solution]
- **Stakeholder**: [owner]
- **Assumption**: [what must be true]
- **Risk**: [what could go wrong]
- **Status**: [Draft / Awaiting Review / Conflicted]

## Conflict Log
| # | Stakeholder A | Position | Stakeholder B | Position | Resolution Needed From |
|---|---------------|----------|---------------|----------|----------------------|
| 1 | [name] | [position] | [name] | [position] | [decision maker] |

## Open Questions
| # | Question | Blocks | Assigned To |
|---|----------|--------|-------------|
| 1 | [question] | [requirement IDs] | [stakeholder] |

Quality checklist

• [ ] Every requirement traces back to a specific source note or transcript segment.
• [ ] Speaker attribution is present for every requirement derived from a workshop or interview.
• [ ] Every conflict is documented, not resolved silently by the AI or analyst.
• [ ] Every solution statement has a derived need; orphaned solutions are removed.
• [ ] The assumption register links assumptions to the requirements they affect.
• [ ] The open questions list is non-empty if any source material was ambiguous.
• [ ] A stakeholder who attended the source session can read the brief and recognize their input.

Common mistakes

• Mistake: Letting the AI resolve stakeholder conflicts by choosing the majority view. Consequence: A minority stakeholder who controls the data or process is sidelined, and the requirements fail at the approval gate.
• Mistake: Losing nuance in AI summarization. Consequence: A critical distinction — such as stage-level ownership versus process-level ownership — is flattened, and the governance design assigns the wrong rights.
• Mistake: Merging facts with opinions. Consequence: A stakeholder's opinion about the root cause is treated as a verified fact, and the requirement targets the wrong problem.
• Mistake: Treating every complaint as a requirement. Consequence: The requirements document bloats with low-value items that do not address root causes.

Weak output vs Strong output

Weak output — bad AI usage

A consultant feeds workshop notes into an AI and asks for a summary. The AI produces a generic list of "requirements" that merges the procurement lead's ownership claim with the finance lead's approval role into a single vague statement: "Vendor master needs better governance." The AI loses the fact that the MDG team gates changes but does not own data quality. The resulting brief is useless for governance design because the stage boundaries are gone. When stakeholders review it, they say "this is not what we discussed" and the workshop must be repeated.

Strong output — good AI usage

The consultant uses AI to classify every paragraph of the workshop notes. Requirement N-004 is derived from the procurement lead's statement and explicitly covers the create process. Requirement N-005 is derived from the finance lead and covers payment term approval. The conflict log flags that the MDG team's role is described as both "gatekeeper" and "data quality owner" by different speakers, and the open questions list assigns the procurement lead to clarify the boundary. The brief is reviewed and approved in one session because every stakeholder sees their input preserved and the conflicts honestly surfaced.

Agent instructions

AI Prompt Pattern

Role: You are a note-to-requirements analyst.
Context: I have raw notes from a [workshop / interview / ticket thread] about [SAP process / business area].
Tasks:
1. Tag each significant statement with the speaker if known.
2. Classify each statement as: Need, Solution, Assumption, Risk, Fact, Complaint, or Unknown.
3. Extract the underlying need from every Complaint and Solution.
4. Rewrite each need as a requirement with the format: "The system must [capability] so that [business outcome]."
5. Document conflicts, assumptions, and open questions.
6. Output a Structured Requirements Brief using the provided template.
Constraints: Do not resolve conflicts. Do not drop speaker attribution. Do not invent needs that are not in the source material. Flag anything that is unclear.

Agent dos

• Preserve the exact words of stakeholders when they describe needs or constraints.
• Classify every significant statement before extracting requirements.
• Flag conflicts and leave them for human stakeholders to resolve.
• Produce the traceability matrix as a separate artifact, not as an afterthought.

Agent don'ts

• Do not let AI summarization flatten nuance into generic statements.
• Do not merge conflicting stakeholder positions into a single compromise requirement.
• Do not invent requirements that are not supported by the source notes.
• Do not present opinions as facts.

Related skills

• Requirements Elicitation — capturing stakeholder needs directly.
• Stakeholder Analysis — identifying who to interview and who owns what.
• Process Analysis — mapping how work happens before extracting requirements.

Related Atlas pages

• SAP Process Audit — structured frame for understanding process context before requirement extraction.
• Master Data Issues Blocking Sales Orders — example of how raw symptoms map to structured diagnostic needs.

Verification status and limitations

This skill is a public working interpretation of AI-assisted note conversion. It is not an official BABOK, SAP, or vendor method. AI classification accuracy depends on the model and the quality of the source notes; ambiguous or unstructured notes will produce more "Unknown" classifications. The skill does not replace stakeholder validation: the brief must always be reviewed by the people who provided the original input. Use it as a structured accelerator, not as a substitute for human judgment.