1. Problem statement
Requirements specifications commonly define enumerations, closed lists of permitted values, in a data dictionary, and individual fields reference them. A recurring situation: a field must accept only a subset of an existing enumeration, five of six values say, either always or under a given condition.
Two modeling options compete:
- Option A: define a new, narrower enumeration containing only the permitted values.
- Option B: keep the reference to the full enumeration in the data dictionary and express the restriction as a separate business rule (constraint).
The choice has consequences. Option A multiplies near-identical enumerations, creates a synchronization burden when the base list changes, and hides the semantic fact that the values belong to one concept. Option B keeps a single source of truth but scatters restrictions across rules, and tooling (code generation, validation) must combine two artefacts to know the effective value set. The question: under what criterion is a new enumeration justified?
2. Positions in the literature
No source addresses enumeration subsets in requirements documents directly. The question maps onto the well-studied problem of subtyping: when does a restricted value set deserve to be a named type of its own?
Conceptual data modeling. Hoffer, Ramesh and Topi define a subtype as a subgrouping of the entities in an entity type that is meaningful to the organization and that shares common attributes or relationships distinct from other subgroupings. The defining criterion is business meaning, not the mere existence of a restriction. Simsion and Witt take the same position: subtypes are introduced for classifications significant to the business, and are also a device for representing rules and managing complexity; they warn against subtyping for every constraint, and note that implementation-level models should generally be subtype-free.
Type systems. In typed languages the same distinction is built into the syntax: a restricted range of values is declared as a subtype with a constraint over a base type, not as an unrelated new type (Ashenden, on VHDL subtypes). The subtype inherits the operations and the identity of the base type; the constraint documents intent and enables checking, but does not create a new concept.
Schema standards. W3C XML Schema formalizes the same idea as derivation by restriction: a datatype may be narrowed with an enumeration facet, and the derived type remains formally related to its base. A named derived type is created when the restriction is reused; a one-off restriction is expressed as an anonymous inline type. UML offers the parallel mechanism of generalization sets and powertypes, and OMG’s KDM likewise treats value domains as first-class only at the level of meaningful abstractions.
3. Proposal
Synthesizing the above into a decision rule for requirements practice:
- Default: one enumeration, restriction as a rule. The data dictionary entry references the full enumeration; a business rule states the restriction (“field X does not accept value Z”, or “only {A..E} are permitted when condition C”). This mirrors derivation by restriction and keeps a single source of truth.
- A new named enumeration is created only when the subset passes a business-meaning test, operationalized as all of:
- the subset has a name that domain experts already use in conversation (it is a concept, not just a filter);
- the subset is referenced from more than one place in the specification;
- the subset is expected to evolve independently of the base list.
- When a new enumeration is created, it must be documented as derived from the base enumeration (an explicit “restriction of” relationship), so that changes to the base list trigger a review of the derived list. An unlinked copy is the anti-pattern to avoid.
- Conditional restrictions (the subset applies only in some context) are always Option B: the condition is inherently a cross-field rule and cannot be expressed by a type alone.
The rule keeps the number of enumerations proportional to the number of business concepts, not to the number of constraints, while preserving traceability from every restriction to its base list.
4. Limitations
The business-meaning test is a judgement call; the three operational criteria reduce but do not eliminate ambiguity. Tool support matters: Option B assumes validation tooling can combine dictionary and rules, which is true of modern schema languages (XML Schema facets, JSON Schema enum plus conditional keywords, OCL constraints in UML) but not of every requirements management environment.
Sources
- Hoffer, J. A., Ramesh, V. & Topi, H. Modern Database Management. Pearson. Chapter: The Enhanced E-R Model (supertype/subtype definitions).
- Simsion, G. & Witt, G. (2005). Data Modeling Essentials, 3rd ed. Morgan Kaufmann. Chapter 4: Subtypes and Supertypes.
- Ashenden, P. (2008). The Designer’s Guide to VHDL, 3rd ed. Morgan Kaufmann. Subtype declarations. Overview: Enumeration type.
- W3C. XML Schema Part 2: Datatypes. Derivation by restriction, enumeration facet.
- OMG. Unified Modeling Language (generalization sets, powertypes).
- ISO/IEC/IEEE 29148 (2018). Requirements engineering (data dictionary and requirements quality context).