Chipress

We are entering the AI era where natural language is the primary interface for system architecture, chip design, and verification. With AI models turning natural language prompts directly into RTL and test benches, the quality of your output is strictly bounded by the quality of your specification (or spec). Specs written by non-trained authors have more than 30 major defects per page. If not fixed in specs, each major defect can cause 10x effort or even more in the execution pipeline.

What is a spec?

At its core, a spec establishes a clear, common, and coherent understanding of what a system must accomplish:

1. Clear: Every statement is unambiguous, complete, and concise
2. Common: All stakeholders share the exact same understanding
3. Coherent: Every requirement is consistent and forms a unified logical whole

A spec drives the design choices, and it should define:

1. Functional requirements, i.e., what a system must do
2. Quality and Performance requirement, i.e., How well the system must do what it does
3. Constraints, i.e., statements that limit the solution space beyond what is necessary for meeting given functional, quality, and performance requirements

The Spectrum of Spec Formality

Requirements can be specified across a broad spectrum of formality:

Consider the following example of how a single Autonomous Emergency Braking (AEB) safety requirement scales across this spectrum:

1. Unconstrained Natural Language – “The car should brake automatically if it gets too close to something in front of it while driving”
2. Constrained Natural Language – “While the vehicle is moving forward at speeds exceeding 15 km/h, when the forward radar detects an obstacle in the vehicle’s driving path with a time-to-collision (TTC) of less than 1.5 seconds, the vehicle shall apply maximum emergency braking”
3. Lightweight Formal Methods –

While(Speedveh>15km/h)(TTCpath<1.5s);Statebrake:=EmergencyMax

4. Formal Specifications – v:Vehicle,obs:Obstacle

(MovingForward(v) Speed(v) > 15 km/h InPath(v, obs) TTC(v, obs) < 1.5s)

—> BrakeState(v) = EmergencyMax W (⌐InPath(v, obs) ∨ Speed(v) = 0 km/h)

There is no single “right way” that exists for all projects, and one needs to find the sweet spot for a single task. However, for most applications, Constrained Natural Language strikes the optimal balance between readability, flexibility, and engineering precision.

Common Pitfalls in Natural Language Specs

Unconstrained natural language introduces critical failure modes:

Category	Problematic Patterns	Why It Fails
Weak Words	normal, usual, regular, state-of-the-art, quickly, timely, rapidly, promptly	Subjective; lacks precise mathematical or operational definitions.
Unbounded Lists	such as, for example, etc., including but not limited to, at least	Lacks a boundary, making design and verification impossible to complete.
Implicit Collections	“The software shall support MacOS.”	Creates multiple interpretations (e.g., All historical versions? Native Apple Silicon or Rosetta 2?).
Structure & Grammar	Complicated sentences, passive voice, double negatives.	Leads to misinterpretation by human engineers and AI tools alike.

Core Characteristics of Quality Specs

Every requirement in a specification must satisfy eight core criteria:

Property	Description
1. Feasible	There is at least one design and implementation for it. Spec may have been proven feasible in previous products. Evolutionary or breakthrough specifications can be shown feasible at acceptable risk levels through analysis and prototyping.
2. Correct	Error-free and validated against source materials and stakeholder intent.
3. Complete	Contains sufficient details for downstream teams to guide their work.
4. Concise	Contains only necessary information, expressed in as few words as possible.
5. Unambiguous	Possesses only a single possible interpretation across readers. Note, ambiguity is often dependent on the background of the reader. Reduce ambiguity by defining terms, writing concisely, and testing understanding among the target audience.
6. Prioritized	Ranked based on customer value, development risk, effort, or time-to-market. Several scales can be used for prioritization, e.g., essential vs desirable, high vs medium vs low, etc.
7. Consistent	Free of logical or functional conflicts with other specifications at any level. Consistency is improved by referring to the original statement where needed instead of repeating statements.
8. Verifiable	Proven to be correctly implemented via demonstration, analysis, inspection, or testing.

To achieve the above criteria, spec authors should follow the following best practices during spec writing:

1. Adopt Constrained Natural Language: Move away from loose narrative to reduce ambiguity with minimal overhead
2. Focus on Black-Box Requirements: Specify system behaviors from the outside looking in. Exclude internal design choices unless explicitly required as constraints
3. Product Scope: Make sure the readers and authors are well aware of the product scope in the very beginning
4. Maintain a Glossary: Define domain terms in a single, accessible repository
5. Use Imperatives Correctly:

• Shall / Must: Mandatory requirements (subject to verification).
• Should / May: Non-mandatory goals or design options.
• Will / Responsible for: Informational statements regarding external systems.

6. Prefer Positive Statements: Avoid double negatives.

• Avoid: “Users shall not be allowed to get root access.”
• Use: “The system shall not allow users to gain root access.”

7. Quantify Qualitative Metrics: Turn subjective goals into measurable parameters (e.g., latency bounds, power limits).
8. Supplement Text: Use state diagrams, tables, and algorithms to clarify complex logic.
9. Vigorously verify specifications to prevent defects and maximize specifications quality.
10. Validate Specs against source materials, and with both internal and external stakeholders frequently
11. Establish Version Control & Traceability: Track authoring metadata, version IDs, and change logs.

A Standard Syntax for Requirements: EARS

To ensure consistency, apply standard frameworks like the Easy Approach to Requirements Syntax (EARS):

[State] [Trigger] Actor Action Object  ([State] and [Trigger] are optional)

For example:

“While the autonomous vehicle is parked waiting for passengers to arrive [State], when the passengers are within 5 feet of the vehicle [Trigger], the vehicle [Actor] shall open [Action] the door [Object] automatically.”

We recommend readers to refer to EARS link for more details.

Level of Detail and Timing: Balancing Investment and Risk

The correct level of detail is a strategic decision that balances risk against upfront investment. There are several factors determining the spec detail level:

1. Product Scope: New breakthrough feature vs. routine upgrade.
2. Complexity: Domain, organizational and technical complexities.
3. Team Profile: Team size, distribution, and domain experience.
4. Risk & Compliance: Regulatory requirements and safety bounds.
5. Architecture Hierarchy: System level down to component or IP sub-block.
6. Project cycle: Where we are at the life cycle of the product or project.

Timing and scope management require making choices about when to write specs and what to omit, ensuring engineering effort remains aligned with evolving project realities:

1. Adopt an Iterative Approach: Specs should evolve through feedback and learning cycles.
2. Avoid Over-Specifying Early: Excess detail early in a project risks wasted effort if product direction pivots.
3. Avoid False Security: A massive document does not equal zero risk—especially if it merely documents assumptions everyone already shared.

Conclusion

In the AI era, writing specs is no longer just documentation—it is high-leverage engineering programming. By migrating to constrained natural language, applying standardized structures like EARS, and focusing on verifiable black-box requirements, engineering teams can eliminate costly downstream defects and leverage AI tooling to build robust systems safely and efficiently.

References:

1. How 3GPP specifications are written: https://www.3gpp.org/specifications-groups/delegates-corner/writing-a-new-spec
2. Easy Approach to Requirements Syntax (EARS): https://alistairmavin.com/ears/