Government, civic, and public-sector software
Digital Public Service Requirements Checklist
A practical requirements framework for agencies and civic organizations delivering an accountable service across public, staff, partner, and assisted channels.
Published by Kennedy Gichobi · Fact-checked by OpenAI Codex research review · Published · 1654 words
Model the service, not only the submission
Describe actors and authority: anonymous visitor, applicant, representative, household member, organization administrator, intake worker, reviewer, supervisor, inspector, records officer, finance staff, support agent, auditor, partner, and system service. Define which records each may see, create, change, decide, export, or disclose and under which assignment, program, region, or delegation.
Model a case or application independently from a user account. People can submit through staff, mail, phone, partner, or bulk migration; representatives can change; accounts can be recovered; organizations can replace administrators. Preserve the relationship and authority that applied at the time of an action.
Define states, transitions, deadlines, and reasons. Example states might include started, submitted, incomplete, awaiting evidence, under review, inspection scheduled, approved, denied, withdrawn, expired, appealed, corrected, and closed. State who can cause each transition, required facts, notifications, timers, downstream actions, and reversal behavior. Do not use a generic “complete” status that hides whether a case was approved, denied, abandoned, or transferred.
Separate facts from decisions. Preserve submitted values and evidence, verification results, policy version, calculation inputs, reviewer findings, decision, reasons, notice, and later correction. A calculated field should be reproducible from the rules and data that applied then.
Design accessible and assisted intake
Requirements must support keyboard operation, screen readers, zoom, reflow, clear focus, understandable labels, error identification, status announcements, adequate targets, and alternatives to sensory-only instructions. Reusable components help, but USWDS explicitly states that teams must test their own implementation and complete page context. Include automated, manual, and user testing throughout delivery.
Use plain language and progressive disclosure. Explain why information is requested, acceptable evidence, estimated effort, deadlines, and what happens next. Save progress where the service permits it. Prevent session expiry from destroying work without warning. Let people review and correct information before submission and obtain a durable confirmation afterward.
Plan multilingual content as an operating capability, not a machine-translation button. Identify languages, translation authority, review, version synchronization, layout, search, notifications, support, and how urgent changes reach every language. Preserve the language in which a notice was issued.
Assisted service is part of the same product. Staff should be able to help without sharing applicant credentials or creating an invisible second record. Define telephone, in-person, mail, partner, and accessibility-accommodation workflows. Record who entered information, its source, consent or authority, and which communications the person received.
Use proportionate identity and fraud controls
Do not demand identity proofing merely because an account is convenient. Determine the harm of accepting the wrong person, exposing information, or denying the right person. Some services can accept anonymous or pseudonymous reports; others need stronger evidence before disclosing records or making a consequential change.
NIST SP 800-63 Revision 4 separates identity proofing, authentication, and federation and connects assurance decisions with security, privacy, fraud, and customer experience. Use a risk assessment to select proportionate controls. Avoid collecting high-risk identity data when a lower-assurance interaction satisfies the service.
Support secure account recovery, device change, name change, representative access, organization administration, and loss of an authenticator. Recovery should not bypass the assurance of the original process. Record proofing and authentication outcomes without exposing unnecessary evidence to ordinary staff.
Fraud controls need human authority and correction. Record signals, source, confidence, review, outcome, and appeal; do not convert an opaque score directly into denial. Test bias, false positives, exclusion, and adversarial behavior. Qualified policy, legal, privacy, security, fraud, and civil-rights owners must define acceptable use.
Define documents, payments, and notifications
For evidence uploads, define permitted formats, size, scanning, metadata, naming, quality, duplicate behavior, replacement, redaction, retention, access, and accessible alternatives. Keep the original file where policy requires and record derived text or classification separately with its method and confidence. Staff must be able to correct an automated extraction without obscuring the original.
For payments, decide which provider handles card or bank data, how the service minimizes sensitive information, and how authorization, settlement, refund, waiver, chargeback, receipt, and reconciliation relate to the case. A successful browser response does not prove funds settled; an unsuccessful response does not prove no charge occurred. Use stable transaction references and idempotent operations.
Model notifications as accountable records: recipient, channel, language, template or content version, triggering fact, generated time, delivery attempts, provider result, and follow-up. Separate informational messages from formal notice. Define what happens when email, SMS, or mail fails and which deadline depends on issuance versus receipt.
Never place sensitive case details in an insecure notification solely for convenience. Send the minimum useful message and route the person to an authenticated service when appropriate. Provide a verified way to recognize official communication and report suspected impersonation.
Preserve records, privacy, and transparency
Create a data inventory for every field, document, derived value, event, message, export, integration, log, and backup. Record purpose, authority, sensitivity, source, access, disclosure, retention, correction, hold, and disposal. Minimize collection and avoid copying sensitive information into analytics or general support tools.
Define the official record and authoritative system for each fact. Integrations should exchange stable identifiers, effective dates, source, and version where needed. Reconcile failures visibly. A staff member must be able to see whether a partner check is pending, stale, unavailable, disputed, or complete instead of interpreting missing data as a negative result.
Preserve an audit history for consequential access and changes, but do not treat logging as permission. Restrict bulk search and export, protect logs, synchronize time, and monitor misuse. Provide lawful access, correction, disclosure, retention, hold, and deletion workflows according to approved policy.
Transparency requirements may include public status, datasets, reasons, processing times, or decision statistics. Design publication from reviewed, minimized data and documented suppression rules. Do not expose personal or sensitive case information through predictable identifiers, search, analytics, or downloadable reports.
Build security, reliability, and recovery into acceptance
Use NIST Cybersecurity Framework outcomes to organize governance, identification, protection, detection, response, and recovery, then select controls proportionate to the service. Threat-model identity, authorization, public intake, uploads, integrations, administrative functions, bulk access, notifications, and provider dependencies.
Test object-level authorization and case assignment at the API and data layer. Protect secrets and service identities, patch dependencies, validate untrusted input, rate-limit abuse, monitor high-risk actions, and define vulnerability response. Avoid claiming universal compliance because the platform uses a particular cloud service or framework.
Classify service journeys by consequence and time sensitivity. Define acceptable downtime and data loss, manual fallback, queue behavior, backup, restoration, reconciliation, and communication. Test loss of identity, payment, notification, partner, storage, and staff systems. A health check that reports a running server does not prove the public can submit or staff can decide a case.
Prepare incident playbooks for account compromise, unauthorized disclosure, malicious upload, fraud campaign, provider outage, data corruption, and unavailable public access. Identify decision authority, containment, continuity, notification review, evidence, restoration, public communication, and post-incident improvement. Exercise the playbooks with the people and fallback channels expected during a real disruption.
Deliver one complete service slice
Avoid launching a beautiful intake form into an unprepared back office. The first release should cover one bounded service journey from trustworthy guidance through intake, staff processing, decision or fulfillment, notice, status, records, support, and measurement. It can limit applicant type, region, permit class, or case complexity while preserving a complete outcome.
For example, a municipal permit pilot might support one permit type with public eligibility guidance, accessible application, document evidence, fee handling, staff completeness review, inspection scheduling, decision reasons, formal notice, status, records retention, and help-desk escalation. More permit types should follow only after policy variation and operational evidence are understood.
Acceptance scenarios include no digital account, representative submission, language assistance, keyboard-only completion, interrupted session, duplicate submission, expired document, fee waiver, failed payment, unavailable partner, reassigned reviewer, missed deadline, corrected decision, failed notice, records request, suspected fraud, and restored service after outage.
Requirements decision checklist
Before procurement or development, make the service boundary reviewable. Name the policy and service owners, public outcome, assisted channels, systems of record, highest-consequence decisions, expected volumes, support model, and evidence required for launch. Then confirm:
- The public outcome, service owner, lawful authority, policy versions, and decision owners are explicit. - Every public, staff, partner, representative, and assisted-channel role has defined authority. - Case states, deadlines, evidence, decisions, reasons, correction, appeal, and closure are modeled. - Accessibility, plain language, multilingual content, mobile use, and assisted service are acceptance requirements. - Identity proofing and authentication are proportionate to risk and include practical recovery. - Documents, payments, notifications, and integrations have failure and reconciliation behavior. - Data purpose, access, disclosure, retention, correction, records, and disposal are approved. - Security, monitoring, incident response, backup, restoration, fallback, and continuity are testable. - Analytics measure service outcomes without unnecessary personal data. - Source code, cloud accounts, configurations, data export, documentation, and operational ownership are transferable.
Use the digital public service cost guide to budget the lifecycle and the public application review requirements guide for deeper staff workflow design. Share the service, authority, users, current channels, systems, records, deadlines, and target outcome through the project questionnaire, or use quick contact to review one service journey.
Authoritative references
Related software planning guides
- Digital Public Service Software Cost and Budget Guide
- Emergency Response Coordination Platform Requirements
- Permit and Licensing System Requirements Checklist