Usability Requirements That Cannot Fail
FieldServe is launching a scheduling app for 45 field technicians and 6 dispatchers. The requirements document states: 'The app must be intuitive,' 'Dispatchers must be able to schedule jobs fast,' and 'The app must be accessible on mobile devices.' No metrics, target users, or tasks are specified. The validation plan consists of a single question: 'Do you like it?' The project manager argues that usability is verified by the UI designer's review, so no user validation is needed. The test team has written 12 functional test cases but no usability tests. The contract includes a penalty if dispatchers cannot schedule 90% of urgent jobs within 2 minutes, but no one has linked that business goal to a requirement. The first release candidate is due in 8 weeks. Two technicians use screen readers, and one dispatcher has color-vision deficiency. The product owner wants to avoid 'over-engineering' and proposes deleting all non-functional requirements.
1. Rewrite the three statements as verifiable requirements. State the user, task, context, metric, and acceptance threshold for each, and note what still needs validation.
Read the worked answer
Verifiable versions: (1) 'After 30 minutes of training, at least 90% of representative dispatchers shall schedule an urgent job, defined as selecting an available technician, assigning the job, and confirming it, in 2 minutes or less, measured in a usability test with 8 dispatchers using realistic job data; no participant shall take longer than 3 minutes.' (2) 'At least 85% of representative field technicians shall complete the three most frequent scheduling tasks, view today's jobs, accept a job, and mark a job complete, without assistance on first attempt, measured in a moderated usability test with 10 technicians.' (3) 'The mobile app shall conform to WCAG 2.2 level AA for the scheduling workflows, verified by automated checks plus manual testing with two screen-reader users, and shall not rely on color alone to distinguish job status.' These are testable but still need validation with real users: the 90%/2-minute target is inferred from the contract penalty, and 'representative' must be defined by role, experience, and device. The requirements should be confirmed with dispatchers and technicians, not imposed by the product owner alone.
2. The project manager says a UI designer's review verifies usability. Explain the difference between validation and verification in this case, and design a validation approach that covers the two screen-reader users and the dispatcher with color-vision deficiency.
Read the worked answer
Verification asks 'Did we build the product right?' against specified requirements; validation asks 'Did we build the right product?' against user needs and intended use. A UI designer's review can verify consistency with a style guide or a heuristic, but it is not validation with representative users performing real tasks. Validation requires observing actual dispatchers and technicians using the system in realistic conditions. Design: recruit 8 dispatchers and 10 technicians, including at least two screen-reader users and one user with color-vision deficiency; run moderated sessions with task scenarios drawn from the contract goal (urgent job scheduling within 2 minutes) and daily field tasks. Measure completion, time, errors, assistance requested, and satisfaction; use think-aloud only where it does not distort timing. Test with the assistive technologies the users actually use, not a simulation. Include a debrief on workarounds and error recovery. Record findings against requirements and feed defects into the backlog. This approach validates both effectiveness and accessibility; a designer review alone would miss interaction failures that only appear under real task load.
3. The product owner proposes deleting all non-functional requirements to avoid over-engineering. How should the requirements engineer respond, and what should happen to the NFRs?
Read the worked answer
Deleting all NFRs would remove the very requirements that carry contractual and usability risk. The contract penalty depends on dispatchers scheduling 90% of urgent jobs within 2 minutes, which is a performance and usability NFR, not a nice-to-have. Accessibility is also a legal and ethical obligation for the two screen-reader users, and color-only status would fail the dispatcher with color-vision deficiency. The engineer should reframe the discussion from 'delete NFRs' to 'right-size NFRs': keep the ones tied to business goals, contract terms, legal obligations, and user safety; quantify them; and defer only those with no credible stakeholder or evidence. Use the traceability link from the penalty to the scheduling requirement to show why it cannot be cut. Propose a small NFR set: scheduling time, task success, accessibility conformance, availability during shift change, and data freshness. For each, state measurement method and acceptance threshold. If the product owner still wants to cut, record the decision as a risk with owner and consequence. The goal is not to defend every NFR; it is to prevent silent acceptance of untestable or unmet user needs.