Client requirements

A client rarely asks for a ground sample distance or a root mean square error. Claire Fontaine asks, Is the slope below the new houses moving, and should we worry? Marta Kowalchuk asks whether the canal bank is eroding and whether she needs to reline the reach before next season. Turning questions like these into requirements that can be measured, tested and signed off is the first technical task of the capstone, and it decides almost everything that follows: which methods to use, how many checkpoints to survey, how long the processing will take and what the final report must prove.

This lesson follows the Coulee Watch team through that translation. It covers how to interview a client, how to separate needs from wishes, how to write requirements that can be verified, how to express accuracy in the language of current mapping standards, and how to set a change detection requirement that matches the movement the clients care about.

Listening before specifying

The team holds a requirements meeting with both clients in week two. Nadia runs it from a short list of open questions. What decisions will you make with the results? What would change your mind? What movement or erosion would worry you, and over what time? Who else will use the data? What format do your staff use? Are there places we must not go or data we must not publish? Each answer is written down in the client's own words before the team rewrites it as a requirement.

The answers are revealing. Claire's real decision is whether to require extra monitoring from the developer before the next phase of building permits is released, and whether to warn the owners of the lots along the crest. She needs to know whether movement is happening at all, roughly where, and how confident the team is. Marta's decision is about money: relining the 400 m of canal at the slope foot would cost a large share of her annual maintenance budget, so she wants to know which part of the reach is eroding and how fast. Both want the data in a form that their own staff and future consultants can open.

The team also asks about constraints. The canal must be dry for survey. Private lots along the crest may not be entered without written permission. The slope includes locations that the project's cultural resource monitor has asked to be kept confidential. Imagery that looks into back yards must not be published. These constraints become requirements too.

Needs, wishes and requirements

A need is something the client must have to make the decision. A wish is something that would be nice. A requirement is a statement of a need written so that it can be verified. Good requirements share a few properties: each one says one thing, it can be tested, it states a quantity and a tolerance where a number matters, and it is traceable to a client need. Words such as accurate, detailed, high resolution or as soon as possible are not requirements, because nobody can test them.

Accuracy in the language of the standards

Mapping accuracy in North America is now usually stated using the ASPRS Positional Accuracy Standards for Digital Geospatial Data. Edition 2, published in 2023 and revised in 2024, reports accuracy as a root mean square error only and no longer uses the 95 percent confidence values of earlier practice. A product is said to meet an accuracy class of a given size, for example a horizontal class of 4 cm, when its tested RMSE is no larger than that value. Edition 2 also asks for at least 30 checkpoints for a project, scaling up with area, expects checkpoints to be at least twice as accurate as the product being tested, and has the checkpoint survey error included in the reported accuracy. Vegetated vertical accuracy is reported but is no longer a pass or fail test.

US agencies widely use the ASPRS classes, and the USGS lidar base specification adopted Edition 2 for its quality levels. Using a recognized standard lets the client compare bids, lets reviewers check the work and makes the final accuracy statement meaningful to people who were not in the room.

Coulee Watch adopts three accuracy requirements. The control network must give coordinates whose relative accuracy is good to about 1.5 cm horizontally and 2.5 cm vertically. The orthomosaic must meet a 4 cm horizontal accuracy class. The terrain model must meet a 5 cm vertical accuracy class in open, non-vegetated ground. These numbers are not arbitrary: the next section shows they come from the change the clients want to detect.

From the change you want to detect to the accuracy you need

When two surveys are compared, the error in the difference combines the errors of both. If each epoch has a vertical error with standard deviation sigma one and sigma two, and the errors are independent, the standard deviation of the difference is the square root of the sum of their squares. To be 95 percent confident that a difference is real and not noise, it must exceed about 1.96 times that value. This threshold is the level of detection.

Turned around, the formula gives the accuracy each epoch needs. If both epochs have the same accuracy sigma, the level of detection is 1.96 times root two times sigma, or about 2.77 sigma. To detect a change of 10 cm, each epoch must have a vertical RMSE of about 3.6 cm or better. That is why the team asks for a 5 cm class as the formal requirement but aims for 3.6 cm in practice: the class proves the product is sound, and the tighter target makes the change detection work.

# Coulee Watch: what per-epoch vertical accuracy lets us detect a given change?
import math
z95 = 1.96
def lod(s1, s2):                  # level of detection at 95 % for two independent epochs
    return z95 * math.sqrt(s1 ** 2 + s2 ** 2)
def sigma_needed(change):          # equal accuracy in both epochs
    return change / (z95 * math.sqrt(2))
for target in (0.05, 0.10, 0.15, 0.20):
    print(f"detect {target * 100:4.0f} cm change  needs RMSEz <= {sigma_needed(target) * 100:4.1f} cm per epoch")
print()
for s in (0.02, 0.036, 0.05, 0.08):
    print(f"RMSEz {s * 100:4.1f} cm in both epochs  ->  level of detection {lod(s, s) * 100:5.1f} cm")
# requirement traceability: each requirement must map to a test
reqs = {"R1 control network": "network adjustment and repeat sessions",
        "R2 orthomosaic": "independent checkpoints (horizontal)",
        "R3 terrain model": "independent checkpoints (vertical, open ground)",
        "R4 change detection": "stable-area difference test",
        "R5 slope targets": "repeat total station sets",
        "R6 InSAR summary": "comparison with target movement",
        "R7 web map": "accessibility checklist and contrast test",
        "R8 report and metadata": "client review",
        "R9 data handover": "checksum manifest and data terms"}
print()
print(f"{len(reqs)} requirements, {sum(1 for v in reqs.values() if v)} with a verification method")

detect    5 cm change  needs RMSEz <=  1.8 cm per epoch
detect   10 cm change  needs RMSEz <=  3.6 cm per epoch
detect   15 cm change  needs RMSEz <=  5.4 cm per epoch
detect   20 cm change  needs RMSEz <=  7.2 cm per epoch

RMSEz  2.0 cm in both epochs  ->  level of detection   5.5 cm
RMSEz  3.6 cm in both epochs  ->  level of detection  10.0 cm
RMSEz  5.0 cm in both epochs  ->  level of detection  13.9 cm
RMSEz  8.0 cm in both epochs  ->  level of detection  22.2 cm

9 requirements, 9 with a verification method

The script also checks the traceability matrix, the table that links each requirement to a verification method. Every one of the nine requirements has a test. A requirement without a test is a wish that has not been admitted to yet.

Horizontal movement and the slope targets

Vertical change on a terrain model is not enough to understand a slope. A slump can move a block downslope several centimeters while barely changing its surface height. For horizontal movement the team uses twelve targets: steel pins with prism adaptors, set in the slope and measured by total station from the control marks in each epoch. With careful observation each target coordinate can be determined to about 4 mm per axis. The difference between epochs then has a standard deviation of about 5.7 mm per axis, and in two dimensions a movement must be larger than about 2.45 times that, or 14 mm, to be significant at 95 percent. Requirement R5 therefore says 15 mm.

The radar interferometry data, discussed in lesson 3, add a third view. They measure millimeters of movement per year but only along the satellite's line of sight and only where the ground keeps a stable radar signature. The team treats them as a regional indicator, not as a measurement of individual targets, and writes requirement R6 accordingly: summarize the published or processed radar velocities over the slope and compare them with the target movement.

Deliverables and formats

Deliverables are part of the requirements because a correct result in an unusable format fails the client. Claire's staff use a web-based municipal GIS. Marta's engineers use desktop GIS and CAD. Both want files that will still open in ten years. The team agrees on open formats: cloud-optimized GeoTIFF for rasters, GeoPackage for vectors, LAS 1.4 compressed as LAZ for point clouds, CSV for target coordinates, and a PDF report. Every dataset carries metadata describing its datum, epoch, accuracy and lineage. Coordinates are delivered in NAD83(2011) on the project's low-distortion projection, with NAVD 88 heights, and the report explains how they will transform to the modernized national datums.

Agreeing the requirements

The requirements are sent to both clients as a short document, and the team walks them through it at a second meeting. Two changes come out of that meeting. Marta asks for canal cross-sections every 25 m along the reach, which is easy to extract from the terrain model and is added as part of R3. Claire asks whether the team can give a single traffic-light rating for the slope. The team declines: a single color would hide the uncertainty and imply a geotechnical judgment the team is not qualified to make. Instead the report will state measured movement with its uncertainty and recommend that a geotechnical engineer interpret it. Both clients sign the requirements, and any later change goes through a written change request.

Requirements are not fixed forever. If the first epoch shows that the terrain model cannot reach 3.6 cm under the grass on the upper slope, the team will not quietly lower the bar. It will report the limitation, explain what level of change can still be detected there, and agree a change with the clients. That openness is part of professional practice and part of what the capstone is assessing.