Systematic Software Development

Systematic software development breaks the process of building a computer system into five distinct phases. Each phase informs the next, and modern agile approaches iterate through the cycle repeatedly rather than completing it once.

Phase	Core question
Analysis	What does the system need to do?
Design	How will the system do it?
Implementation	Build it
Testing	Does it work correctly?
Evaluation	Does it meet the requirements well?

The phases are not always strictly sequential. Agile and iterative approaches cycle through design → implementation → testing repeatedly, delivering working software in increments and refining requirements as understanding grows.

The analysis phase defines the problem and establishes what the system must do.

Activities:

• Define the problem — clarify the situation and identify what a computer system could solve
• Establish requirements — interview or observe the intended users; document what the system must do (functional requirements) and how it must perform (non-functional requirements: speed, security, usability)
• Create a data model — identify the entities, attributes, and relationships the system will manage (feeds directly into design of data structures and databases)
• Prototyping — a prototype (partial, working model) can be shown to users early to check that requirements have been understood correctly

Agile context: in agile development, requirements are not fixed at the start. The analysis phase is revisited at the start of each sprint as understanding deepens and user feedback arrives.

A thorough analysis prevents the most expensive errors — those discovered only after the system has been built.

The design phase decides how the system will work before any code is written.

What must be designed:

Design area	Purpose
Data structures	Decide how data will be organised in memory (arrays, stacks, queues, hash tables, trees)
Algorithms	Specify the logic for each task — search, sort, calculate — before implementing
Modular structure	Break the system into subroutines/modules; define interfaces between them
User interface	Wireframes or mock-ups showing layout, inputs, and navigation

Why design before implementing?

Discovering a structural flaw at the design stage costs a diagram. Discovering the same flaw in 5,000 lines of code costs a rewrite. Design separates the "what" from the "how" at a stage where changes are cheap.

Iterative/agile design: design is revisited each iteration. The design for the next increment is done just before implementation begins, not months in advance.

The implementation phase translates the design into working code.

Key principles:

• Implement models and algorithms as code — each algorithm designed in the previous phase is coded, each data structure is declared
• Iterative process — code is written, tested, and refined in small cycles; errors found early are fixed before they propagate
• Solve the critical path first — the critical path consists of the features that all other features depend on (e.g. the database connection, authentication, core data model). Implementing these first ensures that blocks are identified early and that dependent work can proceed

Good implementation practices:

• Use meaningful variable and function names
• Keep functions small and single-purpose (supports maintainability)
• Handle edge cases identified during design
• Write code that is readable by a future developer, not just functional today

Implementation without design produces code that solves the wrong problem efficiently.

The testing phase verifies that the system works correctly across a wide range of inputs.

Test data categories

Category	Definition	Example (age input, valid 0–120)
Normal	Typical valid values the system should accept and process correctly	25, 40, 67
Boundary	Values at the extreme edges of the valid range (and just beyond)	0, 1, 119, 120, 121, −1
Erroneous	Invalid data the system should detect and reject	"abc", −50, 999, blank

Boundary testing is critical because off-by-one errors are among the most common bugs. Testing 0 and 120 (the limits) as well as 1 and 119 (just inside) and −1 and 121 (just outside) catches errors that typical test data misses.

Acceptance testing

Acceptance testing is conducted by the intended users (not the developers) to verify that the finished system meets the original specification. It tests whether the system does what was agreed at the analysis stage, from the user's perspective.

Acceptance testing is the final quality gate before a system is deployed.

The evaluation phase assesses how well the completed system meets its goals. It is not simply "does it work?" — it measures quality across multiple dimensions.

Evaluation criteria:

Criterion	What is assessed
Functionality	Does the system do everything the specification required? Are all features present and correct?
Efficiency	Does the system use computational resources (time, memory) appropriately? Does it respond quickly enough for the intended use case?
Usability	Can intended users operate the system without excessive training? Is the interface clear, consistent, and accessible?
Maintainability	How easily can the system be modified to fix bugs or add features? Is the code well-structured and documented?

Evaluation findings feed back into the development cycle. A system rated poorly on usability returns to the design phase for UI revisions. A system found inefficient returns to implementation for algorithmic improvement.

1. Describing boundary data as "just outside the valid range"

Boundary data includes values at both edges and just beyond each edge. For an input range 1–100: boundary values are 0, 1, 100, and 101. Testing only the valid extremes (1 and 100) misses the just-outside values, which often reveal off-by-one errors in conditional logic.

2. Confusing acceptance testing with developer testing

Acceptance testing is done by the intended users, not the developers, to check the system meets the specification. Developer testing (unit testing, integration testing) checks that the code works. Acceptance testing checks that the right system was built.

3. Omitting agile/prototyping from the analysis phase

The AQA spec explicitly lists prototyping and the agile approach as part of analysis. Answers describing analysis as purely "gathering requirements" without mentioning iterative/prototyping approaches are incomplete.

4. Treating evaluation as the same as testing

Testing checks correctness (does it produce the right output?). Evaluation judges quality across multiple criteria — functionality, efficiency, usability, maintainability — including aspects that have no pass/fail answer. A system can pass all tests and still be rated poor on usability or maintainability.