How to procure a Web GIS: requirements and acceptance criteria
A practical way to turn a map-portal purchase into testable requirements for data, user tasks, interoperability, accessibility and operations.
A geoportal should not be bought as a collection of screens or a map with layers switched on. It should be bought as the ability for a defined person to complete a decision or process using traceable data, within agreed operating conditions.
That distinction changes the brief. A demonstration can look convincing with sample data yet fail when a layer is updated, sensitive information must be restricted, a source needs explanation, or a recurring enquiry is made. Define what must be proven at project close before choosing a platform.
GeoSAT's geoportal and web GIS service can structure that scope. For the architectural context, see a sustainable Web GIS architecture.
Start with the decision, not the brand
Ask user teams to describe complete tasks: locating a parcel, checking a restriction, downloading permitted data, reporting an inconsistency, or publishing an approved edition. Capture, for each task:
- Who performs it and at which access level.
- The data, cutoff date and source it needs.
- The result that lets a decision or process move forward.
- What happens when data is missing, stale or under review.
- The evidence that must be retained.
Only then decide whether the portal will consume ArcGIS, QGIS Server, GeoServer, PostGIS, OGC services or a combination. Reversing that order often turns a technology preference into a requirement no one can test.
Turn scope into acceptance tests
Every requirement should answer three questions: what will be tested, using which data, and what evidence proves the result? This matrix is a useful starting point:
| Area | Testable criterion | Acceptance evidence |
|---|---|---|
| Data | An authorised person can find a layer by title, theme or territory and see its source, owner and cutoff. | Recorded test against an agreed data set, with metadata links. |
| Enquiry | A user can search, identify the correct feature and understand the result's units and limits. | Test script, screenshots or recording, and expected results. |
| Publishing | An approved update reaches the public environment without manual copying or concealing the previous version. | Executed workflow, version record and rollback plan. |
| Integration | Consuming systems use a documented contract, including identifiers, filters, limits and known error handling. | Consumer inventory and a test against the published service. |
| Security | Roles can see only authorised layers and actions, with access audited where appropriate. | Role matrix and evidence of positive and negative tests. |
| Accessibility | Priority tasks work with a keyboard, visible focus, clear messages and agreed screen sizes. | Manual review of critical flows, not only a conformance statement. |
| Operations | Named owners, monitoring, backup, recovery testing and a source-outage procedure exist. | Log of an agreed recovery test or exercise. |
There is no single response-time target that fits every portal. The contract should set metrics for the project's actual queries, data volumes and operating conditions, including dependencies on external services.
Separate discovery, implementation and operations
One deliverable called “finished geoportal” tends to conceal decisions that should be validated earlier. A more controllable engagement separates at least three stages:
- Discovery and prototype. An inventory of sources, roles, risks and tasks, plus one representative flow using real or authorised sample data.
- Implementation and migration. Publication model, interface, integrations, metadata, permissions, testing and knowledge transfer.
- Operations and evolution. Fixes, patching, observability, backups, support, content changes and periodic dependency review.
The prototype does not replace final acceptance. It establishes whether the proposed solution can handle the workflow, data volume, access rules and dependencies before the full commitment is made.
Require portability where it matters
A portal may use commercial, open-source or bespoke components. The useful question is whether the organisation can retain and reuse its assets if a component or supplier changes. Include these handover items:
- Data model, dictionary, controlled vocabularies and metadata.
- Repositories, dependencies, deployment instructions and applicable licences.
- An inventory of services, paths, schemas, consumers and owners.
- A documented export of organisation-owned data, attachments, styles and configuration.
- A tested transition and recovery plan for one critical flow.
Portability does not mean that every replacement is instant or cost-free. It means that constraints, unfinished work and usable assets are understood before renewal or exit.
Put accessibility and security into the prototype
Accessibility is not a late-stage automated scan. If a map, result panel or critical form cannot be used by keyboard or fails to communicate its state, a user loses an essential task. WCAG 2.2 provides testable criteria and makes clear that conformance applies to full pages, including responsive variations.
Likewise, “it has usernames and passwords” is not an access policy. Define information categories, roles, permitted actions, required audit trails, accountable owners and revocation procedures. A public layer, internal layer and layer containing personal information should not inherit the same rule for convenience.
Make acceptance survive the next day
The final test should use an agreed cutoff date, environment and set of cases. Run critical tasks with the people who know them, test unauthorised roles, simulate at least one unavailable source, and confirm that help, provenance and limitations remain visible.
Keep the outcome: deployed version, data used, issues, owners, acceptance decisions and open items. That turns the portal from a visual deliverable into an operable capability.
If you need to define scope before publishing a procurement or renewing a platform, GeoSAT can assess workflows, architecture and acceptance evidence. Start by comparing the scope with what a geoportal costs: cost follows the operational responsibility being purchased, not just the first interface.