Some requirements arrive as one sentence. Others arrive as a twelve page document describing an entire product area, and the first real problem is not writing acceptance criteria. It is working out how many separate things are actually in there.
Decomposition is the stage of the ReqLens pipeline that answers that question, and the way it is built reflects a specific belief about where decomposition goes wrong.
The mistake it is designed to avoid
Ask any generation tool to break down a large requirement and enrich each piece in one pass, and it will do it. The output looks reasonable. The problem is that the same pass is deciding two very different things at once: where the boundaries are, and what each piece is like.
Those decisions interfere. Once a model is thinking about priority, complexity and dependencies, it starts adjusting boundaries to make the attributes tidy, and you end up with a feature list shaped by what was easy to describe rather than by what is actually separable.
ReqLens separates them into two stages, and the separation is enforced rather than encouraged.
- Feature discovery. Find the boundaries. Nothing else. The output is a name and a purpose for each feature, and that is all.
- Feature enrichment. Take that fixed list and describe it: MoSCoW priority, dependencies, complexity, and feature type.
Discovery is the sole source of truth for the feature set. Enrichment may not add a feature, remove one, merge two, or split one. Everything after discovery enriches, validates, or normalises; nothing after it redefines what the features are.
It means the feature list you review is the feature list that was reasoned about as a boundary question. If enrichment could quietly split a feature to make the complexity ratings look sensible, you would be reviewing an artefact shaped by a formatting concern.
What happens between the two stages
Two Python checks run in between, and neither involves the model.
Validation, which hard fails. A decomposition returning fewer than two features, a duplicate feature name, an empty name, or a feature with no purpose is rejected outright rather than passed along. These are not warnings. A decomposition that produced one feature has not decomposed anything.
A boundary audit, which is a scored heuristic. This looks for signals that the boundaries are wrong: features that overlap heavily in wording, or share too much of their business vocabulary to be genuinely separate concerns. The signals are weighted and summed. Past a threshold, discovery is retried exactly once with a prompt that pushes harder on outcome separation.
Exactly once matters. If the retry still scores badly, the pipeline proceeds with the best available result and logs a warning rather than looping. A tool that retries until it likes its own answer is a tool that will eventually spend your budget convincing itself.
What enrichment adds
- MoSCoW priority. Must have, should have, could have, will not have.
- Dependencies. Which other features in the set this one relies on.
- Complexity. A relative sizing signal, not an estimate.
- Feature type. Core, supporting, and similar classifications that tell you what kind of thing you are looking at.
Read these as a starting position for a conversation, not as answers. Priority in particular is a Product Owner decision, and no model has your commercial context. What the enrichment stage genuinely saves you is the blank page and the tedium of typing four attributes across fifteen features.
Reviewing a decomposition well
The temptation is to read down the list checking whether each feature looks sensible. Individually they almost always do. The useful review reads across instead.
- Could any two of these ship independently? If not, they are one feature described twice, and the boundary is wrong.
- Does any feature contain the word "and" doing real work? Usually the seam is right there in the name.
- Is anything missing that the source document mentioned? Discovery works from the input, so an omission usually means the input was thin, not that the feature is unnecessary.
- Do the dependencies form a chain that makes the first slice enormous? That is a sequencing problem worth catching now rather than in sprint planning.
Key takeaways
- Boundary detection and attribute enrichment are separate stages, and enrichment can never change the feature set.
- Validation hard fails on structurally broken output rather than passing it along.
- The boundary audit retries at most once, then proceeds with a logged warning rather than looping.
- Enrichment output is a starting position for a conversation, especially priority.
Where it sits in the pipeline
Decomposition produces features. Each feature then goes through elaboration in Requirement Studio, which is where acceptance criteria, business rules, and negative paths get attached. Use cases, test design, execution, and defects follow from there.
So a decomposition is not a deliverable on its own. It is the point where a large piece of scope becomes a set of things that can each be elaborated, tested, and finished independently, which is the property that makes incremental delivery possible at all.