Constraints, requirements and criteria   Four different jobs Term Question answered Example Need Why is change needed? Workers lose time locating jobs. Requirement What must the solution do, or how well? Allow search by street or suburb. Constraint What limits the solution space? Must run on existing tablets. Criterion What observable evidence shows success? A worker finds a supplied job within 20 seconds. Traceability: each criterion should test a requirement, and each proposed feature should address a requirement while respecting constraints.   Functional and non-functional requirements Functional requirements state what the solution does: inputs, processes, outputs, data exchange and user actions. Non-functional requirements state how well or under what quality conditions it operates: useability, security, performance, reliability, compatibility and maintainability. “The user can submit a report” is functional. “A valid report is confirmed within two seconds” adds performance and feedback quality. Classify requirements Store an equipment loan. Only authorised staff can issue refunds. Return search results within two seconds. Display all bookings for a selected date. Check your answer Functional. Non-functional security requirement attached to a function. Non-functional performance requirement. Functional.   Find constraints in the context Constraints can concern time, cost, technology, compatibility, data, people, law, environment or scope. Constraint Possible design effect Four-week development window Prioritise essential scope and existing libraries. Existing low-storage server Limit retained media, compress where appropriate and define retention. Unreliable field connectivity Cache essential data and queue updates safely. Personal information involved Minimise collection and implement appropriate privacy and security controls. A constraint is not automatically a flaw. It becomes useful analysis when its effect on design, risk or testing is explained. Explain an impact A mobile app must use the school's existing server, which has limited storage. Explain one consequence for an image-reporting feature. View a sample solution Unrestricted full-resolution uploads could exhaust storage and make the service unavailable. The design should resize or compress images to an agreed quality, limit quantity and apply a justified retention rule.   Write strong criteria A strong criterion is specific enough to test and relevant to the user and requirement. Under [condition], [user or system] can [observable behaviour] with [measurable or clearly judgeable result]. Weak Stronger The app is accessible. Every interactive control can be reached and operated using keyboard navigation in a logical order. Search works. Given a known student ID, the search displays the correct student as the first result. Data is secure. A volunteer account cannot view health notes or perform a refund.   Avoid false precision Numbers are helpful when they come from the context or a reasoned target. Do not invent “99.99% accurate” merely to sound measurable. Some qualities are tested through observable tasks and evidence rather than arbitrary percentages. A useful set of criteria covers normal, boundary and error conditions. For a capacity rule, test one below capacity, exactly at capacity and one above it. Refine a criterion The requirement is “Users must recover from an accidental cancellation.” Determine a testable criterion. View a sample solution After cancelling a booking, a user can activate Undo from the confirmation message and restore the same booking details before leaving the screen.   Build a traceability table Need Requirement Feature Criterion Find nearby safe routes Filter routes by accessibility Accessible-route filter Selecting the filter removes every route marked inaccessible Protect private records Limit access by role RBAC A visitor account receives no private record data Traceability reveals orphan features that address no need, requirements with no implementation and criteria that test the wrong behaviour.   Resolve competing requirements Requirements may trade off rather than fit perfectly together. Detailed data may improve personalisation but increase privacy risk. Immediate synchronization improves freshness but may fail with unreliable connectivity. High-resolution media improves detail but increases storage and transfer time. Frequent confirmation can reduce some errors but interrupt routine work. Use the scenario's priorities and consequences to justify a balance. Do not declare one quality universally more important. Analyse a trade-off A field app needs recognisable damage photos but must operate on slow connections and limited storage. Recommend a balanced requirement. View a sample solution Resize and compress uploads to the lowest tested resolution that still lets staff classify the damage, queue them while offline, and retain originals only when a case is escalated. This protects useful visual detail while reducing routine transfer and storage demand.   Evaluate with test evidence State whether each criterion is met, partially met or not met, using actual results. Criterion Result Judgment Search within 2 seconds for 5000 records 1.4 seconds Met under tested condition Clear field error without losing valid input Message displayed, but all fields cleared Partially met   Independent practice: emergency relief hub A temporary relief hub needs a tablet app to record supply requests. Internet access is intermittent; existing tablets have limited storage; volunteers change each shift; and medical notes must be visible only to authorised health staff. The app must record a request, show its status, work during short outages and synchronise safely later. Recognise three constraints and Explain one design effect of each. Determine four functional and three non-functional requirements. Write one observable criterion for offline operation, access control, synchronisation integrity and useability. Justify how each criterion traces to a requirement. View a sample solution Constraints: intermittent internet requires a local queue; limited storage requires minimal cached data and retention; changing volunteers requires learnable interfaces and individual or shift-appropriate access. Functional: create request, view status, store while offline, synchronise queued records. Non-functional: role-based confidentiality, no duplicates during retry, clear first-use workflow. Offline: a valid request remains available after restarting the tablet without connectivity. Access: a volunteer account cannot retrieve medical notes; a health role can retrieve only relevant notes. Integrity: retrying the same queued request creates exactly one server record with the same local identifier. Useability: a first-time volunteer completes a supplied request scenario without assistance and sees a clear saved-offline status.