Skip to content

c. Practical Examples

Interpreting Requirements and Designing Solutions

These examples use a light I do - We do - You do model. The aim is to make students classify, justify and represent ideas before they see a model response.

Example 1 - I do: Classifying requirements from a brief

Scenario

A school wants a small app that lets students check club meeting times and book a place in a session.

The brief says:

  • students must be able to select a club and submit a booking
  • the interface must be easy to use on a laptop
  • the solution must be completed using existing school devices
  • the first version will not include email reminders

Try first

Before opening the teacher walkthrough, identify:

  1. one functional requirement
  2. one non-functional requirement
  3. one constraint
  4. one item that is out of scope
Teacher walkthrough

A strong response could identify:

  • Functional requirement: students must be able to select a club and submit a booking
  • Non-functional requirement: the interface must be easy to use on a laptop
  • Constraint: the solution must use existing school devices
  • Out of scope: email reminders are not included in the first version

Focus: Good analysis starts by separating actions, qualities, limits and excluded features.

Exam link: Students are often asked to classify statements from a scenario rather than define terms in isolation.

Example 2 - We do: Writing a scope statement

Scenario

A class is planning the first version of a School Event Ticket Tool.

Included requests:

  • display event names
  • let users choose ticket quantity
  • calculate total price

Not included in version 1:

  • online payment
  • staff reporting dashboard

Try first

Write:

  1. one sentence describing what the solution will do
  2. one sentence describing what the solution will not do
One possible model response

In scope: The solution will display event names, allow a user to choose a ticket quantity, and calculate the total ticket cost.

Out of scope: The first version will not process online payments or include a staff reporting dashboard.

We do prompt

If your wording differs from the model but still clearly sets boundaries, that is acceptable. Scope writing is about clarity, not memorising one exact sentence.

Focus: Scope statements should make boundaries obvious to both the developer and the client.

Exam link: Clear scope helps prevent feature creep and later disagreement.

Example 3 - We do: Choosing design tools for a payroll calculator

Scenario

A simple payroll calculator needs to:

  • accept hours worked and hourly rate
  • calculate gross pay
  • calculate tax and superannuation
  • calculate net pay
  • display the final results clearly

Try first

Choose the best design tool for each purpose:

  1. showing the screen layout
  2. showing the data flow from input to output
  3. showing the processing logic step by step
One possible model response
  • Mock-up for the screen layout
  • IPO chart for the data flow from input to output
  • Pseudocode or flowchart for the processing logic step by step
Why these choices work
  • A mock-up shows what the user will see and interact with.
  • An IPO chart separates inputs, processing and outputs clearly.
  • Pseudocode or a flowchart helps represent the sequence of calculations and decisions before coding.

Focus: Different design tools solve different planning problems.

Exam link: Students should justify the choice of design tool, not just name one.

Example 4 - You do: Quick design representation task

Scenario

A student is designing a canteen order form.

The solution should:

  • accept a student name
  • let the user choose one lunch item
  • calculate the total cost
  • confirm that the order has been submitted

Your task

From memory, decide:

  1. What would a mock-up need to show?
  2. What would go in the Input column of an IPO chart?
  3. What would go in the Output column?
  4. What logic would need to appear in pseudocode?

Retrieval Prompt

Try to answer without notes first, then check your ideas against the What You Need To Know page.

Focus: Planning is strongest when students can move from a brief to the right representation quickly.

Example 5 - You do: Retrieval grid

Complete the table from memory.

Term What does it mean? Why does it matter?
Functional requirement
Non-functional requirement
Constraint
Scope
Mock-up
IPO chart
Pseudocode

Study Tip

Retrieval is more effective when you force yourself to recall a term, then compare your answer with the notes afterwards.