The structured, grounded description of what your product does and the data it works with — not a document nobody updates.
A software specification, or spec, is a structured description of what a system should do and the data it works with. It typically covers functional requirements (what the system does), non-functional requirements (how well it has to do it), and a data model (the entities involved and how they relate). Its job is to make sure a developer, a client, and a tester all agree on what “done” looks like.
A spec's value is in how it's used. A client reads it to confirm scope without touching the implementation. A developer reads it to know exactly what to build and what counts as correct. An AI coding agent reads it the same way — a precise, checkable description of the behavior it's implementing, not a loose prompt to interpret. Because everyone reads the same document, scope disagreements surface before implementation, not after.
In kratai, a spec breaks down into three sections, each answering a different question about the project.
Here's what that looks like in practice — kratai's own generated SRS:
You can export these three sections together as a formatted PDF of your own — see Export an SRS.
Before diving into use cases or the data model, ask chat to write the Overview — the project's background, context, and purpose. Chat reads the actual codebase to draft it, rather than asking you to describe the project from scratch, and you can revise it with another chat message until it reads the way you want.
Once the Overview reads the way you want, move on to the Use Case Model — that's where requirements actually live. See Design a Use Case Model for how to generate, detail, and edit it.