BTEC HND Computing Unit 7 Software Development Lifecycles Answer Guide

BTEC HND Computing Unit 7 Software Development Lifecycles Answer Guide
08 Oct, 2026 /

Author : Christopher Anderson

This BTEC HND in Computing and Software Development answer guide covers Unit 7 Software Development Lifecycles (K/618/7408), a Level 4 specialist unit in the Pearson BTEC Higher Nationals in Computing (RQF) and a key unit on the software development pathway. It explains all seven Pass, six Merit and four Distinction criteria, gives a structure for each learning outcome, and includes model paragraphs and a worked feasibility and state machine example.

What the Unit 7 Software Development Lifecycles assignment asks you to do

Unit 7 briefs usually cast you as a junior developer or analyst at a software company that has been asked to build a system for a client, such as a booking platform or an online learning system. Typical evidence includes:

  • a report or presentation describing sequential and iterative lifecycle models and how each manages risk;
  • a feasibility report section explaining its purpose, components and how technical solutions are compared;
  • a software investigation for the client: requirements gathering, analysis models and supporting documentation;
  • a discussion of behavioural design techniques such as state machines, with examples.

Learning outcomes for Unit 7

Learning outcome What it covers
LO1 Describe different software development lifecycles Waterfall, V-model, Spiral, Agile (Scrum), RAD, prototyping; risk management in each
LO2 Explain the importance of a feasibility study Purpose and structure of a feasibility report; technical, economic, legal, operational and schedule feasibility
LO3 Undertake a software development lifecycle Investigation of a business need, requirements, analysis tools (use case, DFD, ERD), traceability, software quality
LO4 Discuss the suitability of software behavioural design techniques Flowcharts, pseudocode, state transition diagrams, finite state machines, extended FSMs, data-driven software

Pass, Merit and Distinction criteria explained

Criterion What it asks How to evidence it
P1 Describe two iterative and two sequential software lifecycle models For example, Spiral and Scrum (iterative), Waterfall and V-model (sequential), with diagrams
P2 Explain how risk is managed in software lifecycle models Risk points in each model: reviews, prototypes, sprints, the Spiral risk-analysis phase
M1 Discuss, using an example, why a particular lifecycle model is selected for a development environment A named project type and the reasons a model fits it
D1 Assess the merits of applying the Waterfall lifecycle model to a large software development project Balanced judgement for a large project
P3 Explain the purpose of a feasibility report Why organisations commission one before committing budget
P4 Describe how technical solutions can be compared Criteria, weighted scoring, prototypes, benchmarks
M2 Discuss the components of a feasibility report Introduction, scope, current system, requirements, alternatives, costs and benefits, recommendation
D2 Assess the impact of different feasibility criteria on a software investigation How technical, economic, legal, operational and schedule criteria change the outcome
P5 Undertake a software investigation to meet a business need Interviews, questionnaires, observation, document review with the client scenario
P6 Use appropriate software analysis tools and techniques to carry out an investigation and create supporting documentation Use case diagram, DFD, ERD, requirements specification
M3 Analyse how software requirements can be traced throughout the software lifecycle A traceability matrix from requirement to design, code and test
M4 Discuss two approaches to improving software quality For example, code reviews, test-driven development, static analysis, ISO/IEC 25010 quality attributes
D3 Evaluate the process of undertaking a systems investigation regarding its effectiveness in improving software quality Reflection on what your investigation did and did not achieve
P7 Discuss, using examples, the suitability of software behavioural design techniques Flowchart, pseudocode, state diagram, each with an example and suitability
M5 Analyse a range of software behavioural tools and techniques Comparison of strengths and limits
M6 Differentiate between a finite state machine (FSM) and an extended FSM, providing an application for both Definitions, diagrams and one application each
D4 Present justifications of how data-driven software can improve the reliability and effectiveness of software Configuration and rules held as data, not code, with examples

How to answer LO1: lifecycle models and risk

For each model, give a diagram, the phases, when it suits and how it handles risk. Then select a model for a realistic environment (M1) and assess Waterfall for a large project (D1).

Example paragraph: The Spiral model manages risk explicitly. Each loop begins by setting objectives, then identifies and resolves the biggest risks, often by building a prototype, before development and planning the next loop. For the online learning platform, the riskiest element is video streaming under heavy load, so the first loop would prototype streaming with a test group of users. If the prototype fails, the team has lost weeks rather than months, which is the main advantage over a sequential model where problems may only appear at system testing.

How to answer LO2: the feasibility study

Explain that a feasibility report helps decision-makers decide whether a project should go ahead and which option to choose. Describe its components, then show how technical solutions are compared, for example by weighted scoring. For D2, assess how each feasibility criterion can change the decision: a technically ideal option may fail on cost, or a cheap option may fail on legal grounds such as data protection under UK GDPR.

How to answer LO3: undertaking the investigation

P5 and P6 need real evidence: interview notes or questionnaire results, a requirements list (functional and non-functional), a use case diagram, a context-level and level-1 DFD and an ERD. Then build a traceability matrix for M3 and discuss two quality approaches for M4.

Example paragraph: Requirement FR04, “learners can resume a video from where they stopped”, is traced to the use case Watch Lesson, the Progress entity in the ERD, the saveProgress() function in the design and test cases T12 and T13. If the client later changes FR04, the matrix shows exactly which design elements and tests must be updated, which reduces the risk of a requirement being lost between analysis and testing.

How to answer LO4: behavioural design techniques

Discuss flowcharts, pseudocode and state transition diagrams with examples (P7), then analyse them (M5). For M6, a finite state machine has a fixed set of states and transitions triggered by inputs. An extended FSM adds variables and guard conditions, so it can model behaviour such as counting failed attempts without adding a separate state for each count. For D4, justify data-driven design: when business rules, prices or menus are stored as data, they can be changed and tested without editing code, which reduces errors and deployment risk.

Worked example: comparing options and modelling a login

Part 1: weighted scoring (P4). Two technical solutions for the client are compared on weighted criteria (weights total 1.0, scores out of 10).

Criterion Weight Option A: custom web app Option B: hosted platform
Fit to requirements 0.4 9 → 3.6 6 → 2.4
Cost 0.3 5 → 1.5 8 → 2.4
Time to deliver 0.2 5 → 1.0 9 → 1.8
Maintainability 0.1 7 → 0.7 6 → 0.6
Total 1.0 6.8 7.2

Economic feasibility: Option A costs £48,000 to develop and saves £20,000 a year in licences and admin time, with £4,000 a year running costs. Net annual benefit = £20,000 − £4,000 = £16,000, so payback = £48,000 ÷ £16,000 = 3 years. Option B scores higher overall, but if the client values a close fit to requirements, increasing that weight to 0.5 (and cost to 0.2) changes the totals to A 7.2 and B 7.0. This is exactly the point D2 asks you to assess. Figures are illustrative.

Part 2: extended FSM (M6). States: LoggedOut, LoggedIn, Locked. Variable: failedAttempts. From LoggedOut, a correct password moves to LoggedIn and resets failedAttempts to 0; a wrong password adds 1 and stays in LoggedOut while failedAttempts < 3; when failedAttempts reaches 3, the machine moves to Locked. A plain FSM would need separate states for one, two and three failures.

Common mistakes that cost marks

  • Describing models with no diagrams and no discussion of risk for P2.
  • Choosing iterative models that are really the same idea, or mislabelling Agile as one fixed model.
  • Writing about feasibility in general instead of for the client in the brief.
  • P5 and P6 without real investigation evidence or with diagrams that do not match each other.
  • A traceability matrix that stops at design and never reaches testing.
  • Confusing a state transition diagram with a flowchart.

How to move from Merit to Distinction

Each D criterion needs judgement. D1: weigh Waterfall’s strengths (clear documentation, fixed scope, contract control) against its weaknesses (late testing, costly change) for a large project and conclude. D2: show how changing criteria changes the recommendation. D3: evaluate your own investigation honestly, including gaps in requirements. D4: justify data-driven design with concrete examples and limits.

FAQs

Is Unit 7 Software Development Lifecycles Level 4 or Level 5?

It is a Level 4 unit, usually taken in the HNC year, and it counts towards the HND in Computing.

Which lifecycle models should I choose?

Waterfall and V-model are clear sequential choices; Spiral and Scrum are clear iterative choices.

What tools can I use for diagrams?

Any diagramming tool that produces clear UML or DFD notation, such as draw.io or Lucidchart.

How many requirements should my investigation include?

There is no set number, but ten to fifteen clear functional requirements plus a few non-functional ones (performance, security, accessibility) usually give enough material for diagrams and a traceability matrix.

Do I need to write code for this unit?

Usually not. The focus is lifecycle, feasibility, analysis and design, although some briefs ask for a small prototype.

For related HN Computing help, see our guides to Unit 4 Database Design and Development and Unit 30 Application Development. If you want feedback on your feasibility report or diagrams, get expert help with your BTEC assignment.

Get AI-Free Assignment Help Instantly

Facing Issues with Assignments? Talk to Our Experts Now! Download Our App Now!

WhatsApp Icon