Skip to main content

How to manage your requirements

When you'd do this: any time you are working inside an application — adding a requirement, reviewing one, analysing it, cleaning up its wording, or tracking how it has changed over time.

This guide walks the full lifecycle of a requirement in REQQA, from the list view down to a single requirement's tabs. It assumes you have an application open. If you haven't created one yet, start with Your first application and give it a proper mission first — every requirement inherits that mission as its context.

note

Requirements always belong to an application, and the application belongs to your organisation. REQQA scopes everything you see to the application currently selected in your profile. To work on a different application's requirements, switch applications first.

See the whole picture: the requirements list​

Open Requirements to land on the list (reqsList). Each row shows the requirement's reference, title, priority, and — once you have analysed it — a compact analysis status: which steps have run, the count of active issues, and how many of those are high-severity ("critical"). Requirements that don't describe implementable features show N/A in the features column rather than a missing-analysis dash.

Filtering the list​

Above the table is a filter bar. You can narrow the list by:

  • Type — Functional (FR), Non-Functional (NFR), or Technical (TR), matched against the start of the requirement's reference.
  • Priority — any of your configured priorities, or Not Set.
  • Origin — how the requirement was created: Manual, Demo Generated, or Mission Generated.
  • Created by — any member of your organisation.
  • Has features — Yes or No.

Set the filters you want and click Filter. A Clear link appears whenever a filter is active, returning you to the full list.

From a row, you can go three ways​

Each row carries three buttons:

  • View opens the requirement (reqView).
  • Edit opens it straight in the editor (reqEdit).
  • Report renders an on-screen HTML report of the requirement and its whole child hierarchy, mirroring the release report layout.

See the structure: the tree view​

Requirements are hierarchical — a parent requirement can contain children, which can contain their own children. The flat list doesn't show that shape, so click Tree View (reqTree) to see it.

The tree is interactive: you can drag a node onto a new parent or reorder siblings, and REQQA re-sequences the affected branch for you. Use the tree when you are organising a large set of requirements or want to understand how a feature decomposes into its parts.

tip

The tree is the fastest way to re-parent a requirement. Editing the Parent field on the requirement itself works too, but dragging in the tree is quicker when you are restructuring several at once.

Create a requirement​

From the list, click Add Requirement (reqAdd). The add form has one rule that shapes everything else: a requirement template is required.

The role of a requirement template​

A template is a reusable skeleton of markdown headings — the sections a requirement of that kind should contain. Selecting a template pre-fills the content field with that structure, so you write into a consistent shape rather than from a blank page. Templates also carry a set of recommended analyses (see below), which the new requirement inherits by default.

Pick a template from the Requirement Template selector, then choose whether to insert its skeleton above or below any text you've already typed, or to set the reference only and leave content untouched.

caution

The title is derived from the content, not typed into a separate field. REQQA reads the first markdown heading (# Your Title) at the top of the content and uses it as the title. If you don't provide a heading, REQQA generates a placeholder title. Two requirements in the same application can't share a title, so if a save fails on a title clash, add a unique # Your Title line at the top and use ## or deeper for section headings.

The other fields​

  • Ref — your reference code (its prefix drives the Type filter: FR…, NFR…, TR…).
  • Priority — chosen from your organisation's configured priorities.
  • Content — the requirement itself, in markdown.
  • Describes implementable features — tick this if the requirement defines behaviour that produces user-facing features. It controls whether feature-oriented analyses apply.
  • Parent — where this requirement sits in the hierarchy (or Top-Level Requirement).
  • Recommended Analyses — see below.

When you save, REQQA redirects you to the new requirement's view.

Open a requirement: the three tabs​

Clicking View opens reqView, which is organised into three tabs. The active tab is remembered in the URL, so you can link straight to any of them.

View tab​

The default tab. It shows the rendered requirement content, its metadata (priority, parent, persona, assigned user, template, recommended analyses), the count of linked stories, and any active features. From here you can jump to:

  • Edit — open the editor.
  • History — the version trail (see below).
  • Report — the printable report.
  • Generate Stories — turn this requirement into user stories (see below).
  • Edit Features — manage the feature suggestions attached to this requirement.

Analyse tab​

This is where REQQA's analysis engine does its work, applying the DeFOSPAM technique to find faults in the requirement. You choose which analysis steps to run from the eleven available:

CodeWhat it examines
R-DDefinitions
R-GGoals & Users
R-FFeatures
R-IInterfaces
R-RRules
R-EEntities & Data
R-CConditions & Decisions
R-BBoundaries
R-QQuality Attributes
R-AAmbiguity
R-MMissing Elements

You can run any combination. If you aren't sure where to start, click Suggest Analyses — REQQA reads the requirement and recommends a set of steps for you, flagging any gaps against its template. Running an analysis queues a background job; refresh the page to watch progress and, when it finishes, the issues it found grouped by severity (high, medium, low). The Analysis Convergence History panel lets you compare runs across revisions, so you can see whether your edits are reducing the issue count.

note

Re-running an analysis supersedes the previous one: its open and accepted issues are marked Superseded so the latest run is the live picture. The R-F (Features) step is locked once active features exist — use Reset & Regenerate Features to re-run it cleanly.

Clean Up tab​

The Clean Up tab runs synthesis and cleanup helpers over the content: a preview of formatting fixes (stray escaped characters, section sizing, and similar) that you can apply selectively, and an AI reformat of an individual section for readability that preserves all the content. Applying any cleanup bumps the requirement's revision and records a history snapshot, so nothing is lost.

Edit a requirement​

Click Edit (reqEdit) to change a requirement. The editor is the same shape as the add form — content (with title derived from the first heading), ref, priority, features flag, parent, and notes — plus two things specific to editing:

  • Changing the template. If you switch templates mid-edit and the requirement already has recommended analyses, REQQA asks how to reconcile them: Keep the current set (the default), Replace with the new template's defaults, or Merge the two. Removing a template entirely leaves your recommended analyses untouched.
  • Recommended Analyses. Tick the analysis steps you want recommended for this requirement. These drive the default selection when you analyse it — individually or in bulk. Leave them empty and the template's recommended set is used at save time.

Saving bumps the requirement's revision, writes a history row, and returns you to the view.

History and versions​

Every save, cleanup, or reformat writes a snapshot to the requirement's history. From the View tab, click History (reqHistory) to see the trail — each revision with who changed it and when. You can open any past version (reqVersionView) to read it in full, or compare two versions to see an inline diff of exactly what changed between them. This is your audit trail: nothing is overwritten silently.

Work in bulk: Analyse Selected and Generate Stories​

The list view has actions that operate across many requirements at once, using the row checkboxes to choose which:

  • Analyse Selected queues an analysis for each ticked requirement. If you don't override the steps, each requirement uses its own recommended analyses (inherited from its template), falling back to the full set when none are recommended. Requirements that don't describe features automatically skip the feature-oriented steps. Each one becomes a queued background job.
  • Generate Stories turns selected requirements into user stories. See Generating stories for the full recipe.

You can also re-index the glossary across all requirements from here, which refreshes the glossary term cross-references.

tip

Bulk analysis can queue a lot of jobs at once. Watch them through the job queue rather than hammering refresh — see Background jobs.

Result​

You can move fluently through the requirements lifecycle: find and filter requirements, understand their structure in the tree, create well-formed requirements from a template, read and analyse them, clean up their wording, edit them with a full version history behind you, and run analysis or story generation across many at once. Each requirement carries its mission context, its analysis history, and its change trail — so the quality picture is always current and auditable.