Overview

Features describe the externally observable services, capabilities, and characteristics provided by the system that directly fulfill one or more stakeholder needs. Each feature document defines what the system does from a business and domain perspective, without prescribing implementation details.

Role in the Product Lifecycle

Features are the first artifact in the specification pipeline. New capabilities are defined here at a high level and reviewed with stakeholders before detailed work begins. Once a feature is agreed, Use Cases are written to specify the behavioral scenarios in detail. Use cases then drive design and implementation.

Feature (what the system does)
  → Use Cases (how personas interact with it)
    → Design & Implementation

For existing capabilities that were built before this workflow was established, feature documents are backfilled to provide the missing high-level context that the use cases assume.

Taxonomy

Features are organized using the same three-level taxonomy as use cases: Domain > Area > Feature. The first two levels (Domain and Area) mirror the Use Cases structure so that readers can navigate between the feature-level description and the detailed behavioral scenarios for the same capability.

Level	Example	Description
Domain	GEN (General Behaviors)	Top-level functional grouping
Area	MEDIA (Entity Media)	Coherent capability group within a domain
Feature	Entity Media Management	A specific system capability

Below the feature level, the document is organized into narrative sections covering the capability from the user’s and domain expert’s perspective.

Requirements

Each feature document contains requirements — specific, testable statements about what the system must do. Requirements are labeled with a stable identifier scoped to the feature:

• Functional requirements: <DOMAIN>::<AREA>::FR-NNNN (e.g., GEN::MEDIA::FR-0001)
• Non-functional requirements: <DOMAIN>::<AREA>::NFR-NNNN (e.g., GEN::MEDIA::NFR-0001)

Requirement identifiers are unique within their feature prefix and are immutable once assigned. Requirements are written in terms of business and domain concepts (manufacturing operations, logistics workflows, standard SaaS/enterprise interaction patterns) rather than implementation technology — unless a technical detail is part of the external specification (e.g., a specific protocol or integration standard).

Writing Guidance

Feature documents should be written for a business subject matter expert — someone who understands the operational domain (manufacturing, logistics, procurement) and is familiar with enterprise SaaS applications, but who is not a software developer.

• Describe behavior in terms of what the user or system does, not how it is implemented.
• Use domain vocabulary (items, suppliers, purchase orders, kanban cards) rather than technical vocabulary (APIs, database tables, microservices).
• Include technical details only when they are part of the external specification (e.g., supported file formats, protocol requirements for integrations, compliance standards).
• Keep feature documents concise. A single feature document covers the full scope of a capability; detailed interaction scenarios belong in Use Cases.
• Link to the corresponding use case pages so readers can navigate to the detailed behavioral specifications.

Current Feature Documents

Domain	Feature	Description
GEN::MEDIA	Entity Media Management	Cross-cutting image attachment, replacement, and removal for entities
REF::ITM	Item Management	Catalog record lifecycle for stocked consumables and materials

---