Artefact: requirements
Requirements that remember who asked for them.
Backlog.cloud sits in your discovery calls and produces a structured requirements document: business, functional and non-functional requirements, assumptions, constraints and open questions, each one traceable to the stakeholder who said it and the exact words they used. Not a summary. A document a BA would stand behind.
What this artefact is
The document discovery meetings keep failing to produce
Every discovery conversation is full of requirements. They arrive as complaints, anecdotes, throwaway numbers and conditions attached to other sentences. The traditional path from that conversation to a requirements document is a BA with a notepad, three days of writing up, and a review meeting where half the detail turns out to have been misheard.
Backlog.cloud generates the document from the conversation itself. Statements of need become classified, ID-numbered requirements. Numbers mentioned in passing become measurable targets. Hedges and question marks become recorded assumptions and open questions. And because the source is a transcript rather than memory, every entry can cite the sentence that produced it.
The write-up work that used to take days happens during the call. The BA's job shifts from stenography to judgement: reviewing, sharpening and challenging a draft that already exists. The craft of asking the right questions in the room is covered in the requirements gathering guide.
Before and after
Five minutes of discovery, four classified requirements
An exchange from a fictional field-service company's discovery call about engineer scheduling, and what Backlog.cloud extracted from it. Curated example, real output shape.
What was said
Ruth (Ops Director): A quarter of our engineer visits fail because the customer is out. We give a four-hour arrival window and people just do not wait in for four hours any more.
James (Dispatch Lead): The window is wide because the schedule is built the night before. Once an engineer overruns on job two, everything after it drifts and we have no way to tell anyone.
Ruth (Ops Director): Whatever we build has to recalculate on the day and text the customer a tighter slot. And it cannot slow James down, his team dispatches three hundred jobs by 7am.
Priti (BA): Do the engineers all have company phones with data? Because live recalculation only works if we know where they are.
James (Dispatch Lead): Most do. The subcontractors are a question mark, I would have to check what the framework agreement says about tracking.
Reduce failed engineer visits caused by customers not being home
25 per cent of visits currently fail because the customer is out. The four-hour arrival window is identified as the driver: customers no longer wait in for windows of that length.
"A quarter of our engineer visits fail because the customer is out." Ruth, SH-01
The system shall recalculate the day's schedule when a job overruns and notify affected customers of a revised arrival window
Acceptance criteria
- Given an engineer's job overruns its estimate, when the overrun is detected, then arrival windows for the remaining jobs on that engineer's run are recalculated the same day.
- Given a customer's arrival window changes, when the recalculation completes, then the customer receives a text message with the revised, narrower window.
"Once an engineer overruns on job two, everything after it drifts and we have no way to tell anyone." James, SH-02
Scheduling changes must not slow the morning dispatch run
Dispatch processes roughly 300 jobs before 7am. Any recalculation feature must leave that throughput intact. Target: no measurable increase in per-job dispatch time for the morning run.
"It cannot slow James down, his team dispatches three hundred jobs by 7am." Ruth, SH-01
Engineer location data is available for live recalculation
Directly employed engineers carry company phones with data. Subcontractor coverage is unconfirmed and recalculation accuracy depends on it.
Open question: does the subcontractor framework agreement permit location tracking? Owner: James, to check before build planning.
"The subcontractors are a question mark, I would have to check what the framework agreement says about tracking." James, SH-02
Notice what did not happen: nothing was invented. The 25 per cent failure rate, the 300-job dispatch run and the subcontractor doubt all came from the room. The document is only ever as confident as the conversation was.
Document structure
What the full document contains
The generated document follows the structure BAs already use, so it slots into existing review and approval processes without translation.
- 01
Purpose and scope
What the document covers, what it deliberately leaves out, and who it is for.
- 02
Stakeholders
Every person whose statements shaped a requirement, with an ID used for traceability.
- 03
Glossary
Domain terms defined the way the team used them, not the way a textbook would.
- 04
Business requirements
The outcomes that justify the work, with owners. BR-prefixed.
- 05
Functional requirements
What the system shall do, each with acceptance criteria. FR-prefixed.
- 06
Non-functional requirements
Performance, availability, security and usability targets with numbers. NFR-prefixed.
- 07
Assumptions and constraints
What the team is taking on faith, and the boundaries nobody gets to move.
- 08
Version history and approvals
Who drafted it, who signs it off, and what changed between versions.
Exports as .docx. Requirements still get signed off in Word in most organisations, so the document leaves the product in a format approvers will actually open, version history and all.
Requirements and the Discovery Pack
One document per meeting, one evidence base per project
A requirements document is a snapshot: what this conversation established, classified and numbered. Discovery rarely finishes in one conversation. The workshop on Tuesday contradicts the interview from last week, the process mapping session adds a user group nobody had mentioned, and an estimate quoted in week one gets replaced by a verified figure in week three.
That is what the Discovery Pack is for. It is a living document, exactly one per project, that Backlog.cloud merges and versions across every discovery meeting: stakeholders, business context, the as-is process, pain points with stable reference codes, statistics with their provenance, personas, clarification questions and a changelog recording what each meeting changed. Requirements documents feed the build. The Discovery Pack holds the accumulating picture the requirements came from, and it exports as .docx too.
Run them together: the pack accumulates evidence across discovery meetings, and requirements documents crystallise out of it when a workstream is ready to commit.
Common mistakes
Where requirements documents usually go wrong
Requirements with no owner and no source
Six months in, someone challenges FR-004 and nobody remembers where it came from. Requirements written from a transcript carry the stakeholder who said it and the sentence they said. The argument becomes a lookup.
Writing solutions and calling them requirements
"The system shall use push notifications" is a design decision. The requirement was "customers must learn about a revised arrival window in time to act on it". Backlog.cloud keeps the need and the mechanism separate, so the team can still choose SMS when it turns out half the customer base has the app uninstalled.
Non-functional requirements without numbers
"The schedule must recalculate quickly" cannot be tested, argued with, or built to. The generated NFR carries the target that was actually discussed, and where no number was given, the gap becomes an open question instead of a vague adjective.
Burying unknowns instead of recording them
The subcontractor tracking question in the example is exactly the kind of thing that vanishes between discovery and build, then resurfaces as a contract problem in month four. Here it is captured as an open question against the requirement it affects.
Treating the document as finished after one workshop
Discovery is a sequence of conversations, not an event. A requirements document snapshots what is known now. The Discovery Pack exists precisely because the evidence base keeps moving across meetings.
FAQ
Requirements from conversations, answered
- How does Backlog.cloud generate a requirements document from a meeting?
- The meeting bot joins the call from a pasted link, or you paste a transcript or upload a recording afterwards. The extraction engine identifies statements of need, classifies each one as business, functional, non-functional, assumption or constraint, assigns IDs, attaches acceptance criteria where the conversation supports them, and records who said what. The result is a structured document you review and edit before sharing.
- What is the difference between functional and non-functional requirements here?
- Functional requirements describe what the system shall do, like recalculating the schedule when an engineer overruns. Non-functional requirements describe how well it must do it: latency targets, availability, device constraints, security expectations. Backlog.cloud classifies both from the conversation and gives non-functional entries a measurable target wherever one was stated.
- How does traceability work?
- Every stakeholder gets an ID, and every requirement records its source stakeholder and the verbatim statement it came from. When a requirement is questioned later, you can read the exact sentence that produced it. That is the difference between a requirements document and a list of things someone once thought.
- What happens to things the meeting left unresolved?
- They become open questions attached to the requirement they affect, not silent gaps. If nobody stated a latency target, the NFR says so and asks. A requirements document that pretends to be complete is more dangerous than one that is honest about its holes.
- How does this relate to the Discovery Pack?
- A requirements document is a point-in-time artefact generated from a meeting. The Discovery Pack is a living document, one per project, that merges and versions the whole discovery evidence base across every discovery meeting: stakeholders, as-is process, pain points, statistics, personas and clarification questions, with a changelog per meeting. Requirements documents feed sprints and sign-offs, the Discovery Pack holds the accumulated picture.
- Can I export the document?
- Yes. Requirements documents and the Discovery Pack both export as .docx, so they travel into the approval workflows that still run on Word documents, which in most organisations is all of them.
- Do requirements push to Jira like stories do?
- The document is the artefact, and it exports as .docx for review and sign-off. When conversations also produce backlog-shaped work, those items are generated as stories, tasks and bugs alongside the document and push to Jira, Azure DevOps, Linear, GitHub Issues, Notion or ClickUp after your review.
Keep going
Related workflows and resources
Transcript to requirements
Start from a transcript you already have instead of a live call.
Requirements gathering guide
The questions and techniques that make discovery calls productive.
Discovery meetings
How Backlog.cloud listens to workshops, interviews and mapping sessions.
For business analysts
The BA workflow: discovery, requirements, traceability and sign-off.
User stories
When requirements become sprint work, they become stories.
Meeting to backlog
The wider workflow: one conversation, twelve artefact types.
Stop reconstructing requirements from memory
Create a free account, run your next discovery call through Backlog.cloud, and review a requirements document with every entry traced to its source. 3 free generations, no card.