CelinQ Insights · No. 64

From requirements to architecture model: building EA content with AI through CelinQ

A requirements document is not yet a model. Getting from one to the other honestly means admitting how much of it the document does not actually say.

Every architect who has been handed a requirements document at the start of a project knows the peculiar disappointment of reading it closely. It is usually long, usually earnest, and usually far less precise about the architecture than its length suggests. "The system shall allow customers to track their orders in real time" tells you a capability is needed and says nothing about whether that means a new service, an extension to an existing order platform, a notification mechanism, or all three. "The solution must integrate with the existing CRM" names an integration point and leaves entirely open which system component initiates it, what protocol it uses, and what happens if the CRM is unavailable. A requirements document is a statement of intent written by people who were, quite reasonably, thinking about the business problem rather than the architecture that would solve it. Turning it into an actual model is a translation exercise, and like any translation, the places where the source text is vague do not become precise simply because you have started drawing boxes.

This article is about how CelinQ approaches that translation — using requirements text, a project brief, or a written architecture decision as the intent behind a generation request, through the same pipeline described in AI for Sparx Enterprise Architect and demonstrated for shorter prompts in generating a model from a prompt. The mechanism is identical. What differs, and what deserves its own treatment, is the shape of the input and the particular discipline that a longer, vaguer, higher-stakes source document demands from the review step.

Requirements text is just a longer intent

There is nothing architecturally special about a requirements document from CelinQ's point of view — it is intent, the same category of input a short prompt is, just considerably longer and considerably less uniform in how precisely it states what it wants. You select the package the resulting draft should land in, you provide the text — pasted from a requirements document, a project brief, or the written record of an architecture decision — and CelinQ retrieves the relevant model context exactly as it would for a short prompt, so that anything the document references by name that already exists in your repository is recognised rather than duplicated. The AI layer's job scales up accordingly: instead of parsing one clear instruction, it has to read a document that mixes clear statements, vague aspirations, and implicit assumptions, and separate the parts that describe a system's structure from the parts that describe a business goal, a non-functional expectation, or simply background colour that has no architectural content at all.

Extracting systems and actors from prose

The first useful thing a generation pass over requirements text can do is surface the nouns that matter — the systems, actors, and external parties the document actually names or clearly implies, distinguished from the verbs and adjectives that describe what should happen to them. "Customers shall be able to track orders" names an actor (Customer) and implies a capability, but the system that provides the capability is not named at all; it has to be inferred, tentatively, as a new element the proposal creates, clearly marked as new rather than presented as though the requirement had specified it. "The solution must integrate with the existing CRM" names a real, presumably already-modelled system, and the proposal should attach to it if it can be resolved in your repository rather than inventing a fresh CRM element that has nothing to do with the one your organisation actually runs. The distinction between "the document told us this exists" and "we inferred this needs to exist" is not cosmetic — it is exactly the information a reviewer needs in order to know which parts of the proposal to trust more readily and which parts to interrogate.

Interfaces, capabilities, and the gaps in between

Requirements documents are usually more explicit about interfaces than about the components that expose them, because from a business perspective the interface is the part that matters — "must integrate with the payment provider via their published API" says a great deal about an interface and almost nothing about which of your own components initiates the call, how errors are handled, or whether the integration is synchronous or asynchronous. A generation pass can propose the interface and the two systems it connects with reasonable confidence, because the document is explicit about that much, while leaving the finer detail of the integration's internal shape open, because filling in detail the document never provided would mean inventing architecture rather than transcribing it. This is a deliberate and important restraint: the proposal should reflect what the requirements actually specify, at the level of confidence the text supports, rather than manufacturing a fully worked-out design that reads as though the requirements were more precise than they were.

Business capabilities present the same tension in a different shape. A requirements document rarely uses the word "capability" the way an architecture framework does, but it frequently describes capability-shaped groupings of function — "manage the customer relationship," "process a claim end to end" — without ever drawing the boundary explicitly. Where your repository already models capabilities in some form, a proposal can map requirement language onto the closest existing capability rather than inventing a fresh decomposition; where it does not, the honest choice is to surface the grouping as a package or a candidate capability element clearly presented as a proposed reading of the text, not as a settled fact the document itself established.

Detecting what the document did not say

The most valuable output of a requirements-driven generation pass is often not the proposal itself but what the proposal cannot confidently include, because the gap between what a document implies and what it actually specifies is precisely where later rework tends to originate. A requirement that says "the system shall notify customers of delivery delays" implies some notification mechanism exists or needs to be built, but says nothing about the channel — email, SMS, push notification, all three — and a generation pass that quietly picked one would be inventing a decision the requirements never made. The more useful behaviour, and the one CelinQ's preview is built to support, is to surface the element that clearly needs to exist while flagging the specific attribute the text left open, so the missing information becomes visible to the architect reviewing the proposal rather than silently resolved by a guess buried inside a fully-formed diagram.

This detection of missing information is not a separate analytical feature bolted onto generation — it falls out naturally of treating the requirements text honestly as a source with real gaps. A generation pass that tried to eliminate every gap by inventing plausible detail would produce a tidier-looking model and a considerably less trustworthy one, because a tidy model that resolved real ambiguity through invention is more dangerous than a visibly incomplete one, precisely because its incompleteness is no longer visible. CelinQ's proposals are deliberately allowed to look unfinished where the source material was unfinished.

A requirements document that never specified the notification channel does not become specific because a diagram was drawn from it. The honest proposal shows you the gap; a dishonest one would have quietly picked one and hidden the guess inside a finished-looking box.

Producing the draft, not the answer

Carried through the rest of the pipeline, that short passage produces a proposal with perhaps four or five new elements, one or two connectors to existing model content, a requirement or constraint element carrying the retention obligation, and at least one visible gap flagged for the reviewer's attention — the notification channel the third sentence left open. None of that is dramatic. It is exactly the kind of unglamorous, careful transcription an architect would produce by hand from the same four sentences, done in a fraction of the time, with the gap the requirements themselves left open still honestly present rather than quietly closed by a plausible-sounding guess.

What emerges from this process is deliberately called a draft model, and the word is doing real work. A draft is something you expect to revise, something whose purpose is to give you a concrete starting point rather than a finished deliverable, and treating the output of requirements-driven generation with that framing from the outset is what keeps the review step honest. The draft typically contains the systems and actors the text named or clearly implied, the interfaces and integrations the text was explicit about, tentative capability groupings where the text supported them, and — importantly — visible markers on the elements and relationships that were inferred rather than stated outright, so the reviewer's attention is naturally drawn to exactly the places where the requirements were thin.

A short passage, worked through

Abstractions are easier to trust once they have been walked through concretely, so take a short, realistic passage and follow it end to end. Suppose the requirements text reads: "Customers shall be able to submit a claim online and track its status. The system shall integrate with the existing Policy Administration system to verify coverage before a claim is accepted. Claims handlers shall be notified when a new claim requires manual review. The solution must comply with the organisation's data retention policy." Four sentences, and already a representative mixture of the precise and the vague that makes requirements-driven generation genuinely useful rather than trivial.

The first sentence names an actor, Customer, and a capability with two parts — submission and status tracking — but no system. A proposal built from it creates a new element, clearly marked as inferred rather than named, to hold that capability, because the requirement establishes that something must provide it without saying what that something already is. The second sentence is considerably more concrete: it names an existing system, Policy Administration, and describes a specific interaction — verification before acceptance — which the context-retrieval stage should resolve against your repository if a Policy Administration system is already modelled there, attaching a new interface or connector to the real element rather than inventing a second one. The third sentence names another actor, Claims Handler, and implies a notification mechanism without specifying its channel, which is exactly the kind of gap the proposal should surface rather than silently fill with an assumed channel — an email notification would be a plausible guess, but it is a guess, and the draft should say so rather than present it as though the requirement had specified it.

The fourth sentence is the most interesting, because it is not architectural content at all in the sense the first three are — it is a constraint, and a generation pass that tried to turn "must comply with the organisation's data retention policy" into a concrete model element would be manufacturing structure the sentence does not actually describe. The honest treatment is to recognise it as a non-functional requirement or constraint, worth attaching as a note or a requirement-type element linked to the claim-handling capability for traceability, rather than as a component, service, or any other structural construct — a small but telling example of why extracting systems and actors from prose is only half the job; recognising what is not a system or an actor is just as important, and getting that distinction wrong in either direction is where a generation pass earns or loses an architect's trust the fastest.

Human review, sized to the stakes

Requirements-driven proposals tend to be larger and more consequential than a short prompt's proposal, which changes what the review step needs to do. A three-tier skeleton generated from a one-sentence request is easy to check against the sentence that produced it; a draft model generated from a twelve-page requirements document demands that the reviewer actually re-engage with the source material, checking not only whether the proposal is structurally sound but whether it represents the requirements fairly — whether an inferred element genuinely follows from what was written, or whether the generation pass reached further than the text actually supported. This is a heavier review than the pipeline asks of a short prompt, and it should be treated as such rather than approved with the same light touch a small, unambiguous change might reasonably receive.

The same deterministic validation described throughout this series still runs underneath every proposal regardless of its size — parents exist, relationship endpoints resolve, no containment cycles, identities stay unique — and a requirements-driven proposal is no more able to violate those invariants than a one-line prompt is. What validation cannot do here, any more than it can for a shorter request, is judge whether the draft is a fair and complete reading of the requirements, because that judgement depends on the document's business content, which is precisely the kind of thing structural rules were never built to assess.

Applying approved changes and what happens next

Once reviewed and approved, a requirements-driven proposal applies through the identical mechanism as any other: an ordinary semantic ChangeSet, producing a canonical revision in the shared workspace's ordered history, synchronising to local EA repositories through the same background agent and add-in path covered in the series' broader discussion of AI-for-EA. There is no special status attached to a large, requirements-derived batch of content beyond the size of the review it received on the way in — once applied, it participates in Fusion's merge logic and the Control Plane's revisions view exactly as any hand-modelled content would, and a colleague who later edits an element the draft created is simply editing a model element, with no memory in the system of whether its origin was a requirements document or a manual click.

Traceability back to the source

For governance-conscious teams, the question that follows naturally from all of this is whether a given element in the model can be traced back to the specific requirement that produced it. The honest answer is that the proposal itself is the trace: it was generated from the exact text you submitted, it is held and shown in full at review time, and once approved it becomes a canonical revision with a recorded author, timestamp, and change description in the workspace's ordered history — the same audit discipline covered in the series' treatment of proof-carrying merges and revision history applies here without modification. What CelinQ does not claim is a dedicated, line-by-line citation mechanism linking every individual element back to a specific sentence in the source document as a first-class, queryable feature; where that level of granularity matters, the discipline of keeping the requirements text and the generated proposal together as part of the review record — a habit any team can adopt regardless of tooling — is what closes the gap, and it is a considerably lighter habit to maintain than the alternative of reconstructing, months later, why a particular element exists from memory alone.

Where this fits alongside the rest of the project

A draft built from requirements is also a natural candidate for the kind of standing analysis described in AI-assisted model analysis, once it has been through review and applied — the same orphan and missing-relationship checks that catch drift in a hand-built model apply just as well to one whose first draft happened to come from a document.

Requirements-driven generation is most useful early, at the point where a project has words but not yet a model, and it is worth being clear that it is a starting point rather than a substitute for the modelling discipline that follows. A draft built this way still needs the same scrutiny any first-pass architecture deserves: stakeholder review, comparison against constraints the requirements document did not think to mention, and the ordinary iteration that turns a first cut into something a team is willing to build against. What changes is where that iteration starts from. Instead of an architect spending the first day of a project manually transcribing a lengthy document into packages and elements before the real thinking about the architecture can even begin, the transcription happens in minutes and the team's attention goes straight to arguing about whether the draft's interpretation of the requirements is the right one — which is a far better use of the first day than data entry.

The honest limits

The central limit of this capability is the same one that runs through the whole series, restated for a case where it matters more than usual: a generated draft's quality is bounded by the quality of the requirements text itself, and a document that is vague, contradictory, or aspirational rather than concrete produces a draft that inherits exactly those qualities, faithfully rather than helpfully. No amount of careful gap-detection turns an underspecified requirement into a specified one; it only makes the underspecification visible rather than silently resolved, which is a real improvement over guessing but not the same thing as fixing the requirements document, and it is not a substitute for the workshop conversation that should happen when the gaps turn out to matter.

There is also a scale limit worth naming. A short, focused requirements section produces a draft an architect can review thoroughly in the time it deserves. A sprawling, hundred-page requirements corpus fed through the same mechanism produces a proportionally large draft, and the review discipline this article insists on becomes correspondingly harder to sustain in practice — a large draft is exactly where the temptation to skim the preview and approve on trust is strongest, and exactly where that temptation is most dangerous, because a misreading buried in element four hundred is no less consequential than one buried in element four, only harder to notice. Teams working from large requirements corpora are better served by feeding them through in sections, each with its own focused review, than by asking for one enormous draft and hoping the review step scales to match.

And as throughout this series, the capability is optional and gated: nothing here runs unless an administrator has explicitly enabled AI-assisted generation for the workspace, and a restricted or Sovereign-mode workspace can keep it off entirely while requirements are still translated into models the traditional way, by an architect reading the document and building it by hand. What the capability changes, when it is enabled and used with the review discipline it asks for, is not whether requirements still need careful human interpretation — they always will — but how quickly that interpretation can become a concrete, inspectable model rather than staying trapped in prose for the first week of a project.