How it works
Nine stages, each checked before the next begins.
ASYST runs a fixed pipeline. Every stage reads the artefacts the stages before it produced, validates its own output against a schema before writing it, and records the links it created on the way. Nothing is generated in isolation, which is why the model is internally consistent when it comes out.
The brief becomes a bounded system.
ASYST reads the brief, statement of work or concept description and pulls out what actually bounds the design: who the stakeholders are and what each of them needs, the operating environment, the regulatory, physical and programme constraints, and the performance drivers that will decide the architecture. It then states a system boundary, so what is in scope, what crosses an interface and what is explicitly out is written down before a single requirement exists.
- Produces a system context record: stakeholders and needs, constraints, operating environment, mission phases and a stated system boundary.
- Governed by the INCOSE SE Handbook stakeholder needs and requirements definition process.
Something concrete to allocate to.
The system is broken into subsystems, each with a stated responsibility and a defined boundary. This exists because everything downstream needs an owner: a requirement is allocated to a subsystem, a function is performed by one, a risk lands on one, an interface runs between two. One decomposition is produced and every later stage allocates against it, so nothing is attributed twice or to something that was never defined.
- Produces a subsystem breakdown, each entry carrying its responsibility and its boundary.
- Governed by MBSE practice: a single decomposition held as the source of truth, rather than a separate structure per artefact type.
Requirements written to be verified, not reworded.
Functional, performance, interface, environmental and constraint requirements, generated from the context and the decomposition. Each one is atomic, uniquely identified, expressed in a single testable statement, and carries the rationale and the source item it came from. The ambiguity that normally gets caught at review, then reworked for a fortnight, is dealt with at the point of writing.
- Produces a uniquely identified requirement set, each entry with a rationale, a source and an allocated subsystem.
- Governed by ISO/IEC/IEEE 29148 and IEEE 830: necessary, unambiguous, singular, verifiable, traceable.
Functions allocated, with the load visible.
What the system must do, expressed as functions, and each function allocated to the subsystem that performs it. Allocation is where a decomposition either holds or does not: ASYST shows the requirement and function count carried by each subsystem, and counts what has been allocated nowhere. A subsystem carrying a disproportionate share is a design decision to make deliberately, not one to discover at integration.
- Produces a function list, the allocation of each function to a subsystem, and the count of unallocated items.
- Governed by the INCOSE SE Handbook functional analysis and allocation process.
Risk read out of the model, not off a workshop wall.
Risks are derived from the artefacts that already exist: requirements with demanding thresholds, constraints in tension with each other, novel technology, interfaces between subsystems built by different teams. Each risk is scored by likelihood and consequence, carries a mitigation, and is attributed to the subsystem it actually lands on, so exposure can be read per subsystem instead of as one list nobody owns.
- Produces a risk register with likelihood, consequence, resulting exposure, mitigation and the subsystem carrying it.
- Governed by the INCOSE SE Handbook risk management process, scored on likelihood against consequence.
Nothing reaches test without a way to pass it.
Every requirement gets a verification method, inspection, analysis, demonstration or test, and an acceptance criterion stated in measurable terms. Where a requirement cannot be given one, that is reported rather than filled in with something plausible. The matrix also surfaces its own debt: entries with no method, no criterion or no responsible party are counted, so the gap is visible while there is still time to close it.
- Produces a verification and validation matrix, one row per requirement, plus the list of entries that are still incomplete.
- Governed by the ISO 29148 verifiability criterion and the INCOSE verification and validation processes.
Components, and the interfaces between them, written down.
The physical components that realise the functions, with each function allocated to the component that performs it, and the interfaces between components defined: what crosses each boundary, in which direction, and under what conditions. Power, data, mechanical and thermal interfaces are stated on paper, which is the only place integration problems are cheap to find.
- Produces a component breakdown with function allocation, and an interface definition for every component boundary.
- Governed by MBSE practice: the physical architecture is derived from the functional one, not drawn independently and reconciled later.
Every artefact knows where it came from.
The links recorded by each stage are assembled into one chain and checked in both directions: stakeholder need to requirement, requirement to function, function to component, requirement to risk, requirement to verification entry, and back again. Orphans are reported rather than tolerated: a requirement no function satisfies, a function no component performs, a requirement with no verification entry.
The chain is also what makes impact analysis possible. The view shown here reads it directly: select a requirement and ASYST lists the functions, components, verification entries and risks that move if it changes.
- Produces bidirectional traceability across every artefact, plus an explicit list of the gaps in it.
- Governed by the ISO 29148 bidirectional traceability requirement.
One document you can take into a gate review.
Every artefact and every link is assembled into a Need Analysis document, exported as DOCX or PDF. Identifiers are preserved end to end, so a reviewer can cite a requirement number in the document and find the same number, with the same links, in the model. The document is a view of the model rather than a separate copy of it, which is what stops the two disagreeing a month later.
- Produces the Need Analysis document, exported as DOCX and PDF.
- Governed by programme record practice: one set of identifiers shared by the document and the model.
Document export becomes a Professional feature at general availability. See the tiers.
Run the pipeline on your own brief.
Free while ASYST is in early access. One brief in, nine artefacts and the chain between them out.
Start free