Skip to main content

Your first application

This guide walks you from your first login to a working application with its first analysed requirement. It should take fifteen to twenty minutes, and by the end you'll have seen the whole REQQA loop in miniature: a mission, a requirement drawn from a template, and an analysis that finds faults in it using the DeFOSPAM technique.

You don't need to get everything perfect on the first pass. REQQA is built for iteration — write something real, analyse it, read what comes back, and refine. This page gets you to that first turn of the loop.

tip

If you'd like the lie of the land before diving in, read A tour of REQQA first. Otherwise, carry on — this guide is self-contained.

Before you start​

You need a REQQA account and membership of an organisation. REQQA is invite-only, so if you're reading this you've already been onboarded into an organisation by your administrator (see Why is REQQA invite-only? for the reasoning). Everything you create — applications, requirements, stories, glossary terms — lives inside that organisation and is scoped to it.

Step 1 — Log in and confirm your context​

Log in with the credentials from your invitation. REQQA always works in the context of one organisation and one application at a time. Your current context is shown in the navigation bar, with a dropdown for switching between them.

On your very first login you'll have an organisation but no application yet, so REQQA sends you to All Applications (the appsList page) rather than an application dashboard. That's expected — you're about to create the first one.

note

If you belong to more than one organisation, use the org/app dropdown in the nav bar to pick the right one before you create anything. New applications are created inside whichever organisation is currently active.

Step 2 — Create your application​

On the All Applications page, click Add an Application. The form (appAdd) asks for a small number of things:

  • Title — the human-readable name of the application.
  • App Code — a short identifier shown on every tag throughout the UI. Keep it concise and memorable, for example REQQA or INVESTO.
  • Mission — the mission statement. This field is pre-filled for you (see below).
caution

An application's App Code must be unique within your organisation. If you reuse a code that already exists, the save is rejected.

The mission is pre-filled with a guideline​

This is the part people miss on their first go: when you open the Add Application form, the Mission field is not blank. REQQA pre-populates it with a guideline template — eight headings, each with a short note telling you what to write underneath. You'll replace those notes with your own content in the next step.

The eight sections are: Business Purpose, Business Scope, Stakeholders and User Classes, Operational Concept, Scenarios, Assumptions, Constraints, and References and Applicable Standards. You don't have to fill every section to the same depth on the first save — you can leave the guideline in place and refine it on the application's edit page afterwards.

When you save, REQQA does three things automatically:

  1. Creates the application and sets it as your active context (the nav bar now shows it).
  2. Seeds a starter set of requirement templates into your organisation, so the requirement form in Step 4 has something to offer you.
  3. Indexes the mission text for the glossary, so terms are cross-referenced from the start.

After saving you land on All Applications with your new app present and selected.

Step 3 — Write the mission​

The mission statement is the single most valuable thing you'll write in REQQA. It sits at the top of your requirements hierarchy: every requirement and every story you create inherits its context. When REQQA analyses a requirement or generates stories, it reads the mission to understand what the application is for — so a richer mission produces sharper analysis and better-grounded generated content.

Open the application (it should already be your active context) and edit it — either from the Edit Application button on the dashboard, or from the read-only mission view. Work through the eight guideline sections, replacing each note with your own content and deleting the guidance as you go. Aim to say something real under each heading.

tip

For a complete, filled-in example at the level of detail that produces good downstream requirements, see Example: a comprehensive mission. For guidance on what belongs in each section, see Writing your application mission.

A good test: could a new team member — or REQQA — read your mission and understand what the application is, who it serves, and the world it operates in, without asking you a single question? If yes, you're ready to write requirements.

Step 4 — Add your first requirement​

With your application open and its mission in place, go to the requirements list (reqsList) and click Add Requirement. The form (reqAdd) has a few fields worth understanding before you fill it in:

Pick the template first​

The Requirement Template dropdown is required — you can't save a requirement without choosing one. Selecting a template pre-fills the content field with that template's markdown skeleton, so you start from a structured shape rather than a blank box. The starter templates seeded in Step 2 will be waiting in the dropdown.

caution

Choose the template before you type any content. Selecting a template overwrites the content field with the template skeleton, so picking one after you've written something will discard your text.

The title is generated, not typed​

You don't type a title. REQQA derives it automatically from the first # Heading line in the content field. Make sure your content begins with a top-level markdown heading — that line becomes the requirement's title. If you forget it, the requirement is saved untitled until you add the heading and re-save.

Fill in the rest​

  • Parent requirement — choose where this requirement sits in the hierarchy, or leave it top-level if it has no parent.
  • Priority — set the priority from the selector.
  • Recommended Analyses — which DeFOSPAM analyses are suggested for this requirement. These carry over from the template by default, and you can adjust them per-requirement.
  • Content — replace the template skeleton's placeholder text with your actual requirement, keeping the structure the skeleton gives you.

Click save. REQQA commits the new requirement and redirects you to its detail page (reqView), where you'll run the analysis.

note

If the template dropdown is empty, no templates exist yet for your organisation. Visit the requirement templates list to create one. (In the normal first-run flow, Step 2 will have seeded some for you.)

Step 5 — Run the analysis​

On the requirement's detail page, switch to the Analyse tab. This is where the DeFOSPAM technique earns its keep: it inspects your requirement against a set of fault categories and reports the issues it finds.

Two analyses are the natural first ones to run on a requirement:

  • R-D — finds defects in the requirement: ambiguity, incompleteness, untestable statements, and the other classic requirement faults DeFOSPAM looks for.
  • R-F — discovers candidate features implied by the requirement, which can later seed stories.

Tick the analyses you want (your Recommended Analyses from Step 4 are a good default) and run them. Analysis runs as a background job, so the page won't freeze — REQQA queues the work and processes it asynchronously. You can watch progress on the Job Queue page.

note

For the full list of analyser codes and what each one looks for, see Analyser codes. For a deeper walk-through of running and reading analyses, see Analysing a requirement.

Step 6 — Read the result​

When the job completes, the issues appear on the requirement. Each issue carries a severity and a confidence rating, an explanation of the fault, and often a suggested improvement. Read them as a reviewer would: not every flagged issue is one you must act on, but each is worth a moment's thought.

This is the loop you'll repeat constantly in REQQA:

  1. Write or refine a requirement.
  2. Analyse it.
  3. Read the issues.
  4. Edit the requirement to address the ones that matter.
  5. Re-run the analysis and watch the issues clear.

When you edit and re-save a requirement, REQQA records a new revision in its history, so you can always see what changed between turns of the loop.

What you've achieved​

You now have an application with a real mission, a requirement built from a template and titled from its own content, and a completed analysis you can read and act on. That's the whole REQQA workflow in miniature. From here you can deepen the mission, add more requirements, generate stories from them, and start managing your work into releases.