Explore the Reference Project

The Reference Project is a system definition for a generic domestic oven. It's a working example of what a real product specification looks like in Solaros Specify - currently with 20 feature sets, 122 features, 85 use cases, and over 350 requirements.

Open the Reference Project in another tab and follow along. This guide walks through the structure, section by section, explaining what you're looking at and why it's organised the way it is.

The big picture

When you open the Reference Project, the Overview tab shows all 20 feature sets listed in alphabetical order. Before diving into individual features, notice something about the names:

Feature sets in ALL CAPS - like CLOCK DOMAINS, COMMS PROTOCOL, DEBUG SERVICES, MEMORY MANAGEMENT - are system-level concerns. These are the feature sets that most embedded systems need regardless of what product you're building. Clock management, memory allocation, interrupt handling, power cycling - these are the infrastructure of any embedded product.

Feature sets in Title Case - like Control Panel, Display, Error Handling, Oven Control, User Features - are product-specific. These describe what makes this product an oven rather than a medical device or an industrial controller.

This distinction matters. When you start a new project, the ALL CAPS feature sets give you a checklist of system-level concerns to think about. The Title Case sets are where your product's unique behaviour lives.

A simple example: CLOCK DOMAINS

In the Reference Project, expand the CLOCK DOMAINS feature set. The first feature you'll see is 1ms Tick Interval Clock (F1).

This is a straightforward feature - the system needs a 1-millisecond tick for frequency based scheduling and for managing timed events. It's a hardware-software interface concern: the software needs this clock, and the hardware has to provide it.

Look at the metadata on this feature:

Status: Approved - it's been reviewed and confirmed as necessary
MoSCoW: Must Have - the system can't function without it
Category: Categorised - all metadata has been set
Feature Category: Hardware-Software Interface
Service Type: Hardware Timing
Service Name / Logical Component: Clock Domains

Below the metadata, you'll see the feature's requirements. These are the rules that define what this clock must do - its frequency, tolerance, and what depends on it.

This is the basic pattern: a feature set contains features, and each feature has requirements that define its behaviour.

A richer example: User Features

Now expand User Features and find Cancel Baking Session. This feature is more complex and shows the full hierarchy at work.

You'll see two types of content under the feature:

Feature Requirements (FRs) are general rules that apply to this feature regardless of how it's used. For Cancel Baking Session, these might include rules about what happens to the heating elements, whether the timer resets, and what the display should show.

Use Cases are concrete scenarios. You'll see a use case called something like "The Happy Path" - this is the scenario where everything goes right. The user cancels the session, the system responds correctly, and the outcome is successful.

Inside each use case, you'll find Use Case Requirements (UCRs) - rules specific to that scenario. For the happy path, these describe the step-by-step sequence: the user presses cancel, the display updates, the heating stops.

The hierarchy is based on requirements set at two levels of the feature tree.

Level 1: Feature Set → Feature → Feature Requirements.
Level 2: Feature Set → Feature → Use Cases → Use Case Requirements.

This two-level requirement structure is deliberate. Feature requirements define what must always be true about the feature. Use case requirements define what must happen in a specific scenario. Together, they give you complete coverage without duplication.

The hardware-software boundary

Scroll through the feature set list and find three feature sets that address something most embedded projects get wrong:

Firmware Assumptions - what the firmware expects the hardware to provide
Hardware Assumptions - what the hardware expects the firmware to do
HW Timing Constraints - timing limitations that the hardware imposes on the firmware

In most projects, these assumptions live in people's heads. The hardware engineer "knows" the firmware will poll at a certain rate. The firmware engineer "assumes" a particular interrupt latency. When these assumptions don't match - and they often don't - you find out during integration testing, which is the most expensive time to discover a mismatch.

In the Oven Project, these assumptions are explicit features with their own requirements. They're part of the specification from the start.

Feature statuses

As you browse the Reference Project, you'll notice status badges on features:

Draft - the feature has been written but the text needs review. It's a starting point.
Review - the feature is under review. MoSCoW priority is being assigned, metadata is being added, and the team is deciding whether to approve it.
Approved - the feature has been confirmed as necessary for the project. It's locked and ready for full specification.
Categorised - all metadata has been set: feature category, service type and service name (the logical component).

Features progress through these statuses as they move through Specify's four stages - Plan, Review, Create, and Finalise. You can read more about this in The Four Stages.

Five tabs, four workflow stages

The Reference Project has tabs across the top: Overview, Plan, Review, Create, and Finalise. Each tab shows the project through the lens of that workflow stage:

Overview - everything at a glance, all feature sets and their features
Plan - features being captured and described
Review - features being prioritised and categorised
Create - features (by feature set) with all known feature requirements and use case requirements
Finalise - features being signed off and locked for export

You can switch between tabs to see the same project from different perspectives. This is how Specify supports the workflow - each stage has its own view with the actions relevant to that stage.

What to notice

A few things worth paying attention to as you explore:

Features aren't just user-facing. The Oven Project has user features like "Change Baking Temperature" and "Switch Oven On", but it also has Clock Domains, Memory Management, Interrupt Handling, and Power Cycle Control. A feature in Specify is any capability, constraint or resource provisioning that needs to be defined - not just things the user sees.

The structure is the documentation. There's no separate "architecture document" or "requirements specification" sitting alongside the project. The feature hierarchy IS the specification. Feature sets are the components. Features are the behaviours. Requirements are the rules.

Nothing is vague. Requirements have specific values, tolerances, and conditions. Not "respond quickly" but "within 100ms". Not "handle errors" but "if sensor timeout occurs, use last known good value and flag error". The EARS Reference explains the patterns used to write requirements this way.

Follow the workflow

You've seen what a real system definition looks like. The Guided Walkthrough follows a single feature through all four stages using a Driveway Gate Controller system as the example - showing the same patterns at a smaller scale.