Specification

Specification audio micro-course (transcript)

Three short podcasts about “Specification”. Listen with the interactive player.

Podcast 1 — Introduction & meaning

Narrator: Specification. Seven syllables. A word that carries weight, precision, and authority wherever it appears.

Narrator: At its core, a specification is a formal, precise statement of exactly what something must be, do, or contain. It is the difference between asking for a table and ordering a table with dimensions of one-point-two metres by eighty centimetres, in solid oak, finished in matte black, with four tapered legs and a central drawer. The second version is a specification. It eliminates ambiguity and makes expectations binding.

Narrator: In engineering, specifications are the backbone of everything built. A bridge specification lists the load it must bear, the materials permitted, the tolerances allowed, and the tests it must pass. A car specification covers engine capacity, fuel efficiency, safety ratings, and trim levels. Without specifications, every engineer and every factory worker would be guessing — and guessing in engineering is expensive, sometimes catastrophic.

Narrator: In software development, a specification defines system behaviour. A functional specification describes what a system does. A technical specification describes how it does it. Writing a clear specification before coding is what separates projects that deliver on time from projects that drift, expand, and collapse under changing requirements.

Narrator: The word entered English from Medieval Latin in the seventeenth century. It derives from specificare — to specify — itself from the Latin species, meaning kind or sort, and facere, to make. To specify the kind of thing you want is literally what specification means at its ancient root.

Narrator: Specification. Precision made permanent. The art of saying exactly what you mean, in writing, so that nothing is left to chance.

Speaker A: I keep seeing the word spec used instead of specification. Are they interchangeable?

Speaker B: In practice, yes — spec is the standard shorthand in most professional environments. Developers, engineers, and product managers all say let me check the spec or the spec says. The full word specification tends to appear in formal documents, contracts, and headings — where the register is elevated and precision signals authority.

Speaker A: So a specification document is different from just a spec?

Speaker B: Not really different — specification document and spec are usually the same thing. The difference is register. If you are presenting to a client board, you say the project specification has been finalised. If you are on a Slack thread with a colleague, you say the spec is ready. Same document, different context. One thing to avoid is using specification loosely to mean just any description. A specification is binding and precise. Saying here is my specification and then handing over a vague paragraph is a misuse — that would just be a description or an outline.

Speaker A: What about technical specification versus functional specification? I hear both.

Speaker B: Good distinction. A functional specification describes what a system must do — its features, user flows, inputs, outputs, and behaviour from the user's perspective. A technical specification describes how it will be built — the architecture, the languages, the APIs, the data models. Both are specifications, but they answer different questions. Functional is the what, technical is the how. In large projects you often need both, and they should be consistent with each other.

Speaker A: Can specification be used outside technical fields?

Speaker B: Absolutely. You hear it in cooking — a professional recipe is effectively a culinary specification. In fashion design, a tech pack is a garment specification. In law, contract specifications define the deliverables a supplier must meet. Even in everyday speech — to a high specification, or built to specification — the word carries its core meaning: something done exactly as required, with nothing left vague. It is a powerful word because it signals that quality and precision were deliberately intended, not accidental.

Speaker B: Today we are prompting with the word specification. When you put specification into a prompt, you shift the AI from guessing what you want to following a precise brief. It is one of the most powerful words you can use to tighten a prompt. Six prompts — each built around specification.

Speaker A: That is a strong framing. Specification as the precision lever in a prompt.

Speaker B: Prompt one — UI sidebar. Build a sidebar navigation to this specification: fixed width 260px, dark background, icon plus label menu items, active item highlighted in purple, collapsible on mobile. Clean and modern.

Speaker A: Giving the sidebar a specification rather than just describing it forces the AI to treat each requirement as binding. Nothing gets interpreted loosely.

Speaker B: Prompt two — database schema. Design a product database to this specification: products table with id, name, price, stock, category_id. Categories table with id and name. Foreign key on category_id. Index on price and stock.

Speaker A: The phrase to this specification tells the AI every detail that follows is a requirement, not a suggestion.

Speaker B: Prompt three — API endpoint. Build a REST API endpoint to this specification: POST slash orders, accepts JSON with user_id and items array, validates stock, creates an order record, returns order_id and total. Express and PostgreSQL.

Speaker A: Every field named in the specification becomes part of the contract. The AI knows exactly what inputs it must handle and what it must return.

Speaker B: Prompt four — HR system. Build an HR leave request system to this specification: employees submit requests with date range and reason. Managers approve or reject. Email notification on decision. Status tracked as pending, approved, or rejected.

Speaker A: Three statuses explicitly defined in the specification — that removes any ambiguity about what states the system needs to handle.

Speaker B: Prompt five — dashboard. Build an analytics dashboard to this specification: daily active users chart, revenue by product bar chart, top five customers table, date range filter. Refresh every sixty seconds. Dark blue theme.

Speaker A: The specification lists exactly four components. The AI knows not to add a fifth, and not to skip any of the four. That is the power of a specification — it defines scope precisely.

Speaker B: Prompt six — full app. Build a stock management app to this specification: add, edit, delete products. Low stock alert below ten units. Export to CSV. User login with admin and staff roles. Clean white and blue theme.

Speaker A: Role-based access, low stock alerts, CSV export — all in one specification. That one prompt could replace a page of requirements if the AI reads it carefully.

Speaker B: Specification in six prompts. The word turns a vague request into a binding brief — and that is exactly what separates a prompt that produces something usable from one that produces something generic.