Skip to main content

Key Concepts

REQQA organises everything you do around a small, consistent domain model. Understand these few objects and how they nest, and the rest of the application — requirements, analysis, stories, releases — falls into place. This page is the conceptual map; the linked pages go into detail on each part.

The shape of the model​

At the broadest level REQQA is multi-tenant: many separate organisations use the same installation without ever seeing one another's data. Inside an organisation, work is divided into applications, and inside each application sits a hierarchy that begins with a single mission and descends through requirements, features, and stories.

Organisation (tenant)
└── Application
    └── Mission (one per application)
        └── Requirements (hierarchical: parent / child)
            └── Features
                └── Stories (Gherkin)

Organisations​

An organisation is a tenant — the top-level container that owns everything else. Each organisation is more than a label: it carries its own AI configuration. The organisations record holds the OpenAI API key (stored encrypted), the AI model to use (gpt-4 by default), the temperature, the maximum token budget, and retry settings. This means two organisations on the same REQQA instance can analyse requirements using different models, different creativity settings, and entirely separate AI accounts and billing.

note

Because the AI configuration lives on the organisation, the quality and cost of analysis are tuned per tenant, not globally. See AI models and cost for how those settings affect results.

Members and access​

People belong to an organisation through membership — the orgmembers table links a user to an organisation. A user can be a member of more than one organisation, and membership is what grants access to that organisation's applications and data.

REQQA is invite-only: you don't sign up to an organisation freely. New members arrive either through an invitation or through an approved access request, after which they are provisioned into the organisation. The reasoning behind this, and the mechanics of getting people in, are covered in Access and onboarding and the how-to Inviting your team.

Applications​

An application is a single product, system, or service you are specifying. It belongs to one organisation (via its orgid) and is the working unit you spend most of your time in: requirements, the glossary, releases, and analysis results all hang off an application.

Each application has:

  • an App Code — a short identifier;
  • a title;
  • a mission — a substantial text field (the model reserves up to 20,000 characters for it) that anchors the whole hierarchy;
  • analysis quality controls, such as per-artefact severity thresholds for the mission, requirements, and stories, that govern which issues an analysis surfaces;
  • a test strategy setting used when generating stories.

Applications can also be archived rather than deleted, so retired work stays in the record without cluttering active lists.

The requirement hierarchy​

Everything an application is is expressed as a hierarchy, and the mission sits at the top of it.

Mission​

The mission statement describes what the application is for: its purpose, scope, stakeholders, operating concept, scenarios, assumptions, and constraints. It is the context every requirement and story inherits. When REQQA analyses an artefact or generates stories, it reads the mission to understand the world the application lives in — so the mission is the single highest-leverage thing you write.

See The mission for the concept, and Writing your mission for the step-by-step.

Requirements​

Beneath the mission are requirements. They are hierarchical: each requirement may have a parent (parentid) and a sequence position among its siblings, so you can build a tree of parent requirements with children below them. A requirement carries a reference, a title, a priority, its detailed content, an optional template, and an origin that records how it came to exist (for example manual for hand-written entries). Requirements are versioned, with a full change history kept as they evolve.

See Requirements for the detail.

Features and stories​

Requirements can be broken down into features, and features into stories — concrete behaviours written in Gherkin (Given / When / Then). Stories are the most granular, testable expression of what the application must do, and REQQA can generate them from requirements as well as analyse them for faults. A story records its source feature and its own origin, so you can trace each behaviour back up the hierarchy to the requirement and mission it serves.

See Stories and features for how this layer works.

Multi-tenancy and orgid scoping​

The single most important rule in REQQA's data model is that everything is scoped by organisation. Almost every table carries an orgid (and often an appid) column, and queries are filtered by the current organisation so that one tenant can never read or write another's data. This orgid scoping is what makes the shared installation safe: tenant isolation is enforced at the data layer, not merely in the user interface.

caution

Tenant isolation depends on this scoping being applied consistently. It is a foundational invariant of the system, not an optional convenience — which is why organisation context is always present when you are working.

Your current context: profile org and app​

Because a user can belong to several organisations, and each organisation has several applications, REQQA needs to know which organisation and which application you are working in right now. That "current context" lives in your user profile.

The userprofile record stores your current orgid (and the organisation name) together with your current appid (and the application name). When you switch organisation or select a different application, you are updating this profile context — and from then on, the requirements, glossary terms, releases, and analyses you see are the ones belonging to that organisation and application. Your profile's current application is also the hub the main view opens to.

tip

If something you expect to see is missing, the first thing to check is your current context: you may be looking at a different application — or a different organisation — than the one your data lives in.