Constraints, requirements and criteria

Constraints, requirements and criteria

Learning intention

WALT

We are learning to turn a real-world problem into clear requirements, constraints and measurable success criteria.

WILF

• Distinguish functional and non-functional requirements.
• Explain how constraints limit possible solutions.
• Write observable, context-specific criteria.
• Evaluate evidence against criteria and recommend refinements.

Cognitive verbs

• Recognise: identify facts or characteristics from what you know.
• Analyse: break down information to reveal relationships.
• Determine: use evidence or reasoning to reach a conclusion.
• Explain: make an idea or relationship clear by showing how or why.
• Evaluate: make a judgment about quality using evidence.
• Recommend: propose an appropriate action for the context.
• Justify: support a conclusion with evidence or reasoning.

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.

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

1. Store an equipment loan.
2. Only authorised staff can issue refunds.
3. Return search results within two seconds.
4. Display all bookings for a selected date.

Check your answer

1. Functional.
2. Non-functional security requirement attached to a function.
3. Non-functional performance requirement.
4. 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.

1. Recognise three constraints and Explain one design effect of each.
2. Determine four functional and three non-functional requirements.
3. Write one observable criterion for offline operation, access control, synchronisation integrity and useability.
4. 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.

Review and exit ticket

1. How do requirements and criteria differ?
2. What makes a criterion traceable?
3. Why test boundary and error cases?
4. When is a requirement non-functional?

Check your answers

1. A requirement states what is needed; a criterion states observable success.
2. It directly tests a named requirement and feature.
3. Normal success alone may hide failures at limits or invalid input.
4. When it defines quality or conditions such as security, performance or useability.

Exit ticket

Write one functional requirement, one constraint and one observable criterion for an event check-in app.