Subsystems and propagation
How a project is split into subsystems, how a subsystem's requirements trace to the system's, and how they are drafted for each part.
The system and its subsystems
A project starts as one system. A subsystem is a part of it with requirements of its own: a mobile app and its backend, say, or billing and scheduling. A requirement with no subsystem is a system requirement, about the whole. A subsystem requirement says what one part does to meet a system requirement, and traces up to it: the table's Source Requirements column names its parents.
Once a project has more than 20 requirements, the Spec score expects it to be split, and holds the score at 70 until it is. The Overview then suggests Split into subsystems.
Creating subsystems
On the Requirements page, open the subsystem panel at the left of the table and select Manage Subsystems. There you can Add Subsystem by hand, or have Auto-detect find them with AI: new subsystems, changes to the ones you have, and the interface contracts between them. Once there are subsystems, More granular and Less granular split or merge them.
- In the app, Auto-detect applies what it finds at once.
- It may move subsystem requirements between subsystems. System requirements stay where they are.
- It never moves a locked requirement, or removes a subsystem that holds one.
Choose a subsystem in the panel to see only its requirements, or System Requirements for the ones about the whole. View All shows every requirement, grouped by subsystem.
Requirements for each subsystem
A subsystem's requirements are drafted from the system requirements, with AI, and each one traces to its parent:
- Generate for a subsystem, with it chosen in the panel, drafts its requirements. The system requirements have to exist first. For a subsystem with none yet, they are saved at once; otherwise they come as suggestions to review.
- Propagate to requirements, on the Stories page, drafts system requirements from stories. With Also propagate into subsystem requirements ticked, as it is once there are subsystems, a second pass drafts the subsystem requirements under them. Everything comes as suggestions to review, and the second pass uses more credits.
- A coding agent can also propagate chosen system requirements into the existing subsystems, over MCP. It gets a proposal, and applies what you agree to.
For experts: decomposition and flow-down
Splitting a system into parts, and its requirements with them, follows systems engineering. ISO/IEC/IEEE 15288:2023 calls the whole the system of interest and its parts system elements, and defines the parts in its system architecture definition process (6.4.4). Entalpa's subsystems are those elements, one level down.
| In Entalpa | Based on |
|---|---|
| A subsystem requirement under a system requirement | Allocation and flow-down: a requirement is allocated to the parts that meet it, and each part gets child requirements that together meet the parent's intent (INCOSE Needs and Requirements Manual, 6.4). The trace from child to parent is the path upward in ISO/IEC/IEEE 29148:2018's definition of requirements traceability (3.1.23). |
| Auto-detect's subsystems | The model is asked for subsystems that each do one thing and depend on each other little: cohesion and coupling, as Stevens, Myers and Constantine (1974) explained them. Each has to be justified by a stakeholder need, verifiable against its own requirements, and connected to the others only through defined interfaces. |
| Revising the split | Requirements and architecture are worked out together, each refining the other: the Twin Peaks model (Nuseibeh, 2001). More granular, Less granular and Auto-detect revise the split as the spec grows. |
| Drawing a boundary by hand | Put each design decision likely to change inside one part, so that a change stays there: Parnas's criterion of information hiding (1972). |
Where Entalpa departs from these sources, it says so:
- One level. In systems engineering a part can be a system in turn, to any depth: the INCOSE handbook's hierarchy within a system. Entalpa has the system and its subsystems, nothing below.
- No budgets. Flow-down can also split a quantity among the parts, such as a response time: budgeting, in the INCOSE manual (6.4.5). Entalpa drafts each part's requirements in words, and does not check that the parts' figures add up to the whole.
- The numbers are rules of thumb. Expecting subsystems past 20 requirements is Entalpa's own choice. Auto-detect aims for about seven subsystems, after Miller (1956) on how many items people can hold in mind at once, which the INCOSE handbook cites for the same purpose.
References
- ISO/IEC/IEEE 15288:2023. Systems and software engineering: System life cycle processes.
- ISO/IEC/IEEE 29148:2018. Systems and software engineering: Life cycle processes, Requirements engineering.
- INCOSE (2024). Needs and Requirements Manual, revision 2.0. INCOSE-TP-2021-002-01.
- INCOSE (2023). INCOSE Systems Engineering Handbook, 5th edition, edited by D. D. Walden et al. Wiley.
- Stevens, W. P., Myers, G. J. and Constantine, L. L. (1974). Structured design. IBM Systems Journal 13(2), 115–139.
- Nuseibeh, B. (2001). Weaving together requirements and architectures. Computer 34(3), 115–119.
- Parnas, D. L. (1972). On the criteria to be used in decomposing systems into modules. Communications of the ACM 15(12), 1053–1058.
- Miller, G. A. (1956). The magical number seven, plus or minus two: some limits on our capacity for processing information. Psychological Review 63(2), 81–97.