A GKM Legacy Holdings company · contracting in Maryland, USA · delivering from Accra, Ghana
InsightsWhere we workFrançais
Strategic Advisory
& AI
Book a consultation

Demonstration · not a client result

Data portals and web applications what the deliverable looks like

The structure of the deliverable for data portals and web applications, how it is produced and how you accept it, with a live specimen generated from the matching free tool’s worked example. Synthetic or permitted data only.

See the service Send a brief

DemonstrationSynthetic or permitted data

What this page isDemonstration

Practice
05 Digital solutions
The deliverable
4 sectionsProduced in 5 stages, each with a review point
Data
Synthetic or permittedNot a client result

Demonstration of methodSynthetic or permitted data.Not a client result.

The deliverable, section by section.

What you receive, and what each part is for.

Section 01 of 04

Workflow spec

Users, roles, data and acceptance criteria.

Demonstration
Section 02 of 04

Working portal

For the defined workflow.

Demonstration
Section 03 of 04

Test record

Acceptance tests passed.

Demonstration
Section 04 of 04

Handover

Code, access, hosting notes and training.

Demonstration

A live specimen.

Generated from the worked example in Web app requirements template: synthetic data, real method. Change the inputs in the tool to see your own.

Demonstration · synthetic data · not a client result

3user roles
4features
2/4traced and testable
3must-haves
Features by priority
  1. Must3
  2. Should1
  3. Could0
  4. Won’t (this release)0

Specification gaps

  • Gap: “Conflict-of-interest declaration” has no acceptance test.Say how you will know it works.
  • Gap: “Dashboard of applications by region” has no user need.If no user needs it, it should not be built.
  • Check: 3 of 4 features are “Must”.When everything is a must, nothing is. Keep musts to what the first release cannot work without.

Specification and test checklist

Users

  • Applicant: Submit an application and track its status (About 400 a year).
  • Reviewer: Score applications against published criteria (12).
  • Programme officer: Manage rounds, reviewers and decisions (3).

Must

  • Save a draft application. Need: Applicants complete long forms over several sittings. Test: A draft saved on one device reopens with every field intact.
  • Reviewer scoring form. Need: Reviewers score consistently against the criteria. Test: Each criterion scored 1 to 5 with a required comment; totals computed.
  • Conflict-of-interest declaration. Need: Reviewers must not score applications they are connected to. Test: MISSING.

Should

  • Dashboard of applications by region. Need: MISSING. Test: Counts match the application list for any filter.
Test and owner, requirement by requirement
RequirementPriorityAcceptance testOwnerReady to hand over
Save a draft applicationMustA draft saved on one device reopens with every field intactNo ownerNo: no owner
Reviewer scoring formMustEach criterion scored 1 to 5 with a required comment; totals computedNo ownerNo: no owner
Conflict-of-interest declarationMustMISSINGNo ownerNo: no acceptance test, no owner
Dashboard of applications by regionShouldCounts match the application list for any filterNo ownerNo: no owner

Before it is handed to a builder

  • Check: 4 of 4 requirements are not ready to hand over.Each needs an acceptance test and a named owner: the person who will say the test passed.
  • Note: An owner is a name you typed.It gives nobody the power to approve, sign or buy. The organisation itself decides who accepts the work.

How it is produced, and accepted.

Each stage ends in something you review; acceptance is tested against criteria agreed at the start.

  1. 01

    User need

    Agree users, tasks and roles.

    Review pointUser needs and success measures agreed.

  2. 02

    Scope

    Write the scope and acceptance criteria.

    Review pointWritten scope with acceptance criteria.

  3. 03

    Build

    Build in short, demonstrated steps.

    Review pointWorking build demonstrated at agreed milestones.

  4. 04

    Test

    Test with real users and data.

    Review pointAcceptance tests passed and recorded.

  5. 05

    Handover

    Hand over and plan the next workflow.

    Review pointHandover of code, content, access and documentation.

How proof is labelled

  • DemonstrationsDemonstrations use synthetic or permitted data.
  • Documented experienceDocumented experience is attributed to the organisation that held the work.
  • Measured resultsMeasured results are added only once they have been measured; none are shown yet.

What needs to move forward?

Tell us the decision, the challenge or the opportunity. We reply with a scoped approach, a named principal and a fee before any work begins.

Tell us what you need Book Michael · from USD 90

No charge to submit an enquiry.