Skip to main content

The Mission

Every application in REQQA begins with a mission statement. It is not a description you write once and forget — it is the anchor of the entire requirements hierarchy. Every requirement you create, and every story generated beneath those requirements, sits underneath the mission and inherits its context. When REQQA analyses a requirement or generates stories, it reads the mission to understand what the application is for.

That single fact drives everything else on this page: the quality of your analysis depends on the quality of your mission. A thin mission gives the analysis engine almost nothing to reason with; a comprehensive one gives every downstream artefact a rich, shared context to draw on.

Why the mission is the anchor​

REQQA organises an application's knowledge as a hierarchy. The mission is at the top, requirements hang beneath it, and stories and features hang beneath the requirements. Context flows downward: a requirement does not need to restate who the users are or what is out of scope, because that lives in the mission and is available to every analysis that runs.

This is why a vague mission is expensive. When the analysis engine examines a requirement and finds an ambiguity, a missing user class, or an unstated assumption, it is comparing the requirement against the world the mission describes. If the mission does not describe that world, the engine cannot tell whether a requirement is complete, consistent, or in scope — so the findings are weaker and the generated requirements and stories are blander.

tip

Treat the mission as the foundation, not a form to clear. Time spent here pays back many times over in the quality of everything REQQA produces below it.

The mission is analysed in its own right​

The mission is not just reference material — REQQA analyses it the same way it analyses requirements. From the mission analysis page, you can run a dedicated mission analysis that applies the DeFOSPAM technique to the mission text itself, surfacing gaps, ambiguities, and unstated assumptions before they propagate into requirements.

Two things follow from this design:

  • Length matters. The mission must carry enough content to be analysable. REQQA will not run a mission analysis on a near-empty statement; there must be real substance to examine.
  • The mission gates requirements generation. Before REQQA will generate requirements from a mission, a mission analysis must have completed with no high-severity issues left open. In other words, you are expected to get the mission into reasonable shape — analysed, with serious problems resolved — before you build the requirements that depend on it.

This makes the mission the first quality gate in the workflow, not an afterthought. See the analysis engine chapter for how analyses, issues, and severities work, and background jobs for how an analysis runs.

The eight-section structure​

When you create an application, REQQA pre-fills the mission field with a guideline template: eight headings, each with a short note describing what to write. You replace each note with your own content. The same template is seeded on every app-creation path, so the structure stays consistent across your organisation.

The eight sections are:

  1. Business Purpose — what the application is, who it is for, and the outcomes it delivers, in plain terms rather than features. State what it is not responsible for, so its boundaries are clear.
  2. Business Scope — what is in scope, what is out of scope (and which other system handles it), and the envelope: where, when, by whom, and at what volume the application is used.
  3. Stakeholders and User Classes — everyone with an interest in the system and what each needs from it, then the distinct user classes that actually touch the software. These shape requirements and stories directly.
  4. Operational Concept — how the application works end to end in normal operation: the inputs, the processing, the outputs, and how the parts fit together. The happy-path narrative.
  5. Scenarios — concrete walk-throughs of the situations the system must handle: not only the routine case, but errors, degraded cases, unusual requests, and setup or decommission. Scenarios are where the real requirements hide.
  6. Assumptions — what you are taking as given: dependencies, pre-conditions, environment, things provided by others. Each assumption is a risk if it turns out to be false, so make them explicit.
  7. Constraints — the limits the solution must respect: operational (performance, availability, usability), commercial or organisational (budget, timescale, policy), and technical (mandated technology, interfaces, data formats).
  8. References and Applicable Standards — any standards, regulations, or policies the application must conform to, with a note on how each applies. Keep the heading even when it is empty.
note

You do not have to fill every section to the same depth, but aim to say something real under each. The Scenarios and Stakeholders and User Classes sections, in particular, do a disproportionate amount of work in shaping good requirements.

How the mission relates to releases and the glossary​

Two further connections are worth understanding at the conceptual level:

  • The glossary. Terms used in the mission are indexed into your organisation's glossary, so the vocabulary of the mission becomes part of the shared dictionary that keeps requirements and stories consistent.
  • Releases and scopes. The mission describes the whole application; a release carves out the subset of requirements you intend to deliver next. The mission's scope envelope is where you note what is deliberately reserved for a later increment — the boundary between "this application" and "this release".

Putting it into practice​

This chapter explains why the mission matters and what the eight sections are. For the practical detail — how to edit the mission, how deep to go, and what good looks like — see the two companion pages: