Unit 1: SE & the SDLC
Learning Objectives
- Define software engineering and explain how it differs from programming
- Identify and describe the main stages of the Software Development Life Cycle
- Distinguish functional from non-functional requirements and explain key quality attributes
- Analyse contributing factors in a software failure case study
Core Input
Read through each tab. Take notes on the key ideas before moving to the activities.
Software engineering is the disciplined application of engineering principles to the design, development, testing, and maintenance of software systems. It is not simply writing code — it involves managing complexity, working with stakeholders, and making principled decisions under constraints of time, budget, and knowledge.
The discipline is fundamentally socio-technical: it cannot be separated from the organisations, teams, and human contexts in which software is built and used. A system that is technically correct but fails to meet user needs, violates organisational workflows, or is unmaintainable by the team that inherited it has failed as an engineering artefact — regardless of whether it compiles and runs.
A software engineer must consider:
- Process — how the team will plan, coordinate, build, and deliver
- Stakeholders — everyone affected by or responsible for the system
- Constraints — time, budget, hardware, legal requirements, existing infrastructure
- Quality — the system must not only work, but be maintainable, secure, and reliable
The Software Development Life Cycle (SDLC) is a structured framework describing the phases a software system passes through — from initial concept to eventual retirement. All SDLC models, regardless of their approach, include some version of these core stages:
- Requirements — what should the system do, and for whom?
- Design — how will the system be structured? Architecture and detailed design are produced.
- Implementation — the design is translated into working code.
- Testing — does the system behave as specified? Defects are identified and resolved.
- Deployment — the system is released to its intended users and environment.
- Maintenance & Evolution — the system is updated, adapted, and extended over time.
Different development methodologies organise these stages differently — sequentially, iteratively, or in overlapping cycles. But the stages themselves are present in all approaches. The SDLC provides a shared vocabulary for discussing where a project is and what decisions need to be made.
Software quality is multi-dimensional. Engineers distinguish between two broad categories of requirement that together define what a system must achieve:
Functional requirements describe what the system must do — specific behaviours, features, and outputs. Example: "The system shall allow a patient to book an appointment with a GP online."
Non-functional requirements (NFRs) describe how well the system must perform its functions — qualities such as:
- Performance — response time, throughput, resource usage
- Security — protection of data and resistance to attack
- Reliability — consistent, correct behaviour under expected and unexpected conditions
- Maintainability — ease of modification, extension, and debugging
- Scalability — ability to handle growth in load, features, or team size
- Usability — how easily users can learn and operate the system effectively
NFRs are frequently underspecified or ignored early in projects — and this is a leading cause of late-stage failure. A system that meets all its functional requirements but collapses under load or is trivially vulnerable to attack has failed its quality obligations.
Key Concepts: SE as a Discipline
Expand each item. Think about your answer before reading the explanation.
Programming is one activity within software engineering — writing the code that implements a solution. Software engineering is the broader discipline encompassing requirements analysis, design, testing, deployment, and maintenance. It also involves working with teams, managing risk, and making decisions about trade-offs.
An analogy: programming is to software engineering what bricklaying is to architecture. Both are essential, but the architect is responsible for the overall system — its structure, its fit to purpose, and its integrity over time.
A socio-technical system is one in which technical components (hardware, software, infrastructure) are deeply intertwined with social components (people, organisations, processes, culture). Software does not operate in isolation — it is always embedded in a human context.
This matters because failures often originate not in the code itself but in the interaction between the technical system and the organisation using it. A poorly designed interface that causes clinical staff to bypass a safety system, or a deployment process that prevents timely security patches, are socio-technical failures.
Effective software engineers must understand the human and organisational context of their systems, not only the technical architecture.
Real software is built under constraints that limit design choices and force trade-offs:
- Technical constraints — existing infrastructure, required platforms, legacy integration, performance limits
- Organisational constraints — team size, available skills, budget, delivery timescales
- Legal and regulatory constraints — data protection law (e.g. GDPR), industry standards, accessibility requirements
- Interoperability constraints — the system must work with other existing systems
Identifying constraints early is critical. A design that ignores them will fail in practice, even if it is technically elegant. In this course, constraints are treated as first-class engineering inputs, not afterthoughts.
Software engineering has a long record of instructive failures. Prominent examples include:
- Therac-25 (1985–87) — a radiation therapy machine whose software flaw caused fatal overdoses. Root causes included removed hardware safety interlocks, race conditions in concurrent code, and inadequate testing of the integrated system.
- NHS National Programme for IT (NPfIT, 2003–2011) — a £10 billion project eventually abandoned. Failures included insufficient requirements elicitation, underestimation of complexity, and poor stakeholder engagement.
- Knight Capital Group (2012) — a trading algorithm error caused $440 million in losses in 45 minutes. Root cause: a deployment process that failed to update all production servers consistently.
These cases recur throughout this course. They illustrate how decisions at every SDLC stage — requirements, design, testing, deployment — can have catastrophic downstream consequences.
Key Concepts: SDLC and Quality
Continue with the concepts below.
Each SDLC stage produces a set of artefacts used by the next stage:
- Requirements → requirements specification, user stories, use cases
- Design → architecture documents, UML diagrams, data models
- Implementation → source code, unit tests, build artefacts
- Testing → test reports, defect logs, quality metrics
- Deployment → running system, release notes, deployment documentation
- Maintenance & Evolution → updated code, new requirements, change logs
A defect in an early artefact — such as an ambiguous requirement — propagates forward and becomes increasingly expensive to correct. This is the core argument for investing in requirements quality and design quality before writing code.
Functional requirements define specific behaviours — what the system shall do in response to inputs or events. They can be verified by asking: "Does the system do this or not?" Either it does or it doesn't.
Non-functional requirements define qualities — how well the system performs its functions. They are often expressed as measurable constraints: "The system shall respond to a booking request within 2 seconds for 95% of requests under peak load."
The critical difference: a functional requirement can usually be implemented in a single feature. An NFR like performance or security affects the entire architecture. Decisions made early in design — choice of database, caching strategy, authentication mechanism — determine whether NFRs can be met at all.
A stakeholder is anyone with an interest in the system — whether they use it, fund it, regulate it, or are affected by it. Common stakeholders include:
- End users — want simplicity, speed, and reliability
- Clients / sponsors — want low cost and fast delivery
- Developers — want clear requirements and sufficient time
- Operations / maintenance teams — want maintainability and good documentation
- Regulators — want auditability, compliance, and security
These interests frequently conflict. A regulator's requirement for detailed audit logging may increase system complexity and reduce performance. A client's demand for the lowest possible cost may push against the testing budget a developer knows is necessary. Negotiating these tensions is a core professional skill.
Watch
Video coming soon
Check Your Understanding
Select the best answer for each question.
Which of the following is a non-functional requirement?
Which SDLC stage is primarily concerned with translating requirements into a system structure?
AI tools are now present across every stage of the SDLC — from drafting requirements to generating code to monitoring production systems. To reason clearly about their impact, it helps to think in terms of four aspects of AI in software engineering:
- Amplifier — a role in which AI speeds up tasks the engineer already knows how to do (generating boilerplate, summarising documents, drafting test cases).
- Assistant — a role in which AI suggests options; the engineer evaluates, decides, and takes responsibility.
- Risk — AI can hallucinate plausible but incorrect outputs, produce insecure code, or encourage over-reliance that erodes the engineer's own understanding.
- Subject — systems that incorporate AI components must themselves be engineered, tested, and governed — they introduce new quality, security, and ethical obligations.
This framework recurs throughout the course. The constant across all four aspects is accountability: AI is accountable to no one. Whatever AI generates, the engineer signs off on it and bears professional responsibility for it.
Activities
Individual task
Choose a digital system you interact with regularly — for example, a banking app, a university learning management system, or a food delivery platform.
Write a short structured description (150–200 words) covering:
- The purpose of the system — what problem does it solve?
- At least three stakeholders and their different priorities
- Two functional requirements and two non-functional requirements
- One constraint that shapes the system's design (technical, legal, or organisational)
Pair task
Exchange your descriptions with a partner and discuss:
- Did you identify the same stakeholders? Are there any your partner missed — or vice versa?
- Are your non-functional requirements actually measurable? If not, how could they be made more precise?
- Do your constraints conflict with any of your stated requirements? How might the conflict be resolved?
Note: there is no single correct answer. The goal is to see how two engineers can read the same system differently — and to understand why precision matters before any design work begins.
Group task — establishing the course case study
As a group, agree on a shared system to use as your case study throughout this course. You will return to this system in every subsequent unit — building requirements, designing architecture, defining tests, and finally evaluating the engineering decisions you make.
Suggested system: a university hospital appointment booking system — patients book appointments online, GPs make referrals, and consultants manage their own schedules. It involves multiple user roles, security and privacy obligations (GDPR, clinical data), performance constraints (availability), and interesting architectural trade-offs.
Your group should agree on and document:
- A one-sentence statement of the system's purpose
- At least four distinct user roles (e.g. patient, GP, consultant, administrator)
- Three non-functional requirements with measurable acceptance criteria
- Two constraints that will shape the architecture
- Two things that are explicitly outside the system boundary
Keep this definition — you will refer back to it in every subsequent unit.
Review
- Requirements — what the system must do; produces specifications, user stories, use cases
- Design — how the system will be structured; produces architecture documents, UML diagrams
- Implementation — translating design into code; produces source code and unit tests
- Testing — verifying behaviour; produces test reports and defect logs
- Deployment — releasing to users; produces running system and release documentation
- Maintenance & Evolution — ongoing change; produces updated code and new requirements
- Amplifier — speeds up tasks the engineer already understands
- Assistant — suggests options; the engineer decides and takes responsibility
- Risk — hallucinations, insecure outputs, and over-reliance erode engineering judgment
- Subject — AI-incorporating systems require their own engineering, testing, and governance
The constant: accountability cannot be delegated to AI. The engineer signs off.
Proceed to Unit 2: Methodologies when ready.