Stretch tasks Designing before building

Round 1: Quiz Blitz

1. Analysis → Design → Implementation → Testing → Evaluation → Maintenance Find out what is needed, plan it, build it, test it, judge it, then keep improving it.
2. The user can add a task in two taps A requirement must be something you can tick off as met or not met.
3. False Wireframes are deliberately plain so that discussion stays on layout and flow.
4. So discussion stays on layout and flow, not colours If a sketch looks finished, people argue about the blue instead of whether the screen works.
5. How the screens connect, and which buttons lead where It maps the journey between screens, so dead ends and missing links show up before anything is built.
6. Completed tasks move to a separate list; Saved tasks are still there when the app reopens You can check each of the first two with a clear yes or no. The others are opinions.
7. Evaluation Evaluation judges the finished app against the requirements written during analysis.
8. Each version fixes problems and adds features users need This is iterative development, which is why apps update so often.
9. True Designing before you understand the problem means designing the wrong thing.
10. Screens and features have to be rebuilt when problems show up late Problems found late are expensive, because working code has to be torn up and rewritten.
11. wireframe A wireframe shows where things go on one screen.
12. Maintenance Maintenance keeps the app working and useful after launch.

Round 2: Quick Fire

1. • Gives a measurable target, such as a number of seconds
   • Says which action it applies to
   Model answer

   The app opens and shows the task list within 2 seconds.

2. • To plan the layout and where everything goes
   • Because it is quick and cheap to change, so problems are found before coding
   Model answer

   A wireframe plans the layout of each screen and where everything goes. It is quick and cheap to change, so problems are found and fixed before any time is spent coding.

3. • Who is the app for?
   • What problem does it solve?
   • What must it do?
   • What limits are there, such as budget, devices or deadline?
   Model answer

   Who is the app for? What problem does it need to solve?

4. • A wireframe shows the layout of a single screen
   • A navigation diagram shows how the screens connect
   Model answer

   A wireframe shows the layout of a single screen: where each thing goes. A navigation diagram shows how the screens connect, and which buttons lead where.

Round 3: Big Think

1. • A requirement about adding subjects
   • A requirement about times or dates
   • A requirement about reminders
   • A requirement about saving
   • Each can be checked with a clear yes or no
   Model answer

   The user can add a subject with a name and a colour. The user can give each revision session a date and a start time. The app sends a reminder 10 minutes before a session starts. The timetable is saved and is still there when the app reopens. Each one is testable because it is specific and can be checked with a clear yes or no: either a reminder arrives 10 minutes before, or it does not.

2. • A small app or a prototype can be built quickly to try out ideas
   • You can learn what works by building it
   • Without analysis you may build something that does not solve the users' problem
   • Requirements give clear targets to test against
   • Wireframes are cheap to change, but rebuilding code is expensive
   • Planning the navigation makes sure the screens fit together
   • A plan lets a team, or a client, agree and give feedback early
   • A reasoned conclusion
   Model answer

   For a very small app, or a quick prototype to try out an idea, starting straight away can make sense, and you do learn by building. But for a real app the view is usually wrong. Without analysis you can spend weeks building something that does not solve the users' problem, and without requirements there is nothing to test against. Wireframes and a navigation diagram are cheap to change and show whether the screens fit together, whereas finding the same problems in finished code means expensive rebuilding. A plan also lets the team or client agree on the app and give feedback early. Overall, a little analysis and design saves far more time than it costs.

This or That

1. Analysis Analysis works out who the app is for and what it must do. Only then can you design it.
2. A requirement A requirement is a specific, testable statement of what the app must do.
3. Implementation Implementation is building it, once the design has been planned.
4. Planning where things go on a screen A wireframe sketches the layout of one screen. Testing comes much later.
5. A navigation diagram A wireframe shows one screen. A navigation diagram shows which buttons lead to which screens.
6. Evaluation After testing, evaluation asks whether the app actually solves the original problem.
7. So tasks are still there when it reopens Without saving, every task would vanish the moment the app closed.
8. No: nobody can test it A requirement must be specific and testable, such as: the user can add a task in two taps.

Memory Match

• A 3 Analysis: Who is it for and what must it do?
• B 5 Design: Planning the screens, the flow and the data
• C 2 Implementation: Building the app
• D 1 Testing: Checking it works, even when things go wrong
• E 6 Evaluation: Does it solve the original problem?
• F 4 Maintenance: Fixing problems and adding features