Features & Feature Sets
A feature in Specify is a bounded behavioural capability. Not a work item. Not a user story. Not a backlog entry. A feature is any event, action, concurrent process, constraint or resource in your product that needs to be defined.
What counts as a feature
This is broader than most people expect. Features include:
- User interface interactions - pressing buttons, changing settings, reading displays
- Communications protocols - are protocol sequence dialogues with interactions, i.e. for Bluetooth, MQTT, UART etc.
- Background processes - scheduled diagnostics, periodic backups, watchdog timers
- Memory management - flash partitioning, bootloader allocation, configuration storage
- Diagnostic interventions - debug services, error logging, test modes
- Control software - motor control, sensor sampling, state management
- Hardware-software interfaces - hardware and firmware assumptions, hardware constraints, timing requirements
Feature categories
Every feature falls into a category that describes the type of behaviour it represents:
Feature Dialogue - an interaction between the user (or a protocol) and the system. These define all the steps from the start to the finish of a feature activation. In the Reference Project, "Cancel Baking Session" under User Features is a feature dialogue - it describes the complete interaction when a user cancels a baking session. Feature dialogues also apply to protocol interactions: the features offered by a Bluetooth API, for instance, would each be a feature dialogue.
Event Processing - handling scheduled or triggered events. The Timed Event Management feature set in the Oven Project contains two event processing features: managed frequency scheduled events (run every N milliseconds) and managed time/date scheduled events (run at a specific time on a specific day). These are different patterns - frequency scheduling uses a frequency-scheduled virtual state machine, while time/date scheduling uses an event-scheduled virtual state machine.
State Handler - managing system states and transitions. In the Oven Project, "UFC State 1 Cold Start" and "UFC State 3 Oven Off" are state handlers that define what the system does in each state and how it transitions between them.
Device Configuration - hardware configuration or setup. The Memory Management feature set in the Oven Project has device configurations for bootloader memory partitioning, application memory, configuration memory, and firmware update memory. These describe the physical characteristics of the system - start addresses, end addresses, allocation sizes etc.
Hardware-Software Interface - the boundary between firmware and hardware. Features in Firmware Assumptions, Hardware Assumptions, and HW Timing Constraints make explicit what each side expects from the other.
Feature sets as logical components
Feature sets group related features into components. The naming convention in the Reference Project signals what kind of component each set represents:
ALL CAPS - system-level infrastructure. CLOCK DOMAINS, COMMS PROTOCOL, DEBUG SERVICES, INTERRUPT HANDLING, MEMORY MANAGEMENT, POWER CYCLE CONTROL, POWER SAVING, RESET BEHAVIOUR. These are the feature sets that most embedded systems need regardless of product.
Title Case - product-specific behaviour. Control Panel, Display, Error Handling, Oven Control, Sensors, Timed Event Management, User Features. These define what makes this product an oven rather than something else.
This distinction matters for several reasons. When starting a new project, the ALL CAPS list is a checklist of system concerns to consider. Product-specific sets are where your unique product behaviour lives. And feature sets can be included in or excluded from product variants - the base product ships with 15 feature sets, the premium version with 19.
Feature sets as build components
Feature sets aren't just logical groupings - they're units of work. Each feature set can be:
- Worked on independently by a team or individual
- Outsourced with a complete specification as the contract
- Tested as a component using the requirements within
- Reused across product variants by including or excluding the set
Related
- System Definition - the bigger picture
- Requirements Hierarchy - how requirements work within features
- Glossary - definitions of all feature categories
Need help? Contact us · Return to home