Features First

The features-first approach is the foundation of how Specify works. Instead of starting with a flat list of requirements and trying to architect a system around them, you start with features - the bounded behavioural capabilities that together make up your product.

The approach

Describe your system as a collection of features grouped by feature set. Each feature maintains a logical thread of traceability from the beginning of a project to completion.

This means:

• Every feature has a name, a purpose, scenarios (use cases), and rules (requirements)
• Requirements don't exist in isolation - they belong to a feature and govern a specific behaviour
• Feature sets group related features into logical components
• Architecture emerges from the feature set boundaries rather than being imposed upfront

The starting question isn't "what requirements must this system satisfy?" but "what behaviours make up this product?"

Why features, not requirements

Requirements are rules. Features are behaviours. The distinction matters because a flat list of correct requirements can still produce incorrect behaviour.

Consider a system with 200 individually correct requirements. If those requirements are organised as a flat list, the interactions between them are implicit. Sequencing issues, timing conflicts, and contradictory edge cases hide in the gaps between requirements. Teams discover these problems during integration testing - the most expensive time to find them.

When requirements live inside features, attached to specific use cases, the interactions are visible. You can read a feature from top to bottom and understand what it does, why, and under what constraints. The specification structure mirrors the system structure.

Start anywhere

Features-first doesn't mean "define everything first." You can:

• Start with one feature set and build out as your understanding grows
• Add three new features to an existing product without specifying the whole system
• Work iteratively - features can exist with just a name and description initially, then be refined over time
• Export when ready - you don't need every feature finalised to get value from the ones that are

This is not waterfall. You build the system definition as you work, not as a prerequisite to starting. But you build it deliberately - each feature goes through Plan, Review, Create, and Finalise to ensure it's correctly defined.

Traceability

Each feature creates a traceable thread through the entire development lifecycle:

• Specification: the feature is defined with requirements and use cases
• Implementation: code is written to satisfy the feature's requirements
• Testing: tests validate the feature against its specification
• Acceptance: deliveries are measured against the feature's definition

Every code statement and code path can be tagged to the feature it implements. Unit tests, integration tests, and acceptance tests all trace back to specific features and requirements. When something fails, you know exactly which feature's behaviour is wrong and which requirements it violates.

Related

• System Definition - what the features-first approach produces
• Features & Feature Sets - what features are in detail
• From Definition to Code - the path from specification to implementation