Skip to main content

ConOps, ICD, Risk Register and SEMP

What they do​

Four documents that a NASA- or INCOSE-style process expects at the front of a programme, and that most hardware teams either skip or keep in a Word file nobody opens again:

  • ConOps (Concept of Operations) — what the system is for, who operates it, and what a day in its life looks like, before anyone argues about implementation.
  • ICD (Interface Control Document) — the contract between two things that have to connect: signals, protocols, power, mechanical, and who owns each side.
  • Risk Register — programme and technical risks with likelihood × consequence, ownership, and mitigation.
  • SEMP (Systems Engineering Management Plan) — how the engineering will actually be run: reviews, gates, verification approach, roles.

Why it matters​

These are the documents that make requirements defensible. A requirement with no ConOps behind it is a guess; an interface with no ICD is an integration failure scheduled for later. They are also the artifacts an auditor, a prime contractor, or a serious investor asks for first — and the ones a small team is least likely to have the hours to write from scratch.

Creopus drafts each from your system context and keeps them in the same change-controlled graph as everything else, so they are living documents rather than a folder from kickoff week.

How they connect to the rest of the platform​

The point is not four more documents. It is that they are wired into the same artifact graph:

Interface Control Document listing nine interfaces, each with its endpoints, a POWER or DATA class, owning parties on both sides, a verification status of VERIFIED or IN-WORK, and an AGREED disposition

An ICD derived from a block diagram. Every interface names both endpoints and both owning parties, and carries its own verification state — seven verified, two still in work. That per-interface status is what turns an ICD from a document into a tracked contract.

  • ICD from a Block Diagram — an ICD can be derived directly from an existing block diagram, turning the connections you already drew into interface stubs to fill in, instead of a blank table.
  • Risk Register from DFMEA — high-RPN failure modes from a DFMEA can be pulled into the Risk Register as programme risks, so a design-level finding does not stay trapped in an FMEA spreadsheet.
  • Risk matrix — the register renders as a likelihood × consequence heat map, not just rows.
  • Every one of them supports the full platform workflow: revisions, baselines, structured review with sign-off, hierarchy linking, and traceability.

Where they sit in the V-model​

ConOps and SEMP belong at the top of the left-hand side, before requirements have hardened. The ICD arrives as soon as the architecture has more than one box. The Risk Register runs the whole length of the programme and is the one most worth keeping open.

Attach each to the appropriate node in your system hierarchy and they inherit that node's team permissions and review workflow automatically.

Getting started​

Each tool follows the same two authoring paths as everything else: generate a first draft from a prompt plus your node context, or start from the structure and write it yourself. Most teams generate the ConOps and SEMP, and hand-author the ICD — because interfaces are where the details are load-bearing and worth arguing over line by line.