What is Solaros Specify?

One of the greatest challenges of embedded software engineering is the specification of a system - documenting an accurate description of the product you want to build. Most teams know what their product should do. The challenge is capturing that knowledge in a way that's complete, unambiguous, and useful throughout the entire development lifecycle.

Solaros Specify is a system definition tool. It helps teams describe an embedded product as a collection of features grouped by feature set, following a features-first approach that captures the full capability and behaviour of a system.

What you get

A system definition built in Specify isn't just documentation. It's a structured knowledge base that serves multiple purposes:

A record of intent. Not just what the system does, but what it was designed to do and why. This becomes the contractual basis for what gets delivered - the benchmark against which validation and acceptance of deliveries can be measured.

Traceable from start to finish. Each feature maintains a logical thread from initial capture through review, definition, and finalisation. When something goes wrong in testing or production, you can trace back to the original intent.

The IP that defines your product. The system definition becomes the knowledge base for the intellectual property associated with each product. When people leave, the knowledge stays.

How it works

Specify organises your system into a clear hierarchy:

• Feature Sets are logical groupings of related features - the components of your system
• Features are bounded behavioural capabilities - not work items or user stories, but descriptions of what the system actually does
• Use Cases are concrete scenarios for each feature
• Requirements are the rules that govern each feature and use case

Features move through four stages - Plan, Review, Create, and Finalise - with progressive refinement at each step. You can start with just a name and description, then build out the full specification as your understanding grows.

What it is not

Specify is not a requirements database - requirements here define behaviours, not validate them. It's not a project management tool - we define systems, not manage tasks. And it's not a documentation system - we model behaviours, not store prose.

It complements all of these. Specify defines what needs to be built. Other tools manage how it gets built and when.

What's next

The best way to understand Specify is to see a real example. Explore the Reference Project - a complete system definition for a domestic oven with 20 feature sets and over 350 requirements.