INFO1111 Chap.6 Problem Solving and Requirements
Problem Solving and Requirements
This chapter covers the Week 3 problem-solving lecture and the requirements example that supports the Skills assignments. It starts with the principle that you must understand a problem before solving it, which in professional computing means problem and requirement specifications and a clear view of constraints, illustrated by the story of hotel guests whose complaint about slow lifts hid a different problem.
It lists five kinds of computing problem, from making something to persuading people, and explains how to elicit requirements from stakeholders who cannot always say what they need. It separates functional requirements, what a system does, from non-functional qualities such as performance, usability, cost and security, and insists that every requirement be paired with a way to evaluate it.
It then works through turning a vague request into a precise requirement and a state-based test, and ends with six common flaws and a self-check for missing cases, undo actions, edge cases and testability.
What this chapter covers
- 01
Understanding the problem before solving it
- 02
Reframing a complaint into the real need
- 03
Five kinds of computing problem
- 04
Eliciting requirements from stakeholders
- 05
Functional requirements and non-functional qualities
- 06
Pairing each requirement with an evaluation
- 07
Writing state-based tests with refusals and edge cases
- 08
Six flaws and the self-check
Worked example · free
Making a ticket-refund requirement testable
- +1Question it: which tickets, until when, how much is returned, and what does the customer see?
- +1Rewrite: a customer may request a refund for an unused ticket up to 48 hours before the show; the system returns the full price to the original card and confirms the amount and date.
- +1Test: a $60 ticket for a show 72 hours away is refunded; the confirmation shows $60, and the seat returns to sale.
- +1Refusal: a request 24 hours before the show is refused with the 48-hour rule shown. Edge: a request at exactly 48 hours succeeds.
Key terms
- Functional Requirement
- A statement of what a system does, often as an input and output relationship at the level of user needs.
- Non-functional Requirement
- A quality the system must have, such as performance, ease of use, cost, security or ease of change.
- Stakeholder
- A person or group affected by a system or problem whose needs must be found out and considered.
- Edge Case
- An unusual or boundary situation, such as a value exactly at a limit or a search with no matches.
- Problem Specification
- A clear statement of the problem to be solved, including its constraints, written before solutions are chosen.
Problem Solving and Requirements FAQ
What is the difference between functional and non-functional requirements?
A functional requirement states what the system does, usually as inputs and outputs. A non-functional requirement states a quality, such as how fast, how secure, how easy to use or how costly the system is.
Why should every requirement have an evaluation?
Without a way to check it, nobody can tell whether the requirement was met. The lecture pairs every requirement with an evaluation plan, usually a test for a system.
What makes a requirement bad?
The lecture lists six flaws: incorrect, incomplete, vague, conflicting, missing and solution-focused. Statements such as good usability or error-free cannot be tested as written, so a tester could never say whether they passed.
What should a test for a requirement include?
The starting state, the request, the expected response and the state afterwards, plus cases where the request should be refused and cases exactly at a limit.
What kinds of problems do computing professionals solve?
Building something that meets a need, repairing something that works badly, judging whether something works, deciding what to make or do, and persuading people to make or do something.
Exam move
Take three everyday systems you use, such as a library catalogue, a food-ordering app and a timetable site, and write two functional requirements and one non-functional requirement for each, with a measurable target for the quality. For every requirement, write the test before you move on: starting state, request, expected response and final state.
Then attack your own list with the self-check: is there a way to undo each action, what happens with no results or several, and could a stranger decide pass or fail from your words alone? Practise reframing too: each time you hear a complaint about a system this week, write the stated problem and the need underneath.
For the Skills Foundation assignment, keep your requirements about what the system ought to do, not what it currently does. When you review a classmate's requirements, swap roles: you act as the tester and they defend each line, which quickly shows which statements a tester could never judge. Keep a personal list of the vague words you catch yourself using, and ban them from your next draft.
Working through Problem Solving and Requirements in INFO1111? Sia is AskSia’s AI Computer Science tutor — ask any INFO1111 Problem Solving and Requirements question and get a clear, step-by-step explanation grounded in how INFO1111 is taught and assessed. Read this chapter free, then take your hardest questions to Sia.
