Skip to main content

Writing mission statements that pass analysis

When you'd do this: after drafting your mission, before you run Analyse Mission — or when a mission analysis has come back with more findings than you expected.

Writing your application mission covers what to put in each of the eight sections. This page covers something narrower and more practical: how to write so that REQQA's mission analysis finds real problems and not noise — and how to tell the difference when it doesn't.

Mission analysis runs six checks: M-V (a readiness gate), R-D, R-G, R-A (definitions, goals, ambiguity — the same analysers requirements use), and M-M / M-B (mission-specific completeness and boundary checks). See What each analysis step looks for for the full picture. Each of the six has a different idea of "good", and each rewards a slightly different writing habit.

tip

None of this is about hiding problems from the analyser. A mission with genuine gaps should get findings — that's the analysis doing its job. This page is about not generating false findings through writing habits that are easy to fix once you know what triggers them.

Six checks, six habits​

M-V — say something under every heading, even briefly​

M-V is deliberately generous: it asks "is this good enough to generate requirements from", not "is this perfect". It fails a section only when it is genuinely thin or absent. The single most common cause of an M-V finding is a section left as the placeholder guidance text, or skipped because it felt inapplicable. If a section genuinely doesn't apply, say so explicitly — "None; this system has no regulatory obligations" is a complete section. An empty one is not.

R-D — define load-bearing terms, and use one word per concept​

R-D looks for undefined terms and inconsistent terminology. Two habits avoid the findings this raises:

  • Pick one term for each concept and use it everywhere. If your first paragraph calls it a "case" and section 4 calls it an "application" and section 6 calls it a "matter", that is three terms for one concept — R-D will flag the inconsistency, and correctly so: a requirements author reading this later won't know if they're the same thing either.
  • Define domain-specific or organisation-specific terms on first use, briefly, in parentheses — not in a separate glossary section (the mission doesn't have one; that's what REQQA's own glossary is for once terms start appearing in requirements). A term used once and never explained reads as undefined because it is.
  • Terms already defined by a cited standard or regulation don't need re-defining — R-D treats a citation as a definition. "ALARP, per the Safety Case Guidance" is fine on its own; "ALARP" with no source is not.

R-G — name who benefits and who is affected, even at class level​

R-G asks whether the business goal and the user roles are clear. It is satisfied by naming classes of stakeholder and user, not individuals — "regulatory case manager", "first-time applicant", "policy owner" are enough. What triggers a finding is a capability described with no indication of who it's for or why it matters: "the system tracks case status" says what, not who needs it or what happens if they don't have it.

R-A — replace vague qualifiers with a number, a source, or an explicit "TBD"​

This is the check most mission statements trip on, and the fix is almost always the same shape. Words like sufficient, appropriate, reasonable, roughly, as needed, in a timely manner read naturally in prose but are unverifiable — a requirements author (human or AI) reading them later has nothing to build a test against. Each one is a candidate finding. Three ways to fix a vague qualifier, in order of preference:

  1. Replace it with a number or a named source. "Sufficient compute capacity" → "capacity sized to the population and load envelope stated in Section 2, reviewed quarterly." "In a timely manner" → "within 10 seconds" or "by the next business day."
  2. If you genuinely don't know the number yet, say that instead of reaching for a softer word. "The interactive response target has not yet been agreed — assume 10 seconds pending stakeholder confirmation" is an honest, analysable assumption. A vague qualifier hiding the same uncertainty is not.
  3. If a document elsewhere fixes the number, cite it rather than restating a fuzzy version. R-A (and R-D) both treat a citation as resolving the ambiguity.

Also worth a pass: contradictions between sections. R-A checks that a strict claim in one place ("zero tolerance for a false indication of completeness") isn't undercut by a looser one elsewhere ("citation accuracy of at least 98%") without acknowledging the gap between them. If your mission has two numbers that could conflict, say explicitly how they relate.

M-M — fill every mission-level section with real substance, but stop there​

M-M checks the same eight sections the template asks for: purpose, scope, stakeholders, operational concept, scenarios, assumptions, constraints, references, success criteria. It is satisfied by substance at mission altitude — a stated stakeholder class, a named constraint category, one real scenario per major situation the system must handle. It is never satisfied by implementation detail, because it never asks for any:

  • Don't try to pre-empt an M-M finding by adding algorithms, data schemas, API shapes, or acceptance criteria "just in case." M-M doesn't check for these, and adding them blurs the boundary between the mission and the requirements you haven't written yet — which makes the requirements-generation step worse, not better.
  • Do make sure Assumptions and Scenarios in particular carry real content, not the placeholder note. These two sections do disproportionate work: a thin Assumptions section is the single most common M-M finding, because it's the section people skip when they're in a hurry, and it's genuinely load-bearing — everything downstream inherits whatever the mission assumed.

M-B — every number you state should say what happens at its edge​

M-B only looks at boundaries you put in the mission — a stated capacity, a service window, an accuracy target, a budget figure. It does not invent edges for capabilities you mention with no number attached, so the fix here is the mirror image of the R-A fix above:

  • For every number you state, add one sentence about its edge. If you write "up to 40 concurrent users," add what happens at the 41st — even "not supported in this release" is enough to close the finding. If you write "200 documents or 2GB per case, whichever is reached first," say what happens when a case hits it.
  • You don't need to do this for every capability — only for the ones you gave a number to. "The system scans uploads for malware" with no size or time limit stated will not raise an M-B finding, because there's no boundary in the sentence for M-B to examine the edge of. Adding a number without also stating the edge behaviour is what creates the finding — so if you're not ready to say what happens at the edge, it is sometimes better to leave the number out of the mission and let the requirement that eventually covers it settle both together.

A worked fix​

Before (raises R-A: vague qualifier; M-B: no edge behaviour once you add a number):

The system must respond to interactive requests promptly, and support a reasonable number of concurrent users during business hours.

After:

Interactive requests complete within 10 seconds under normal load. The service supports up to 40 concurrent interactive users; a 41st concurrent session is queued rather than rejected. Service hours are 07:00–19:00 on working days; requests outside this window are accepted but processed asynchronously.

The second version is longer, but every clause in it is something a requirements author — or REQQA — can act on directly. That's the target, not length for its own sake: a short mission with numbers and edges stated is worth more than a long one without them.

Worked example​

See Example: a systems-consolidation mission for a complete mission written with all six checks in mind, for a fictional healthcare provider replacing a fragmented estate of legacy systems — a shape closer to a consolidation programme than the everyday-application example on the general worked example page.

Result​

A mission where every analysis finding is telling you something you didn't already know, rather than restating a writing habit you could have fixed on the first draft.