Requirements Hierarchy

Specify uses two levels of requirements within each feature. This isn't arbitrary complexity - it reflects how real systems work.

Feature requirements (FR)

Feature requirements are general rules that govern the feature regardless of which scenario is being executed. They define invariants - things that must always be true about this feature.

In the Reference Project, the feature "Change Baking Temperature" (F1) has feature requirements like:

Allow users to set temperature within a defined range (50-250°C)
Temperature changes are only permitted during an active baking session
Maintain stable internal temperature for grill, bake, and roast modes

These apply no matter how the temperature is changed, in which use case, or under what conditions. They're the rules of the feature.

Use case requirements (UCR)

Use case requirements are rules specific to one scenario. They describe the step-by-step sequence within a particular use case.

For the same feature, the "Happy Path" use case has requirements like:

The user turns the temperature dial to the new baking temperature
The display is updated with the new baking temperature

These only apply within this specific scenario. A different use case - say, "Temperature change rejected because oven is off" - would have its own UCRs describing that different sequence.

Why two levels

Consider what happens without this separation. If all requirements are at the same level, you end up with one of two problems:

Everything in one list. General rules and scenario-specific steps sit side by side. It's unclear which requirements apply always vs only in certain situations. Testing becomes harder because you can't distinguish invariants from sequence steps.

Duplicated across scenarios. The general rules get copied into every use case. When a rule changes, you update it in one place and miss it in three others. The specification drifts from itself.

The two-level hierarchy solves both problems. Feature requirements capture what must always be true. Use case requirements capture what happens in each specific scenario. Together they give you complete coverage without duplication.

The feature is its constraints

This is a key principle in Specify: you can't have a feature without its rules. A feature isn't just a name and a description - it's the complete set of invariants (FRs) and scenarios (UCs with UCRs) that define its behaviour.

A feature cannot exist unless:

Its purpose is clear
Its scenarios are known
Its invariants are defined
Its edge cases are acknowledged
Its constraints are explicit

Globally unique identities

Every use case and requirement gets a globally unique identity within the project. UC7 is always UC7. FR35 is always FR35. UCR12 is always UCR12.

These identities are stable - even if a use case is moved between features or a requirement is reordered. This matters for traceability. When a test references FR35, that reference doesn't break because someone reorganised the specification.

Unique identities are separate from custom order IDs. You might give FR35 the custom ID "PWR-R-01" for your team's conventions, but the underlying unique identity stays FR35.

In practice

The pattern in the Reference Project is consistent across all features:

Feature - bounded behavioural capability with a name and description
Feature Requirements - general rules (FR1, FR2, FR3...)
Use Cases - concrete scenarios (Happy Path, Error Case, Edge Case...)
Use Case Requirements - scenario-specific rules within each use case (UCR1, UCR2...)

In the Reference Project, expand any feature under User Features to see this hierarchy at work. Some features have one use case and a handful of requirements. Others have multiple use cases with detailed step-by-step sequences.

Write Requirements - how to write clear FRs and UCRs
Define Specifications - where requirements are added
EARS Reference - patterns for writing unambiguous requirements