Learning Objectives
- Explain abstraction in the analysis of a computational problem.
- Identify the problem, users needs and functional requirements from a scenario.
- Separate relevant information from irrelevant detail.
- Write precise requirements that can later be designed and tested.
Key Terms
- Abstraction
- Removing or ignoring unnecessary detail so attention is focused on information relevant to the solution.
- Requirement
- A statement describing something the solution must do or a condition it must satisfy.
- Problem identification
- Defining the exact task or difficulty that the computer solution must address.
- Functional requirement
- A required operation or behaviour, such as calculating a total or producing a report.
- Constraint
- A limit or condition that affects the solution, such as an allowed range of input values.
- Specification
- An organised description of the problem and the requirements for the solution.
Analysis Begins With The Real Problem
A scenario may contain background information, opinions and descriptive detail. The developer must determine the actual computational problem. A shop may be described as busy, friendly and located near a station, but a stock program may only need product code, quantity, reorder level and supplier details.
The problem should be expressed in a way that leads to a measurable solution. “The shop has stock difficulties” is vague. “The system must identify each product whose quantity is below its reorder level and output its code and required reorder quantity” is precise enough to design and test.
Abstraction
Abstraction keeps the important features and removes detail that does not affect the solution. It does not mean making an answer vague. Instead, it creates a simpler model of the real situation.
For a library-loan calculation, the borrowers hair colour and the colour of the library walls are irrelevant. The membership number, date borrowed, due date and date returned may be relevant. The decision depends on the problem, so the same item can be relevant in one system and irrelevant in another.
Abstraction helps reduce complexity, prevents unnecessary data collection and makes the later algorithm easier to understand. It can also improve privacy because the system does not store personal information that it does not need.
Identifying Requirements
A requirement states what the solution must achieve. Requirements often describe input rules, calculations, decisions, stored values and outputs. They should be written so a tester can decide whether each one has been met.
Words such as “quickly,” “nicely” or “correctly” may be too vague unless a measurable condition is supplied. A better statement is: “After a valid product code is entered, the program must display the current quantity and reorder level.”
From Scenario To Requirement List
| Scenario Detail | Analysis Decision | Reason |
|---|---|---|
| Marks are entered for six subjects | Keep as an input requirement | The values are needed for calculations |
| The student wears a blue uniform | Remove through abstraction | It does not affect the result |
| Each mark must be 0 to 100 | Keep as a constraint and validation requirement | Invalid marks must be rejected |
| The average and pass/fail result are required | Keep as output requirements | They define the result the program must produce |
| The teacher prefers green text | Usually irrelevant unless explicitly required | It does not change the algorithmic solution |
Questions To Ask During Analysis
- What exact problem is being solved?
- Who will use the solution and what do they need from it?
- What data must be input and in what form?
- What processing or decisions are required?
- What results must be output?
- What data must be stored for later use?
- What limits, formats or rules apply to the data?
- Which details can be removed because they do not affect the solution?
Why Good Analysis Matters
A correct program that meets the wrong requirements is not a successful solution. Clear analysis creates a common understanding of the task and provides a basis for design and testing.
Each important requirement should later be represented in the design and covered by at least one test. This trace from requirement to design to test is why precise analysis reduces omissions.
Worked Examples
Cinema Ticket Scenario
Question: A cinema wants a program to calculate ticket cost. Children under 12 pay 6, all other customers pay 10. Identify relevant and irrelevant information.
- Relevant input: age.
- Relevant process: compare age with 12.
- Relevant output: ticket cost.
- Possible relevant constraint: age must be within an accepted range.
- Irrelevant details: seat colour or the customers favourite film, unless the scenario makes them part of the price.
Answer: Abstraction retains age, pricing rules and cost output while removing details that do not affect the calculation.
Improving A Requirement
Question: Improve the requirement “The program should handle marks properly.”
- Identify the required input rule.
- Identify the calculation.
- Identify the output.
Answer: For example: “The program must accept five integer marks from 0 to 100, reject any invalid mark, calculate the average and display the average.”
Examination Guidance
- Quote or paraphrase relevant facts from the scenario when applying abstraction.
- State why a detail is irrelevant rather than merely crossing it out.
- Write requirements using “must” and a measurable action.
- Do not invent extra requirements unless the question asks you to suggest them.
- Connect validation limits and required outputs to the specification.
Common Mistakes
- Defining abstraction as hiding all details, including necessary ones.
- Treating every sentence in a scenario as required data.
- Writing requirements that describe implementation instead of the required result.
- Using vague phrases that cannot be tested.
- Ignoring limits or formats stated in the question.
Knowledge Check
1. What is abstraction?
2. Why should requirements be testable?
3. Give one example of a functional requirement.
4. What is a constraint?
5. Does abstraction always remove the same details?
