B. Software Development · Software Development: Problem Solving, Design, Testing and the Life Cycle

The Software Development Life Cycle and Clarifying Specifications

B4.1 B4.2About 70 minutes

Learning goals

I can name and describe the seven phases of the software development life cycle in order.
I can give the milestones and products (deliverables) of each phase.
I can use dialogue, questionnaires, surveys and research to clarify what a client really needs.
I can turn a vague request into a clear written specification.

Words to know

software development life cycle (SDLC)
The series of phases a software project goes through, from defining the problem to maintaining the finished program.

phase
One stage of the life cycle: problem definition, analysis, design, writing code, testing, implementation or maintenance.

milestone
A checkpoint with a date, marking that something important is finished, such as "specification approved by Oct 30".

product (deliverable)
Something a phase produces and hands on: a specification, a flow chart, the program, documentation, bug reports.

client
The person or group the software is being made for.

requirement
Something the software must do (functional) or a quality or limit it must meet (non-functional), such as "runs on school laptops".

specification
A written description of exactly what the program must do, agreed with the client before design starts.

questionnaire / survey
A set of written questions given to many people to gather their needs or opinions.

Software has a life story

A school's student council asks you: "Can you make an app for the winter carnival?" You could start coding tonight. But what exactly should it do? Sell tickets? Show a schedule? Who will use it, on what devices? What happens after the carnival?

Professional teams follow a software development life cycle (SDLC): a series of phases, each with milestones (dated checkpoints) and products (things it delivers). The Ontario curriculum names seven phases. Following them is how real projects avoid building the wrong thing, or building the right thing badly.

The software development life cycle. Each phase produces a product that the next phase uses. After maintenance, new needs can start the cycle again.

Phase	Key question	Typical products
1. Problem definition	What problem are we solving, for whom?	problem statement, project goals
2. Analysis	Exactly what must the program do? Is it possible?	specification (requirements), IPO charts, interview notes
3. Design	How will it work?	structure charts, flow charts, pseudocode, screen designs, test plan draft
4. Writing code	Build it	the program, with comments
5. Testing	Does it meet the specification?	completed test plan, bug reports, fixes
6. Implementation	Get it to the users	installed program, user guide, training
7. Maintenance	Keep it working and useful	bug fixes, updates, change log

The seven phases with their main products. Example milestones: "specification approved" (end of analysis), "all modules coded", "all tests pass", "program installed".

Waterfall or cycles?

In the waterfall model, each phase is finished before the next begins, like water falling down steps. It is simple and suits small, well-understood projects (like many school assignments).

Many teams today work iteratively (agile methods are a popular family of these): they go through all the phases quickly to build a small working version, show it to the client, and repeat, adding features each cycle. Feedback arrives early, so misunderstandings are caught when they are cheap to fix.

Either way, the same phases and products appear. In iterative work they just happen many times, in small pieces.

Two ways to move through the phases. Waterfall finishes each phase once, in order; iterative development repeats short cycles and delivers a working version each time.

Worked example

Example 1: Phases, milestones and products

The student council wants a winter-carnival ticket app, needed for February 12. Lay out the phases with a product and a milestone for each.

Problem definition (week 1): meet the council. Product: problem statement: "Students need a quick way to buy carnival tickets and see the schedule." Milestone: statement approved, Jan 9.
Analysis (week 2): interview and survey users. Product: specification. Milestone: spec signed off, Jan 16.
Design (week 3): product: structure chart, screen sketches, test plan. Milestone: design review, Jan 23.
Coding (weeks 4-5): product: working program. Milestone: all modules done, Feb 2.
Testing (week 5-6): product: test results and bug reports. Milestone: all tests pass, Feb 6.
Implementation: product: app installed on the office computer, user guide. Milestone: live, Feb 9.
Maintenance: fix problems reported during the carnival; product: change log.

Every phase has a dated milestone and a concrete product. If a milestone slips, the team knows immediately.

Clarifying the specification

The most expensive bugs are misunderstood requirements: code that works perfectly but does the wrong thing. During analysis you clarify the specification with:

Dialogue (interviews): talk with the client and users. Ask open questions ("Walk me through how tickets are sold now") and then specific ones ("Can one student buy tickets for friends?"). Repeat back what you heard.
Questionnaires and surveys: written questions for many users at once. Use closed questions (choices, ratings) to count answers and a few open ones for ideas.
Research: look at the current system, similar apps, school rules, laws (for example, privacy of student information).
Prototypes: a rough sketch of a screen often gets better feedback than any question.

Then write the specification: purpose, users, inputs, outputs, functional requirements, limits (non-functional requirements), and how you will know it is done (acceptance criteria).

Worked example

Example 2: From vague to specific

The council says: "The app should handle ticket sales." Write five clarifying questions, then turn possible answers into specification statements.

Who buys? → "Only students and staff with a school ID number can buy."
What does a ticket cost, and are there types? → "Day pass $5, full carnival pass $12."
Is there a limit? → "Each ID may buy at most 4 passes."
How do people pay? → "Payment is cash at the office; the app records sales and prints a receipt number."
What reports are needed? → "At the end of each day, show the number of each pass sold and the total money."
Each statement is testable: you can later check "Did buying a fifth pass get refused?"

Five clear, testable requirements replace one vague sentence.

Worked example

Example 3: Summarizing a survey

Seven students answered the survey question "How would you like to receive your pass?" (pickup / delivery to class / either). Write a program to summarize the results as counts and percentages.

Store the answers in a list.
For each option, responses.count(option) counts the matching answers.
Percentage = count ÷ number of responses × 100, rounded to a whole number.
Result: pickup 4 (57%), delivery 2 (29%), either 1 (14%). The requirement becomes: "Passes are picked up at the office." (Here the rounded percentages happen to add to 100%. With other data, rounding can make them add to 99% or 101%; that is normal.)

Most students prefer pickup, so the spec does not need a delivery feature.

responses = ["pickup", "delivery", "pickup", "pickup", "either", "delivery", "pickup"]

for option in ["pickup", "delivery", "either"]:

count = responses.count(option)

print(option, count, f"{count / len(responses) * 100:.0f}%")

Output: pickup 4 57% / delivery 2 29% / either 1 14% (one line each)

Just for fun

A programmer's family member says, "Please go to the store and buy a litre of milk. If they have eggs, get a dozen." The programmer comes home with 12 litres of milk. They had eggs.

Moral: always clarify the specification.

Hands-on activity

Interview a client at home

You need: a family member to play the client, paper and a pencil.

Your client wants "an app to help with chores". Interview them for 10 minutes. Start with open questions ("What goes wrong with chores now?"), then specific ones (Who? How often? Any rewards? What device?). Take notes.
Write a short questionnaire (5 questions, at least 3 closed) you could give to the whole family. Give it to two or three people and tally the answers.
Write a specification: purpose, users, at least five testable requirements, and one non-functional requirement (for example "works on the family tablet").
Read it back to your client. Did they want anything you missed? Revise it.
Plan the seven phases with a product and a made-up milestone date for each.

What to look for: requirements that can be checked ("shows each person's chores for today"), not vague wishes ("is easy"); evidence that the client's feedback changed the spec.

Your turn

List the seven phases of the software development life cycle in order.

In which phase is the specification produced?

Name two products of the design phase.

What is the difference between a milestone and a product?

Name four techniques for clarifying a specification.

Rewrite this requirement so it can be tested: "The app should be fast."

Which phase does fixing a bug reported by a user three months after release belong to?

More practice: warm-up

What does SDLC stand for?

Is "Which colour do you prefer: blue, green or red?" an open or a closed question?

In which phase is the program installed for users?

Name one product of the testing phase.

In the waterfall model, is each phase finished before the next begins?

More practice: on your own

Give one advantage of the waterfall model and one of iterative development.

Write three interview questions (one open, two specific) for a coach who wants an app to track team practice attendance.

A survey of 40 students found 26 want reminders by text, 10 by email and 4 want none. Give each as a percentage.

Explain why mistakes found during analysis are cheaper to fix than mistakes found after implementation.

Classify each as functional or non-functional: (a) "prints a receipt number" (b) "works on Chromebooks" (c) "refuses a fifth pass for the same ID".

Challenge

The council approves the carnival spec on Jan 16. On Feb 1 they ask for online payment. Describe the effect on the life cycle and what the team should do.

Design a 5-question questionnaire to decide the features of a cafeteria pre-order app. Label each question open or closed and say which requirement it informs.

A team skipped the analysis phase and went straight from "make a chores app" to coding. Predict two problems they are likely to hit, naming the phases where each will appear.

Check your understanding

Quiz

Which list gives the SDLC phases in order?

A specification is mainly produced in which phase?

Which is a milestone?

Which question is best for clarifying a vague request?

Which requirement is testable?

Fixing a bug that users report after release happens in:

For parents and teachers

Big idea: B4.1 asks students to describe the phases, milestones and products of a software development life cycle; B4.2 asks them to clarify program specifications using techniques such as dialogue, questionnaires, surveys and research.

How to help: Play the client in the interview activity. Be a little vague on purpose ("I just want it to be nice") and let your teen practise asking follow-up questions. Ask to see the specification they write and check: could you tell whether the finished program meets each sentence?

Common difficulties:

Mixing up milestones (dates) and products (things).
Writing requirements that cannot be tested ("easy", "fast", "good").
Skipping analysis and design on school projects, then running out of time.
Forgetting maintenance: software keeps living after it is handed in.