Architecture Portal

Generic delivery and QA assets

Requirements, tests, review and the actual result.

Adrian Sutherland · Version 1.0 · · © 2005–2026

A plan can appear complete while leaving a requirement without a check or a result without a clear meaning. These delivery and quality assurance (QA) assets help a team compare its intended change with what it plans, checks and actually establishes.

Each task pairs a human brief with an artificial intelligence (AI) prompt template, required inputs, expected outputs and a fictional worked example. Adapt the record to your sources and existing authority. The download contains the complete template; the descriptions below help you choose one.

Requirements versus plans

Find requirements that a delivery plan omits, changes or cannot yet substantiate.

Compare each in-scope requirement with the planned work and proposed check. Include service operation and quality requirements. Identify contradictions, assumptions, extra scope and decisions still needed.

Human brief and AI prompt template — Markdown

Example. The fictional plan includes a transfer screen but no way to investigate a lost response. The requirement for support to establish acceptance is only partly covered. The sample proposes a status/receipt investigation task, subject to design review.

Meaningful tests

Choose checks that can reveal a consequential failure in the proposed change.

Start with the required behaviour and failure risk. Specify inputs and expected results from the requirement or contract. Use checks at the level where the failure can occur, and retain valid prior results when their relevant inputs remain unchanged.

Human brief and AI prompt template — Markdown

Example. A fictional acceptance test repeats the same accepted request and expects the same receipt with no second handover, as the proposed contract specifies. A separate revoked-access case checks disclosure. These are proposed tests and have not run.

Independent review

Challenge a proposed change against its requirements and accepted decisions.

Give a reviewer the actual change, the requirement and relevant sources. Ask for actionable findings, the source for each finding and any unresolved question. Preserve the distinction between a separate review and proof that the change is correct.

Human brief and AI prompt template — Markdown

Example. For the fictional case-service change, a reviewer notices that the proposed design sends notifications before acceptance is recorded. The finding links that behaviour to the proposed contract. A separate review helps challenge the design; it does not establish that a service has been tested.

Explicit execution/result state

Describe what was requested, attempted and established without hiding incomplete or unknown outcomes.

Identify the operation and its agreed result contract. Record requests, actions, observations and accepted results separately. Include failed, pending and unknown work. Explain which observation is needed to choose the next step within the task’s existing permissions.

Human brief and AI prompt template — Markdown

Example. In the fictional service, the caller loses the response to X7 (Acceptance operation). The caller’s outcome is unknown until an authorised lookup or an agreed repeat returns the same receipt without a second handover. The timeout alone establishes neither rejection nor acceptance.

Connected guidance

Systems and software explains responsibilities, contracts, failure and checks. Assessment helps examine accepted outcomes, quality and the effort needed to reach them.

AI-supported architecture describes how these activities can use AI assistance. Browse the other IT practice collections when a task crosses governance, delivery and support.

Methodology configuration

Use the terms and records your team already understands. Keep their meanings, source versions and decision owners clear. Methodology configuration explains how to map the activities and reviews to your own approach.

Edition and reuse

Version 1.0 · September 2026 · © 2005–2026 Adrian Sutherland.

Portal-authored downloads use CC BY 4.0. Keep the author, source edition and licence with adaptations, and identify changes. Read the edition note and use the asset index — JSON for the complete list of tasks and download addresses.

About this edition

Refreshed for the September 2026 website update. This edition extends the retained Architecture Portal and ASAF material with IT practice assets and reported project experience.

Scope, limitations and next checks

Status and accountability

Read this page with its boundaries visible

Status

In development

Last reviewed

Intended users

  • Architects adapting their own approach to IT design, delivery and support

Non-goals

  • A mandatory methodology or a guarantee of AI accuracy or operational safety

Limitations

  • Guidance and adaptable examples; the fictional service is unimplemented and its checks remain unrun.

Next evidence sought

  • Apply the guidance to a real task and review usefulness, results and limitations.