SolarosGo To Solaros
Documentation

Guided Walkthrough

This walkthrough follows a single feature - Lock Gate - through all four stages of the Specify workflow. The example product is a Driveway Gate Control System: an electric entrance gate with remote operation, safety sensors, and security locking.

The point isn't to produce a finished specification. It's to show how a feature moves from an initial idea through to a locked, exportable definition - and how the structure builds as you go.

Open Specify alongside this page and follow along. If you want to compare against a mature example, keep the Reference Project open too.

The example product

A driveway gate control system is a real embedded product with clear features that don't need domain expertise to understand. Gates lock, unlock, open, close, detect obstacles, respond to remotes. The behaviours are tangible, and the requirements write themselves once the features are clear.

We'll focus on one feature: Lock Gate - the feature that locks the gate in its current position, preventing movement until explicitly unlocked.

Stage 1: Plan - capture the feature

Select 1. Plan from the navigation.

The Plan stage is for quick capture. You don't need to know everything about a feature to add it - just enough to describe what it does. Detail comes later.

Click Add Feature and enter:

  • Feature name: "Lock Gate"
  • Feature description: "Locks the gate in its current position, preventing movement until explicitly unlocked. The lock engages when the gate is fully closed and the system is in secure mode."
The feature appears in the Plan list with a P-number (P1, P2, etc). P-numbers are temporary identifiers for the planning stage. They change to permanent F-numbers after approval.

At this point the feature is proposed but not nominated. It's on the table for discussion - stakeholders can review it, add context, and decide whether it belongs in the project.

Nominate for review

Open "Lock Gate" and select Move to Review. This nominates the feature - it's flagged as necessary and moves to the Review stage.

Stage 2: Review - prioritise and categorise

Select 2. Review. "Lock Gate" appears under features nominated for review.

Open the feature. The Review stage captures three things:

MoSCoW priority

  • Must Have - the product is unacceptable without it
  • Should Have - important, but can defer if needed
  • Could Have - nice to have, first to be dropped under pressure
  • Won't Have - explicitly out of scope for this release
"Lock Gate" is a Must Have. A security gate without a lock isn't a security gate.

A guideline: Must Haves should be 60% or less of your total features. If everything is a Must Have, you can't make trade-off decisions when time gets tight.

Categorisation

Categorisation adds metadata that describes what kind of feature this is:

  • Feature Category - the type of behaviour. "Lock Gate" is a feature dialogue - an interaction between the user (or a protocol) and the system.
  • Service Type - the implementation pattern. For a feature dialogue, this might be "Feature Service".
  • Service Name - the logical component the feature belongs to.

Approve

Once priority and categorisation are set, the feature can be approved. Approval confirms it belongs in the project and assigns a permanent F-number (F1, F2, etc) replacing the P-number. F1 is always F1, even if the feature moves between feature sets later.

In the Reference Project, look at any approved feature in the Review tab to see the same metadata fields.

Stage 3: Create - build the specification

Select 3. Create. This is where the feature gets its full behavioural definition.

Create a feature set

Feature sets are logical groupings of related features - the components of your system. Create one called "Gate Controller" and assign "Lock Gate" to it.

Add feature requirements

Feature requirements are general rules that apply to "Lock Gate" regardless of which scenario is executing:

  • "The gate lock shall only engage when the gate is in the fully closed position."
  • "The gate lock shall disengage within 500ms of receiving an unlock command."
  • "While the gate lock is engaged, the system shall prevent motor activation in any direction."
Notice the patterns - "shall only", "within [time]", "while [condition], the system shall". These are EARS patterns. More on those in Write Requirements.

Add a use case

Use cases are concrete scenarios for the feature. Start with the happy path - the scenario where everything goes right.

Name it something like "Gate locks successfully" and describe the scenario: the user triggers a lock command, the system confirms the gate is closed, the lock engages.

Add use case requirements

Inside the happy path, add the step-by-step requirements for that specific scenario:

  • "When the user selects lock, the system shall verify the gate is in the fully closed position."
  • "When gate position is confirmed as closed, the system shall engage the lock mechanism."
  • "When the lock mechanism is engaged, the system shall update the display to show locked status."
Use case requirements describe what happens in sequence within one scenario. Feature requirements describe what must always be true. The two levels work together - general rules plus specific scenario behaviour.

In the Reference Project, expand User Features and look at Change Baking Temperature (F1) to see how feature requirements and use case requirements work together.

Custom ordering and IDs

You can drag features, use cases, and requirements into whatever order makes logical sense. Creation order doesn't have to be reading order. You can also assign custom IDs - "GATE-LCK-01" instead of "FR1" if that matches your conventions.

Stage 4: Finalise - lock and export

Select 4. Finalise.

Review "Lock Gate" for completeness:

  • Feature requirements cover all general rules
  • Use cases cover the scenarios that matter - at minimum the happy path, plus error conditions and edge cases
  • Use case requirements describe the full sequence within each scenario
  • No requirement is vague - every one has specific values, conditions, and tolerances
When the specification is complete, sign off the feature. It's now locked. Changes after this point require explicit authorisation and create an audit trail.

From the Finalise view you can export as JSON, CSV, or PDF. The export preserves your custom ordering and includes all metadata.

Where to go from here

Need help? Contact us · Return to home