How can a program run without crashing and still be completely wrong? A program that calculates a total accurately but ignores the discount rule requested by its user may have perfect syntax and flawed requirements. Software engineering begins before the first line of code and continues after the first successful run. The aim is to produce a solution that addresses the actual problem, not merely one that executes.
Ministry of Education V3.0 Reference 361 explains the 2027 Singapore–Cambridge SEC G3 Computing K349 Module 2.6, Software Engineering. It follows the stages of gathering requirements, designing solutions, writing code, testing and refining, and deploying code, while showing why development may be iterative rather than strictly linear. Students, parents and tutors can use worked fictional projects, traceable acceptance criteria, test cases, short Python illustrations and a twelve-stage method to understand how robust computing solutions are built.
This independent eduKateSG study guide is not an official MOE, SEAB or Cambridge publication. The authoritative 2027 K349 syllabus defines the examinable scope. All app scenarios are invented educational exercises. Code snippets are illustrative and should be executed only in appropriate learning environments; real services require stronger testing, accessibility, privacy protection and operational safeguards than a school example can establish.
The one-minute model: problem, solution, evidence
A user has a task and a definition of success. The programmer turns that need into clear inputs, outputs and constraints, chooses an approach, implements it and checks whether it behaves as required. A good solution has both working code and evidence that it meets the right requirements. That evidence might be a test table showing expected and actual outputs for normal, boundary and invalid inputs.
For example, a fictional library program may be required to determine whether a book is overdue using a due date and a return date. A program that prints ‘overdue’ for every book executes successfully but does not solve the problem. The critical test is whether its result follows the rule for dates on both sides of the boundary.
1. The official K349 section 2.6 scope
The 2027 syllabus states that learners should understand and describe the stages of developing a program: gathering requirements, designing solutions, writing code, testing and refining code, and deploying code. It also asks students to recognise that the stages need not occur in a fixed linear sequence and that iterative development can sometimes be more appropriate.
Related syllabus areas support this lifecycle: section 2.1 identifies valid inputs and correct outputs; section 2.2 addresses sequence, selection and iteration through flowcharts; section 2.3 covers Python coding; section 2.4 addresses testing and debugging; and section 2.5 addresses algorithm design. This reference focuses on how those skills fit into a complete software-development process rather than presenting the stages as isolated vocabulary.
2. Gather requirements by asking what must happen
A requirement describes a necessary behaviour or constraint. Some requirements specify functional outcomes—what a program must do. Others specify important qualities, such as clarity, performance or safe handling of information. In a school-level programming task, start by identifying the user, the permitted inputs, the expected outputs and circumstances in which inputs must be rejected.
A weak statement might be ‘Make a good marks program’. A stronger statement is ‘Accept three scores between 0 and 100 inclusive, calculate the mean and display it to one decimal place’. The second can be tested. It also raises questions: May a user enter decimals? What happens if no valid score is given? Should the program terminate or ask again? Clarifying such questions before coding prevents needless rework.
3. Separate the actual problem from the proposed feature
Users often describe a solution rather than a need: ‘Add a big button’. Ask what the button is supposed to accomplish and whether that action is appropriate for the intended audience. Students should not assume that every request is complete or mutually consistent. A specification that says ‘accept all values’ and also ‘reject values outside 0 to 100’ requires clarification.
Gathering requirements may involve examples and non-examples. Ask for a normal input and output, an invalid input and the rule to apply at the boundary. The purpose is not an elaborate corporate interview. It is the simple discipline of ensuring that the problem being solved is the problem the user actually has.
4. Inputs and outputs need precise definitions
Input is the information the program receives; output is the information or action it produces. For each input, identify its type, valid range or format and whether missing values are permitted. For each output, state its type, structure and conditions. An output can be numerically correct yet still be incorrect for the specification if its formatting or associated label is wrong.
Suppose a fictional attendance program receives a class size and a number present. If the program calculates a percentage, a class size of zero needs handling. A result of 75 may mean 75 students, 75 per cent or 0.75 as a proportion, depending on the output format. Requirements must remove such ambiguity before tests can be written.
5. Design first at the level of decisions
A design describes how the system will transform its inputs into the required results. Use a flowchart, clear pseudocode or a decomposition of smaller tasks. Identify the decision points and repeated actions before writing detailed syntax. For a simple program, the design may take less than a page, but it should still expose the logical structure.
Consider a password-length checker for a fictional practice app. The design could read a string, calculate its length, compare the length with a stated rule and output an appropriate message. The design must also specify how empty strings are handled and whether the threshold is inclusive. Writing this down makes it easier to discover a mistaken condition than debugging a larger program after implementation.
6. Decomposition turns a large task into smaller parts
A program that reads a file, validates records, calculates a total and writes a summary can be divided into smaller steps. Each step has a purpose and a clear relationship to the next. Decomposition makes the system easier to reason about and lets students test one part before adding another.
A useful plan identifies which operations are independent and which depend on earlier results. You cannot calculate a correct average until you know which values were valid and included. Nor can you safely overwrite an output file before the required information is available. The sequence matters because data flows through the system.
7. Build a small correct version before adding complexity
Incremental development begins with a minimal solution that works for a small case. Then features are added one at a time. A student could first calculate the total of two fixed numbers, then accept user input, then validate the input, then extend to a list, and finally improve the output presentation.
Each change should preserve the behaviour that was already correct. A newly added feature that breaks an earlier case is a regression. The purpose of small steps is to make it easier to identify which change introduced an error. This principle is often more practical for learners than writing a hundred lines of code and hoping the complete program works immediately.
8. Explain the difference between syntax, run-time and logic errors
A syntax error breaks the language rules, such as a missing required colon after a Python if statement. A run-time error occurs while a program executes, such as attempting to divide by zero in a context where the exception is not handled. A logic error allows the program to run but produce an incorrect result.
The way to investigate each is different. Syntax errors often produce a diagnostic message before normal execution. Run-time errors can be associated with particular inputs or states. Logic errors require comparing actual behaviour against expected results, tracing variables and inspecting the decision process. Calling every bad output a ‘syntax problem’ prevents effective debugging.
9. Tests should come from requirements, not just from the code
An acceptance test checks whether the software meets an agreed behaviour. Suppose the rule says values from 0 to 100 inclusive are valid. Tests should include 0, 100 and valid interior values, as well as −1 and 101. Testing only 50 because it works is insufficient evidence.
The expected result must be determined independently from the program’s actual output. Otherwise a mistake can be copied from the code into the expected answer, allowing the program to appear correct. A good test table records purpose, input, expected result, actual result and whether the requirement is satisfied. This is a powerful habit even for a ten-line exercise.
10. Trace tables reveal how variables change
In a manual dry run, record the values of relevant variables as each line or loop iteration executes. The table should correspond to actual program behaviour, including the order of updates. For a running total, distinguish the value before adding an item from the value after adding it.
A student who writes the final answer without tracking intermediate values may overlook a variable that was reset inside a loop or a condition that skipped one item. Trace tables are especially useful when the program does not raise an exception but the output is wrong. They turn an invisible process into an inspectable sequence.
11. Debug from the first wrong observation
When a test fails, identify the first unexpected result and work backwards to the variable or condition that produced it. Use carefully placed print statements or a debugger when allowed. Changing several unrelated lines at once may make a bug disappear without revealing its cause and can introduce new failures.
For example, if an average is too low, inspect the total and the count separately. The total may omit the last item, the count may include an invalid item, or the division may be performed at the wrong moment. A clear hypothesis about the error guides the next test. Repeating random changes is slower and teaches less.
12. Refinement can improve correctness and usability
After a program meets basic requirements, improvements might make its messages clearer, reject invalid input safely, organise code into functions or simplify repeated logic. Refinement is not simply adding more features. It can mean removing unnecessary complexity that increases the risk of errors.
The best improvement addresses evidence. If a user misunderstands an output, improve the label. If a function repeats calculations inconsistently, consolidate it. If an invalid input crashes the program, implement the appropriate rejection behaviour. A refinement should have a reason and a test that demonstrates whether it solved the problem.
13. Iteration is a deliberate return to an earlier stage
The software-development process is often described in a sequence, but real learning is not always linear. A prototype can reveal that a requirement was ambiguous. A failed test can show that the design needs revision. User feedback can uncover an inaccessible workflow. Returning to requirements or design is not a failure of discipline; it is a rational response to new evidence.
A simple loop is: state the current requirement, build the smallest usable solution, test it, collect feedback, revise the requirement or design, then implement the next version. Keep a short change record. Without a record, iteration may become uncontrolled feature drift in which the project loses its original purpose.
14. Deployment means making the solution available for its intended use
Deployment is the step of placing the completed software into the environment where its intended users can run it. For a school exercise, this may mean delivering a correctly named Python file or spreadsheet in a required folder. In a larger application, deployment can involve servers, configurations, permissions and user access.
Writing code that runs on a developer’s own computer does not guarantee it will work elsewhere. Files may be missing, paths may differ or required versions may be unavailable. A sound deployment check asks whether the correct files are present, the environment is suitable and the expected tasks can be completed. Do not confuse publishing a screenshot with delivering a functioning program.
15. Verification is more than the final click
Before submission or deployment, run the system from a clean and known starting point using representative test data. Check the output files, not only the console message. If the task requires a saved report, confirm that the file can be reopened and that its contents match the specification.
If the environment is a Jupyter notebook, execution order matters: a cell may depend on a variable created earlier in a session. A fresh-kernel, top-to-bottom run can expose hidden dependencies, although the exact examination setup is determined by the school. An apparently successful previous run is not proof that the submitted artefact is reproducible.
16. Be careful with real data and permissions
Many learner programs involve names, scores or contact information. For teaching, use invented records unless school rules specifically authorise real data. Avoid hard-coding personal details into shared code or uploading sensitive files to public repositories. A test is not worth violating confidentiality.
Software design includes deciding whether information is needed, how it is protected and whether the output reveals more than users should see. A simple classroom attendance example need not carry real identifiers to illustrate a sorting or averaging algorithm. Synthetic data make the exercise safer and often easier to check.
17. Understand the K349 written and lab components
The official 2027 Computing K349 scheme gives Paper 1 a two-hour written examination worth 60 per cent of the overall marks and Paper 2 a two-hour-thirty-minute lab-based examination worth 40 per cent. The lab uses spreadsheet and Python/JupyterLab software for work from Modules 2 and 3, while Paper 1 assesses concepts across the modules.
This means learners need both explanatory skill and practical control. They should be able to state the stages of development, then apply the habits in code: careful input, correct outputs, incremental testing and reliable file saving. This article does not reproduce examination tasks or guarantee the specific format of any upcoming question.
18. A twelve-stage Requirement–Build–Test method
The following independent study routine combines syllabus outcomes into one reliable development process. It is useful for short exercises, and its stages can be revisited in a different order when testing reveals a new issue.
Stage 1 — Name the user and problem
State whose problem the software addresses and what successful use would look like. Avoid beginning with a favourite library or interface design.
Stage 2 — Write observable requirements
Specify valid input, output, limits and failure behaviour. Use clear conditions that can be tested rather than adjectives such as ‘fast’ or ‘good’ without measures.
Stage 3 — Collect example cases
Prepare ordinary, boundary and invalid examples before the full program exists. Determine expected outputs from the specification.
Stage 4 — Decompose the task
Break the work into input, validation, calculation, output and saving stages as needed. Identify necessary dependencies.
Stage 5 — Design the control flow
Select sequence, selection and iteration structures. Sketch decisions in pseudocode or flowchart form.
Stage 6 — Build the smallest working version
Implement enough behaviour to verify one complete path. Avoid adding a complex interface before the basic logic is correct.
Stage 7 — Test one feature at a time
Compare outputs with independently determined expectations after each meaningful code change. Preserve a record of regressions.
Stage 8 — Trace unexpected behaviour
Locate the earliest incorrect state using a dry run or diagnostic values. Distinguish the error type before changing code.
Stage 9 — Refine the design
Revisit an assumption when evidence shows a flaw. Simplify repeated logic and improve validation without changing intended behaviour accidentally.
Stage 10 — Retest old and new cases
Use a small regression suite to ensure a change has not broken previously correct outcomes. Include boundary conditions.
Stage 11 — Prepare the deliverable
Check the required files, names, location, environment and permitted dependencies. Make sure the output can be reopened or rerun as intended.
Stage 12 — Review and document
Write a short account of what the system does, the evidence for correctness and a known limitation. This is more credible than claiming that no defects can exist.
19. Twenty original software-engineering decision cases
Each fictional case offers a small example of a lifecycle decision. Before reading the explanation, identify which stage of development is missing or needs to be revisited. A student who can explain why a change is needed understands more than one who merely names the stage.
Engineering case 1 — A marks calculator has no accepted range
The learner coded an average but has no rule for scores below zero or above the maximum. Gather requirements and define valid inputs before adding tests.
Engineering case 2 — A receipt program rounds too early
Every item is rounded independently when the specification requires rounding the final sum. Revise the calculation design and test with values where the approaches differ.
Engineering case 3 — A student enters letters where a number is expected
The program raises an error. The requirement should specify what to do with invalid data, and the implementation needs an appropriate validation or handling path.
Engineering case 4 — A library due-date checker uses the wrong comparison
A return on the due date is incorrectly marked late. Check whether the rule says ‘later than’ rather than ‘on or later than’, then add a boundary test.
Engineering case 5 — A program prints an unnamed number
The calculation is correct, but the user cannot tell what the result represents. Refine the output requirement and label the value clearly.
Engineering case 6 — A feature works only with a fixed test record
Hard-coded example values can create the appearance of success. Test different valid inputs and verify that the algorithm actually uses the supplied values.
Engineering case 7 — A notebook works only after running cells out of order
The state from an earlier run may hide a missing initialization. Restart the notebook environment and run it top to bottom; then fix the dependency.
Engineering case 8 — An average is wrong after a list grows
The running total works for three items but not four. Inspect loop bounds and the count, and trace where the last item is handled.
Engineering case 9 — A function returns a result instead of printing it
A student expects visible output from a function that returns a value but is not printed by the caller. Distinguish return values from screen output and test the calling context.
Engineering case 10 — A software release is missing its input file
Code runs locally but cannot open the required file in the submitted environment. Deployment verification must include data files and appropriate relative paths where allowed.
Engineering case 11 — Two requirements conflict
A task asks the program to accept any text but also reject empty strings. Clarify which conditions actually apply before implementing arbitrary exceptions.
Engineering case 12 — A developer changes three variables at once
After the change, a failing test passes but nobody knows why. Revert to a known state when possible and make incremental, attributable changes.
Engineering case 13 — A user asks for a dashboard instead of a summary
The request may be a proposed interface rather than the underlying need. Ask which decisions the user must make and which output supports those decisions.
Engineering case 14 — The program works for 5 but not for 0
The zero case may expose division, range or logic problems. Add explicit boundary tests rather than assuming a successful typical value proves correctness.
Engineering case 15 — A student tests only the result they expect
One positive test does not establish correct rejection or behaviour at limits. Generate normal, error and boundary cases from the requirements.
Engineering case 16 — A program runs but uses an incorrect tax rate
Syntax and execution may both be correct. This is a problem with rules or requirements. Verify the stated fictional rate and the output calculation.
Engineering case 17 — A calculation function is duplicated
Two copies gradually diverge. A refinement may consolidate the shared logic, then regression tests should confirm that the change preserves required behaviour.
Engineering case 18 — An input prompt misleads users
The program expects an integer but asks for ‘enter amount’ with no unit or range. Clearer input instructions reduce avoidable invalid entries and improve usability.
Engineering case 19 — An app stores real names unnecessarily
The teaching task needs only anonymous record counts. Remove unnecessary personal identifiers and test the functionality with fictional data.
Engineering case 20 — A final submission has only a screenshot
The required outcome is a working program and specified files. Deployment includes delivering the functioning artefact, not merely evidence that a similar program once ran.
20. Mini-project practice: a fictional class-booking counter
Imagine a program that receives a positive room capacity and a requested group size. It should report whether the group fits and, if it does, how many seats remain. An initial specification might be: capacity must be an integer from 1 to 40, requested group size must be an integer from 1 to 40, and the program should reject invalid input rather than producing a nonsensical seating count.
A normal test could use capacity 20 and request 12, expecting ‘available, 8 seats remain’. A boundary test could use capacity 20 and request 20, expecting ‘available, 0 seats remain’. An error-condition test could use a request of 21, expecting a clearly labelled capacity rejection. Notice that valid numeric input does not always imply a feasible booking, so input validation and the business rule are distinct.
21. Practice questions for students and tutor prompts
Question one: list the development stages in the syllabus and explain why a later stage might require revisiting an earlier one. Question two: a program returns 100 for the average of [40, 60]. Name the likely kind of error and describe a useful trace. Question three: state two acceptance tests for an inclusive valid range of 1 to 10. Question four: why should expected output be derived independently of code?
Question five: distinguish coding, testing and deployment using one coherent scenario. Question six: explain why a file that ran in a developer’s notebook may not run after submission. A tutor can ask the learner to present a short acceptance-test table before reviewing source code; parents can ask the simple question, ‘How did you check that the program solves the right task?’ rather than focusing only on how much code was written.
22. Frequently asked questions
Software engineering is a way of making computing results more reliable and usable. These concise answers distinguish the development process from the specific programming syntax used to implement it.
Is software engineering just writing Python?
No. Coding is one stage. Requirements, design, testing, refinement and deployment help ensure that the code actually addresses a problem and can be used as intended.
Must the stages always happen in exactly one order?
No. The syllabus explicitly recognises that development may be iterative. Test results and feedback can lead back to requirements or design.
What makes a requirement testable?
A testable requirement states an observable condition, such as a permitted input range or expected output, rather than an undefined claim that the software should be ‘great’.
Why write expected results before running the program?
The expected result should represent the specification independently. Copying the program’s actual output as the expected answer can hide logic errors.
What is the difference between testing and debugging?
Testing checks behaviour against expectations; debugging investigates and corrects defects when behaviour is unexpected. The activities inform one another but are not identical.
What is a regression?
A regression occurs when a change breaks behaviour that previously worked. Retesting earlier cases after a modification helps detect regressions.
What is a deployment for a school assignment?
It may be placing the required source code, notebooks or output files into the correct submission environment so the intended program can be run or assessed. Follow the school’s instructions.
Can a program be correct if it never crashes?
No. A logic error or misunderstood requirement can produce incorrect results without a crash. Correct execution and correct behaviour are different properties.
Why is iterative development useful for beginners?
Small tested changes help reveal errors close to the time they are introduced and reduce the uncertainty created by building a large untested system.
Should students use real personal data for testing?
Normally no. Synthetic or invented records can exercise the program’s logic without creating unnecessary privacy and confidentiality risks. Follow school rules for any authorised real data.
Official 2027 K349 syllabus and related eduKateSG learning
The source is the 2027 SEC G3 Computing K349 syllabus, especially sections 2.1, 2.4, 2.5 and 2.6; the SEAB 2027 G3 syllabus directory provides the official current entry point. Continue with Reference 357 — Data Validation, Reference 342 — Manual Algorithms, Reference 360 — AI Classification, the MOE V3.0 library and the immutable Clementi teaching reference.
Reviewed 29 October 2026 in Singapore. All projects and test records are original fictional teaching illustrations, not actual SEC questions. A sound development process names the requirement, builds a testable solution, investigates unexpected behaviour, revises responsibly and verifies the deliverable.
MOE V3.0 reference navigation
Previous: Reference 360 — AI Nearest Neighbour · Reference library.