Two engineers extract features from DCRouter's specification. One produces four: "routing", "arbitration", "registers", "low power". The other produces 160, one for every sentence and every register field. The first list is too coarse to tell whether anything is verified; "arbitration" could mean one test or fifty. The second is too fine to manage and still misses things, because the riskiest behaviours (two features interacting) are not sentences in the specification at all.
How do you turn a specification into features a plan can track?
The obvious method walks the specification's headings and makes each a feature. Headings follow how the document was written, not how the design can fail: they group by topic, ignore interactions, and rarely list error behaviour, configurations or performance as separate items. A good feature list is organised by what must be checked.
Source | Question | DCRouter features |
|---|---|---|
Functions | What does it do with normal input? | Forward whole packets; per-flow order; length handling; CRC check |
Interfaces | What does each port promise and require? | Valid/ready ingress; credit egress; APB access |
Configurations and modes | What can be set, and what changes? | Port enable; priority enable; low-power enable |
Errors | What happens with bad input or conditions? | Bad CRC; length 0; unmapped address; counter saturation |
Interactions | What happens when features overlap? | Priority and fairness together; sleep with traffic in flight; clears during counting; simultaneous tails |
Non-functional | How fast, how fair, how much power? | Throughput; bounded waiting; sleep entry and wake latency |
One feature, one check, one coverage goal: if a feature needs several unrelated checks, split it; if two features share every check, merge them.
Every rule maps to at least one feature (DCRouter's R1 to R13 from lesson 2.2), and every feature traces to at least one rule.
Interactions are features of their own: they are where bugs hide (lesson 1.9) and they appear in no single section.
Typical size: a block has tens of features, not four and not hundreds; DCRouter has about thirty (lesson 9.8).
What happens at reset, and in the first cycles after it?
What happens at every limit: full, empty, zero, maximum, saturation?
What happens when two things happen in the same cycle?
What happens in every mode, and when the mode changes mid-operation?
What does the software do with this block, step by step?
These are lesson 2.5's specification-review questions, used a second time: every silence they expose is either a specification bug or a missing feature.
Practice | Purpose |
|---|---|
Feature extraction workshops with designers and architects | Intent and interactions the document does not state |
Feature lists linked to specification sections and requirement IDs | Traceability from the start |
Explicit interaction and error sections in the plan | The categories headings usually miss |
A plan (illustrative) extracted features from a DMA engine's specification chapter by chapter: descriptors, channels, interrupts, errors. Each was verified thoroughly. The bug was a descriptor completing on one channel while another channel's error interrupt was being cleared: an interaction between two chapters, listed in neither. An "interactions" section in the feature list, filled by asking which features share state, would have named it.
For example: sleep entry while a packet is in flight (low power and forwarding), and clearing a counter in the same cycle it increments (registers and error counting).
It hides several separately checkable behaviours (round-robin rotation, priority, priority disabled, fairness bound), so "arbitration verified" says nothing about which were.
Extract features from functions, interfaces, configurations, errors, interactions and non-functional requirements.
Cut each feature to one check and one coverage goal; make interactions explicit features.
Use the specification-review questions to find features the document never states.