Requirements

Requirements in Northwise make the "why" of architecture decisions inspectable. A requirement links upstream to a principle, stakeholder, or regulatory driver, and downstream to the capabilities and applications that realise it. That chain — from business driver through requirement to architecture element — is what makes your architecture auditable and your decisions defensible.

What it does

• Captures three types of requirement under one unified entity: Architectural, Functional, Non-functional
• Tracks a dual lifecycle: status (draft → active → retired) and realization (not started → in progress → realized)
• Links requirements upstream to principles, drivers, and goals; downstream to capabilities, applications, and business processes
• Groups requirements inside Initiatives (work contexts) for scoping to a delivery effort
• Provides a reader-view permalink (/r/requirement/{uuid}) for sharing with non-Northwise stakeholders

When to use it

• A regulatory obligation must be traceable to the controls that address it
• You need to know which NFRs govern a particular application before deciding on its infrastructure
• A team asks "what are the architecture constraints for the new customer portal?"
• You're documenting the motivation behind an ADR so future readers understand why the rule exists
• A Plumbline assessment raises a finding and you want to track the corrective requirement

How it works

The three types

Architectural requirements motivate or constrain architecture choices. They are long-lived, owned by an architect, and linked to principles, capabilities, and architecture elements. Example: "All customer-facing services must support OIDC-based authentication."

Per-type fields: domain (business / data / application / technology / security / governance / cross-cutting), rationale, applies_to_scope.

Functional requirements describe what a system or capability must do. They're often scoped to an initiative and expressed in actor/action/outcome form. Example: "As a fleet manager, I can export the active leases for a customer to CSV."

Per-type fields: actor, action, outcome, acceptance_criteria (Given/When/Then).

Non-functional requirements specify measurable quality attributes. They have a target value and a verification method. Example: "The customer portal must return any page in p95 < 800 ms under 200 concurrent users."

Per-type fields: quality_attribute (performance / scalability / availability / security / privacy / usability / maintainability / observability / portability / compliance / cost), measurement, target_value, verification_method.

The two lifecycle axes

Requirements have two independent lifecycle axes — both matter.

Status (the authoring axis):

draft → active → retired

• draft — being authored. Not yet authoritative. Hidden from element-level "Requirements" tabs unless you expand "Include drafts."
• active — authoritative. The default for any requirement your team acts on.
• retired — withdrawn or superseded. Requires a retired_reason. Hidden by default; recoverable via the "Include retired" filter.

Realization status (the delivery axis):

not_started → in_progress → realized
                           ↘ not_applicable

• not_started — default. No linked realising element yet.
• in_progress — a realising link exists or the architect has manually flagged work in progress.
• realized — the architect has confirmed the requirement is implemented. realization_notes should explain how and where.
• not_applicable — when realization tracking doesn't apply (e.g., a constraint satisfied by absence).

Upstream and downstream traceability

Upstream (where did this requirement come from?):

Each requirement has a primary source_type (stakeholder, legal/regulatory, principle, driver, goal, finding, internal policy) and optionally a source_ref (citation) or a linked Northwise entity (e.g. a specific Principle or Finding).

Downstream (what realises or is constrained by this requirement?):

The Requirement Links mechanism connects requirements to other entities with typed semantics:

| Link type | Meaning | | ---------------- | ------------------------------------------------------------------- | | realises | A Capability, Application, or Process that fulfils this requirement | | constrains | An element whose design is limited by this requirement | | satisfies | A Principle or Goal that this requirement satisfies | | derives_from | A parent requirement this was decomposed from | | conflicts_with | A known tension with another requirement | | related_to | Soft link with no specific semantics |

ArchiMate integration

If you also want a requirement to appear on ArchiMate canvases — in Landscape viewpoints — you can link it to an ArchiMate Requirement element. This is optional. When linked, changes to the requirement's title sync to the element's name automatically, and the requirement code appears as a chip on the element in the Layered viewpoint.

Scoping to initiatives

Set work_context_id to scope a requirement to a specific delivery initiative. The initiative's Requirements tab then shows all requirements associated with that initiative. Useful for sprint reviews or architecture sign-off ceremonies scoped to a particular delivery effort.

Priority (MoSCoW)

Requirements can be tagged with a MoSCoW priority: must, should, could, wont. Priority is optional — if not set, the requirement appears as "unprioritised". Bulk-reassign priority from the list page.

Configuration options

No per-tenant configuration required. The code format (REQ-{n}) is fixed and auto-increments within each tenant.

Common workflows

• Capturing requirements from a regulatory driver → create an Architectural requirement with source_type=regulatory; fill source_ref with the regulation citation; link to the principles it invokes.
• Tracing NFRs to a specific application → create a Non-functional requirement; add a constrains link to the Application Component in Landscape. The element's Requirements tab will list it.
• Finding unrealised requirements → filter the requirements list to realization_status=not_started, status=active to see what's approved but not yet built.
• Raising a finding from a requirement → from the requirement detail page, click Add finding to open the Findings create-flow with the subject prefilled.

Related