Unit 30 Application Development BTEC Level 5 Assignment Answer Guide

Unit 30 Application Development BTEC Level 5 Assignment Answer Guide
08 Oct, 2026 /

Author : Christopher Anderson

This Unit 30 Application Development BTEC Level 5 assignment guide is for HND Computing students who need to design, build and evaluate a business application. In the current Pearson BTEC Higher Nationals in Computing (RQF) the unit is numbered Unit 22: Application Development (Y/618/7436, Level 5, 15 credits), and this guide follows that specification, with each criterion explained, model extracts and a worked requirements-to-testing example.

Assignment brief: Unit 22 Application Development (Y/618/7436) assignment brief — read the full task first, then use this guide to plan and check your answer.

What the Application Development assignment asks you to do

The unit simulates the work of a commercial developer. You take a business problem, turn it into requirements and a design, choose tools and a methodology, build a working application and then judge how well it meets the original requirements. Most centres set one large project split into two submissions:

  • Part 1 (LO1 and LO2): a software design document for a client problem – for example, a booking system for a small gym, a stock tracker for a café or an appointments app for a clinic – plus research into the tools and methodologies you could use.
  • Part 2 (LO3 and LO4): a peer review of the design, the working application with technical and user documentation, a record of testing, and an evaluation of the finished product against the design.

Pick a problem that is small enough to finish but rich enough to need a database, validation and more than one type of user. A typical good scope is five to eight core functions.

Learning outcomes for Unit 22 (formerly Unit 30) Application Development

Learning outcome What it covers
LO1: Produce a software design document for a business-related problem based on requirements Problem definition, user and system requirements, design artefacts (use case, class, sequence and entity relationship diagrams, wireframes) and risk.
LO2: Research design and development tools and methodologies for the creation of a business application IDEs, languages, frameworks, version control, testing tools; methodologies such as Waterfall, Scrum, Kanban and rapid application development.
LO3: Plan and produce a functional business application with support documentation Peer review of the design, implementation, algorithms, code management, testing and refinement, user and technical documentation.
LO4: Evaluate the performance of a business application against its software design document and initial requirements Performance review against requirements, feedback, reliability and effectiveness, and future improvements.

Pass, Merit and Distinction criteria explained

Criterion What it asks How to evidence it
P1 (LO1) Produce a well-defined problem definition statement, supported by a set of user and system requirements for a business problem. A one-page problem statement and numbered functional and non-functional requirements.
P2 (LO1) Review areas of risk related to the successful development of a proposed application. A risk register with likelihood, impact and mitigation.
M1 (LO1) Analyse a business-related problem using appropriate methods to produce a well-structured software design document. Use case, class and data diagrams, wireframes and traceability back to requirements.
P3 (LO2) Research the use of software development tools and techniques for the development of a proposed application. Comparison of languages, frameworks, IDEs, databases and version control.
M2 (LO2) Justify the software development tools and development methodology selected. Reasons tied to your requirements, timescale, skills and risks.
D1 (LO1, LO2) Evaluate the solution and the preferred methodology by comparing the tools and techniques researched. A balanced judgement with alternatives considered and rejected for stated reasons.
P4 (LO3) Review designs with others, record the feedback and act on it to refine the solution. Peer review notes or survey, a feedback log and the design changes made.
P5 (LO3) Develop a functional application with supporting documentation. Working code, screenshots, a user guide and technical documentation.
M3, M4 (LO3) Show how review feedback and your chosen tools, methodology, algorithms and code management shaped the build, and document testing and refinement. Sprint logs or iteration records, commit history, annotated code and a test log with fixes.
P6 (LO4) Review the performance of the application against the identified requirements. A requirements traceability table marked met, partly met or not met, with evidence.
M5 (LO4) Critically review the design, development and testing, including how feedback improved the solution. Honest discussion of what worked, what did not and why.
D2 (LO3, LO4) Justify recommended improvements based on feedback and opportunities for future development. Prioritised improvement list with a rationale for each.

The LO3 and LO4 criteria are worded slightly differently on some centre briefs, so always copy the exact wording from your own brief into your report headings.

How to answer LO1: the software design document

  1. Write a problem statement: who the client is, what is going wrong now and what a good outcome looks like.
  2. List requirements with IDs (FR1, FR2… for functional; NFR1… for non-functional such as security, performance and accessibility).
  3. Produce design artefacts: a use case diagram, a class or entity relationship diagram, at least two sequence or activity diagrams for key processes, and wireframes.
  4. Add a risk review covering scope, skills, data protection, technical and time risks.

Example paragraph: The gym currently takes class bookings by phone and on a paper sheet at reception. Classes are regularly overbooked, members cannot see availability outside opening hours and staff spend up to an hour a day handling calls. The proposed web application will let members view the timetable, book and cancel places, and join a waiting list when a class is full. Staff will manage classes and view attendance reports. Because the system stores members’ names, email addresses and booking history, it must comply with the UK GDPR, with role-based access and hashed passwords listed as non-functional requirements NFR2 and NFR3.

How to answer LO2: tools and methodologies

Research is not a list of every language you know. Compare realistic options against criteria drawn from your requirements.

  • Language and framework: for example C# with ASP.NET Core, Python with Django, or JavaScript with Node.js.
  • Database: relational (SQL Server, MySQL, PostgreSQL) versus document stores.
  • Tools: IDE, Git and a hosted repository, testing frameworks, a task board.
  • Methodology: Waterfall suits fixed requirements; Scrum or Kanban suit changing requirements and frequent client feedback.

Example paragraph: Scrum was selected over Waterfall because the gym manager wanted to see the booking screen early and was unsure how the waiting list should behave. Two-week sprints allowed a working booking feature to be demonstrated after the first sprint, and feedback from that demonstration changed the cancellation rules before they were coded. Waterfall would have fixed those rules in the design stage and made the change more expensive. The trade-off is that Scrum relies on regular client availability, which was managed by agreeing a fixed review slot every second Friday.

How to answer LO3: building the application

Treat the build as evidence collection. Assessors need to see the process, not just the final screens.

  • Peer review: present your design to classmates or the client, record their comments in a table and show what you changed.
  • Implementation: annotated code extracts for key algorithms (such as booking and waiting list logic), not the full code listing.
  • Code management: Git commits with meaningful messages and branches for features.
  • Testing: unit tests, integration tests and user acceptance testing, recorded in a test log.
  • Documentation: a short user guide with screenshots and technical notes on installation, structure and database.

How to answer LO4: evaluating performance

Return to your numbered requirements and mark each one with evidence. Then discuss reliability, usability, security and performance, and finish with prioritised improvements.

Example paragraph: Seven of the eight functional requirements were fully met. FR6, emailing members when a waiting-list place becomes free, was only partly met: the notification is created, but the email service was not configured on the test server, so messages are logged rather than sent. User acceptance testing with five gym members found the booking process clear, although two found the cancel button hard to locate on a phone. Moving the button and completing the email integration are therefore the first two improvements recommended.

Worked example: from requirement to test case

This short example shows the traceability that Merit and Distinction work depends on.

Requirement FR3: A member can book a class only if a place is free; otherwise they are offered the waiting list.

Algorithm (pseudocode):

  1. Get capacity of class (for example 12).
  2. Count confirmed bookings for that class.
  3. If the member already has a booking for this class, show “already booked” and stop.
  4. If confirmed bookings < capacity, create a confirmed booking.
  5. Otherwise, offer the waiting list and, if accepted, add the member with the next position number.
Test Input Expected result Actual
T1 Capacity 12, 11 booked, new member Booking confirmed, count becomes 12 Pass
T2 Capacity 12, 12 booked, new member Waiting list offered, position 1 Pass
T3 Member already booked on same class “Already booked” message, no duplicate Fail – duplicate created; fixed with a unique constraint and retested: Pass
T4 Two members book the last place at the same moment Only one booking confirmed Pass after adding a database transaction

Boundary tests (11 and 12 bookings) and a failure that was found and fixed (T3) are exactly the kind of testing and refinement evidence that supports M4 and M5.

Common mistakes that cost marks

  • Choosing a project that is too large and submitting half-finished features.
  • Requirements without IDs, so nothing can be traced through design, testing and evaluation.
  • Methodology research copied from generic sources with no link to your own project.
  • No evidence of peer review or of changes made because of it.
  • Pasting the full source code instead of annotated key extracts.
  • Testing only the “happy path” and ignoring invalid input and boundary values.
  • An evaluation that only praises the application.

How to move from Merit to Distinction

D1 asks you to evaluate both the solution and your methodology by comparison: state the alternatives, what each would have meant for this project and why your choice was better or, honestly, where it was not. D2 asks for justified improvements: rank them by value to the client and effort, explain the evidence behind each (test results, user feedback, performance data) and say how each would be implemented in a future iteration.

FAQs

Is Unit 30 Application Development the same as Unit 22?

The content is aligned. Unit 22 is the numbering in the current RQF Higher Nationals in Computing; older materials list Application Development as Unit 30. Follow the criteria printed on your own brief.

Which programming language should I use?

Use one you can work in confidently and that suits the problem. The marks come from design, process, testing and evaluation, not from choosing a fashionable language.

Do I need a working application to pass?

Yes. P5 requires a functional application with supporting documentation. It does not have to be large, but the core features must work.

What diagrams should a software design document include?

Typically a use case diagram, a class or entity relationship diagram, sequence or activity diagrams for key processes, and wireframes for the main screens.

How do I evidence peer review?

Record who reviewed the design, what they said, your response and the change made. A simple feedback table with dates and screenshots of before and after is enough.

Need one-to-one support from a subject specialist? Our BTEC Level 5 (HND) assignment help service covers planning, feedback on drafts and referencing.

If you are stuck on the design document or evaluation, you can get expert help with your BTEC assignment. You may also find our Database Design and Development answer guide and HND Computing and Software Development guide useful.

Top Assignment Services
Get AI-Free Assignment Help Instantly

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

iphone android
QRcode
WhatsApp Icon