Example Sheet 1: Mindset, Requirements & Process — Worked Answers
Example Sheet questions are not past Tripos questions but are excellent practice in the same style. Answers below are structured to hit the likely marking points.
Q1. The Complexity of Scale
(a) Why Software Engineering, not just Programming, for a national health-record system?
The health system involves a large team (communication overhead, Brooks’s Law), a huge, long-lived codebase (maintainability over decades, 80/20 rule), and life-or-death safety stakes (cf. Therac-25, a medical device that killed patients due to a race condition). Success requires process, testing, traceability, and professional accountability — the absence of any of which could directly cause patient harm. The To-Do app is solo, small, short-lived, and low-stakes: “does it work today?” suffices.
(b) Three emergent behaviours from connecting previously isolated hospital databases:
- Positive: cross-department analytics emerge — combining cardiology records with pharmacy data reveals that patients on Drug X have better outcomes, a pattern no single department’s database could show.
- Negative: a race condition between two independently-correct modules — the pharmacy module dispenses a medication, and simultaneously the allergy module revokes it — produces an unsafe combined state (cf. Therac-25).
- Negative: systemic overload — each component behaves reasonably in isolation, but together they exceed capacity (cf. London Ambulance Service).
None of these are possible in a solo app with one component and one user.
(c) Discrete state and risk — why is a nationwide health-record system qualitatively riskier than a physical hospital building?
A physical hospital building degrades continuously and visibly (cracks, wear, rust) and can be periodically inspected. Software state is discrete: a single flipped bit or a wrong branch in a conditional can instantly flip the system from “perfectly safe” to “catastrophic failure” with zero warning. Exhaustive state-space testing is mathematically impossible for a system this complex. The risk profile is qualitatively different, not just quantitatively larger.
Q2. Requirements Engineering: The Autonomous Delivery Drone
(a) Critique the requirement “ultra-fast and safe”:
It is not testable or measurable: what is “fast” — 10 km/h or 100 km/h? Under what wind conditions? What is “safe” — zero incidents ever, or a specific failure rate per thousand flights? It provides no contractual boundary for acceptance. It is ambiguous and will be interpreted differently by different engineers, forcing unconscious (and likely wrong) assumptions.
(b) Three testable NFRs:
- Performance: “95% of deliveries within a 3 km radius shall complete in under 15 minutes, measured over a rolling 30-day window.”
- Safety: “The drone shall maintain a minimum 5-metre separation from any detected person or building, with an automatic abort-and-land manoeuvre if separation drops below 3 metres.”
- Reliability: “The drone shall complete 99.9% of flights without a critical navigation fault, measured over a rolling 30-day window.”
(c) Trade-off between speed and safety — justify the balance to a stakeholder:
Faster delivery may require riskier flight paths (lower altitude, higher speed in proximity to obstacles) or lighter batteries (reducing the weight budget for redundant sensors). A quantified trade-off frames the discussion: “Increasing minimum separation from 5 m to 8 m would reduce the estimated incident rate by X% but increase average delivery time by Y%. At 8 m, we project Z incidents per year; at 5 m, W incidents per year. Which residual risk level is acceptable given our liability exposure and insurance costs?” This grounds the negotiation in measurable NFR fit criteria, not opinion.
Q3. Brooks’s Law & Project Management
(a) Adding 5 developers to an already-late team of 5 — what is the immediate effect?
Progress will likely worsen in the short term, per Brooks’s Law. The new developers require ramp-up time and mentoring from the existing team (training overhead pulls senior engineers off feature delivery). Communication paths roughly double: , increasing coordination overhead. “Adding manpower to a late software project makes it later.”
(b) Two hidden costs:
- Onboarding cost: existing developers lose productive time mentoring and answering questions instead of coding.
- Integration/communication cost: more people means more merge conflicts, more meetings, more duplicated or conflicting work on an already partially-built, interdependent codebase.
(c) Alternative strategy:
Descope the project (negotiate a reduced feature set by the deadline, per MoSCoW “Won’t have”); extend the deadline; or bring in a very small number (1–2) of senior engineers already familiar with similar systems — minimising onboarding cost while adding genuine capacity.
Q4. Technical Debt & The Legacy Trap
(a) What is technical debt? Is it always bad?
Technical debt is the trade-off of writing quick, messy code to meet a deadline (the “principal”) versus the extra effort required to add features or fix bugs in the messy codebase (the “interest”). Not always bad: deliberate/prudent debt — a conscious, informed strategic choice (e.g. hardcoding a database connection to hit Friday’s launch, with a ticket to refactor next sprint) — can be a valid business decision, provided it is tracked and repaid.
(b) Why a simple UI change takes 4 weeks in a debt-ridden legacy system:
The tangled, tightly-coupled code means every change requires understanding and safely modifying deeply interwoven logic. A “simple button” might require navigating five layers of undocumented coupling, each of which could silently break a seemingly unrelated feature. The interest payment on the original shortcut consumes developer time.
(c) Strategy to address the debt:
Refactor incrementally alongside feature work — do not attempt a Big Bang rewrite (cf. Netscape, 3 years with zero features shipped). Apply the Strangler Fig Pattern: extract and clean one module at a time behind a facade, while continuing to ship features. Write characterisation tests first, to lock in current behaviour before restructuring code with no existing test suite.
Q5. Process Selection & The Cost of Change
(a) Process choice:
- (A) Flight control software → Waterfall (or heavily gated Spiral). Requirements are stable and well-understood (physics of flight); the cost of a late-discovered defect is catastrophic (loss of life, cf. 737 MAX); extensive upfront verification and certification is mandated by aviation regulators (DO-178C).
- (B) Lecture-notes sharing app → Agile / Spiral. Requirements are unstable and best discovered by shipping to real students and iterating; the cost of a bug is low (inconvenience at most); there is no regulatory requirement for upfront certification.
(b) Cost of Change curve:
For the jet, the curve rises steeply (Boehm’s curve: in design → in production) because a defect found after certification or deployment may require re-certification, physical recall, or grounding a fleet — astronomically expensive. For the mobile app, the curve stays relatively flat: a bug found in production can be patched and redeployed within hours via CI/CD, at low marginal cost.
(c) How a 2-week Sprint closes the Translation Gap:
A 2-week Sprint produces a working Increment shown to real students every fortnight, directly closing the gap between the vague Why (students want to share notes easily) and the precise What being built. Feedback from each Sprint Review continuously re-calibrates the backlog, rather than betting everything on one upfront specification (as in Waterfall) that risks the Translation Gap widening unnoticed for years.
Q6. Requirements Elicitation: The Hospital Ward
(a) Why ethnography might reject the PIN requirement:
An interview captures what the Head of Nursing believes should happen. Direct observation on the ward would likely reveal that entering a 10-digit PIN for every single vitals entry is impractical in a fast-paced, hands-full clinical environment. Nurses would develop dangerous workarounds — writing PINs on stickers, sharing logged-in devices — exactly the invisible-workaround problem seen with the nurse’s sticky note. Observation surfaces the real usability constraint that an interview would miss.
(b) User Requirement vs System Specification:
A User Requirement is a high-level, business-facing statement of need in the client’s language: “nurses must be able to record vitals quickly and securely.” A System Specification is the precise, technical, testable elaboration of how the system will satisfy it: “the system shall accept NFC badge-tap authentication within 1 second, and fall back to a 4-digit PIN authenticating within 2 seconds.”
(c) FR/NFR conflict — security vs emergency response:
A security NFR (data privacy, requiring strong authentication per entry) conflicts with a usability NFR for emergency response time (authentication delay could cost seconds in a life-threatening situation). This is the classic Security-vs-Usability NFR trade-off. Resolution options: badge-tap authentication (fast, secure), or a time-limited “emergency override” mode with full audit logging — balancing both concerns rather than sacrificing either.
Q7. Scrum Ceremonies & Failure Modes
(a) Violated Scrum principles:
- A 2-hour Daily Standup violates the time-boxed, 15-minute synchronisation purpose of the Daily Scrum. It has become a status meeting, not a quick sync.
- “No working software at Sprint end” violates the requirement that a Sprint produce a Done, potentially releasable Increment — violating the Transparency pillar (the Sprint Review has nothing genuine to inspect).
(b) How the Sprint Retrospective could fix this:
The Retrospective’s purpose is continuous process improvement: what went well, what went wrong, what should change? The team could agree a concrete action — “Daily Scrums are capped at 15 minutes; detailed technical discussion moves to a separate follow-up meeting with only the people involved” — and review whether it worked at the next Retrospective.
(c) Scrum Master vs traditional Project Manager:
The Scrum Master is a servant-leader who facilitates events and removes blockers but does not assign tasks or dictate technical decisions. Here, they would coach the team to self-organise a fix for the standup problem — not personally mandate a solution. A traditional PM would more likely command a fix top-down and might also be evaluated on the same deliverables, creating less incentive to flag the dysfunction transparently.
Q8. The Agile Manifesto in Conflict
(a) Conflicting value:
“Customer collaboration over contract negotiation” (and “Responding to change over following a plan”) directly conflicts with a 500-page fixed-price, fully-specified contract — which is the Waterfall/legal mindset of freezing requirements upfront.
(b) Risk discussion:
Following the fixed contract risks delivering software that no longer matches the government’s real needs 2 years later — business and political requirements evolve; the Translation Gap widens. Responding to change risks scope creep, unpredictable cost, and difficulty enforcing accountability without a fixed contractual baseline.
(c) How prototyping might satisfy both:
Use Spiral-model-style prototyping within an overall fixed-price framework: contract for a series of fixed, short, prototype-validated phases with formal sign-off gates (satisfying legal certainty), while using each prototype and stakeholder demo to adapt the next phase’s detailed scope (satisfying Agile responsiveness).