How Specify Differs

Specify occupies a space that existing tools don't cover. It's not competing with your current toolchain - it's filling the gap between "what should we build?" and "let's start building."

The traditional approach

Most embedded projects follow a familiar pattern:

1. Teams brainstorm functional requirements
2. An architect imagines an architecture that satisfies them
3. Developers implement against the architecture
4. Testers validate against the requirements

This works until it doesn't. The architecture doesn't follow the natural flow of features and use cases - it was guessed before the full system was understood. Code becomes abstract and detached from the real motivation and behaviour. Testing can only validate by following feature flows, but the architecture reflects requirements, not features. When something goes wrong, engineers can't easily trace back to what the system was supposed to do.

The root cause is the starting question: "What requirements must this system satisfy?" This leads to flat lists of requirements where many combinations of correct individual requirements produce incorrect system behaviour.

The Specify approach

Specify asks a different question: "What must be true for this system to exist safely and coherently?"

Instead of a flat requirements list, the system is described as features grouped by feature sets. Requirements don't float above the system - they live inside features, attached to specific use cases, governing specific scenarios. Architecture emerges from the feature set boundaries rather than being guessed upfront.

The result is a system definition where:

• Every behaviour is bounded and has clear ownership
• Requirements trace directly to the features they govern
• The specification structure mirrors the system structure
• Knowledge is explicit and shareable, not trapped in people's heads

How it relates to other tools

Specify complements your existing toolchain rather than replacing it.

Tool category	What it does	How Specify relates
Project management tools	Manage tasks, sprints, and resources	Specify defines what needs to be built. Task managers handle who builds it and when. Features can export to work items, use cases to tasks, requirements to acceptance criteria.
Requirements databases	Track requirements globally	Requirements databases track requirements across an organisation. Specify structures requirements within behavioural contexts - each requirement belongs to a feature and a use case. The approaches can coexist.
Documentation systems	Store documentation and processes	Documentation systems store prose about the system. Specify models the system's behaviours. The system definition is structured and queryable, not narrative.
Code documentation tools	Document code and APIs	Code documentation tools document how the system is implemented. Specify defines what the system does. One looks backward at code, the other looks forward at intent.
Version control	Store and version code	Version control stores the implementation. Specify stores the definition. The system definition feeds the development process that produces the code.

The relationship is sequential: Specify defines what needs to be built. Other tools manage how it gets built, track the code, and document the result.

What makes it different

Methodology agnostic. Specify works with Waterfall, Agile, or anything else. It doesn't care how you organise your work - it cares that your system is correctly defined.

Hardware agnostic. Start with no hardware decisions, or with complete specs. Specify doesn't depend on specific hardware choices - the system definition describes behaviour, not implementation.

Start anywhere. You don't need to define the entire system before starting work. Start with one feature set. Add three features to an existing product. Build out as you go. This isn't waterfall - you build the system definition iteratively, as you work, not as an afterthought.

Plain English, machine readable. Everything is written in plain English for humans, structured hierarchically for navigation, and exportable as JSON/CSV for machines. No special notation required.

Related

• System Definition - what the finished specification represents
• Features First - the approach in detail
• Glossary - every term defined