Skip to main content

Writing your application mission

When you'd do this: when you create a new application, and whenever its purpose, scope, or stakeholders change.

The mission statement is the most important thing you write in REQQA. It is the top of your requirements hierarchy: every requirement and every story you create sits underneath it and inherits its context. When REQQA analyses a requirement or generates stories, it reads the mission to understand what your application is for — so the more complete and precise your mission, the better the generated requirements and the sharper the analysis.

A thin mission ("an app to manage orders") gives REQQA almost nothing to reason with. A comprehensive mission — who the users are, what's in and out of scope, how the system operates, the situations it must handle, the assumptions it rests on, and the constraints it must respect — gives every downstream requirement a rich, shared context to inherit.

tip

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

The structure​

When you add an application, REQQA pre-fills the mission field with a guideline template: eight headings, each with a short note describing what to write. Replace each note with your own content and delete the guidance as you go. You don't have to fill every section to the same depth, but aim to say something real under each.

1. Business Purpose​

What the application is, who it's for, and the outcomes it delivers — in plain terms, not features. Say what it is not responsible for, so its purpose and boundaries are clear.

2. Business Scope​

The boundaries: what's in scope, what's out of scope (and why, or which other system handles it), and the envelope — where, when, by whom, and at what volume it's used, plus anything reserved for a later release.

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 — how often, and to do what. These shape the requirements and the stories directly.

4. Operational Concept​

How the application works end to end in normal operation: what goes in, what it does, what comes out, 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 the errors, the degraded cases, the unusual requests, and setup/decommission. Scenarios are where the real requirements hide.

6. Assumptions​

What you're 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/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 word on how each applies. Keep the heading even if it's empty — write "None" if nothing applies.

A worked example​

See Example: a comprehensive mission for a complete, filled-in mission for an everyday application. It shows the level of detail that produces good downstream requirements — use it as a yardstick, not a script.

Result​

A mission that a new team member (or REQQA) could read and understand what the application is, who it serves, and the world it operates in — without asking you a single question.