Unit 12 Assignment guide

Level 1, Pass, Merit and Distinction

Grade	Typical command words	What the assessor looks for
Level 1	Identify, produce with guidance	You can identify the main points and complete the work with help from your teacher.
Level 2 Pass	Explain, describe, produce, develop, test	Clear explanations in your own words and complete, working evidence: a design, a program with comments, and a completed test plan.
Level 2 Merit	Comment on, produce a detailed…, review the extent	More depth: alternatives in your design, a fully functional program, feedback from others used to improve it, and judgements about how far it meets the requirements.
Level 2 Distinction	Discuss, justify, refine, evaluate	Balanced arguments and reasons: justify design decisions against requirements and constraints, refine code for quality, compare the final program with your design and recommend improvements.

Meet every Pass criterion first. Merit and Distinction build on the same work: they are about the quality of your thinking, not the length.

Assignment 1: Characteristics and uses of software programs

Learning aim A. You are on work experience at a software development company. Your line manager gives you two simple programs the company has written and asks you to explain how they work and comment on their quality, before you are trusted to write code for a client. Your teacher supplies the two programs and the official brief.

Hand in: A report on the two programs (with annotated code and a flowchart)

Criterion	What the task asks (in plain English)	Checklist: a strong answer…	Help
1A.1 / 2A.P1	Explain the purpose and characteristics of two programs For each of the two simple programs, explain what it is for (its purpose) and its characteristics: the type of language, its inputs, processing and outputs, and the tools and techniques it uses (command words, subroutines, string handling, file handling, data structures, event handling, selection, loops, variables and data types). Level 1 (1A.1) only needs you to identify these; Level 2 Pass needs you to explain them.	The purpose of each program is explained in your own words Inputs, processing and outputs are identified for each program The type of programming language is stated (e.g. event-driven Visual Basic) with a reason Each construct or technique used is named AND you explain what it does in that program You refer to specific lines or parts of the code (annotated screenshots help) You have run the programs (or dry-run them with a trace table) and say what happens It is written in your own words	A1 A2 A3 Open in builder →
2A.M1	Comment on quality, suggest improvements and draw a flowchart Choose one of the programs and comment on its quality using the quality measures (efficiency, maintainability, portability, reliability, robustness, usability). Suggest improvements, and provide a flowchart showing how the program would process data once your improvements were made.	Each quality measure is covered with evidence from the code (not general statements) Weaknesses are identified, e.g. no validation, unclear names, repeated code, no comments Each improvement is specific and linked to the weakness it fixes The flowchart uses the correct symbols (start/end, input/output, process, decision) The flowchart shows the improved processing, including any new validation or decisions The flowchart has been checked with test values (a dry run)	A4 B4 Open in builder →
2A.D1	Discuss the strengths and weaknesses of the program Discuss the strengths and weaknesses of the software program in a balanced way, considering its purpose, its users and the quality of its design and code, and reach a conclusion about how good it is.	Strengths AND weaknesses are both covered, with evidence from the code Points are linked to the program’s purpose and its users Quality measures are used to structure the discussion You weigh up which strengths and weaknesses matter most, and why You reach a supported overall conclusion	A4 Open in builder →

Assignment 2: Design, develop and test a software program

Learning aims B and C. A client has given your company a brief describing a problem that a software program could solve, such as replacing a paper-based booking or ordering system. You will design the program, develop it in Visual Basic (or the language your teacher sets), and test and refine it. Your teacher gives you the official brief with the client’s requirements.

Hand in: Design documents, the working program (source code with comments and an executable), a completed test plan with screenshots, a feedback and changes log

Criterion	What the task asks (in plain English)	Checklist: a strong answer…	Help
1B.2 / 2B.P2	Describe the purpose and user requirements Show that you understand the brief: describe the intended purpose of the program and the user requirements. Level 1 identifies them; Level 2 describes them in detail.	The intended purpose is described in your own words (not copied from the brief) Every user requirement from the brief is listed Each requirement is described: what it means and why the user needs it You identify who the users are It is presented clearly and professionally, as a report for the client	B1 B2 Open in builder →
1B.3 / 2B.P3	Produce a design for the program Produce a design including a problem definition statement, a proposed solution (main tasks with inputs and outputs, screen layouts and navigation, algorithms in pseudocode or flowcharts, data structures and storage, validation), a list of any predefined functions/subroutines with sources, and a test plan.	A problem definition statement describes the current problem and how the program will solve it The main program tasks are described with inputs, processing and outputs Screen layouts are annotated (every control labelled with its type and purpose) A navigation diagram shows how the screens link Algorithms are shown as pseudocode and/or flowcharts Data structures, data storage and validation are planned Predefined functions/subroutines are listed with their sources A test plan lists tests, test data and expected results	B2 B3 B4 B5 Open in builder →
2B.M2	Produce a detailed design with alternatives Produce a detailed design that includes alternative solutions, a detailed proposed solution using a range of design tools, and test data.	At least two alternative solutions are shown (e.g. two screen layouts or two algorithms) The differences between alternatives are explained The proposed solution uses a range of tools: IPO table, annotated layouts, navigation diagram, pseudocode/flowcharts, data design Control structures, validation and error handling are planned in detail Test data covers normal, boundary and erroneous values for each input	B3 B4 B5 Open in builder →
2B.D2	Justify the design decisions Justify your design decisions, including how they will fulfil the stated purpose and user requirements, and any design constraints.	Each major decision (layout, navigation, data structures, validation, algorithms) is justified Justifications link back to specific user requirements and the purpose You explain why the chosen alternative is better than the others Constraints (language, time, device capabilities) are identified and you explain how they shaped the design	B2 B3 B5 Open in builder →
1C.4 / 2C.P4	Develop the program Develop a program for the brief which includes a user interface (input and output), constructs and techniques, and commentary (comments) throughout the code. Level 1 is developed with guidance.	The program has a user interface with clear inputs and outputs It uses a range of constructs: variables and data types, selection, iteration, subroutines It uses techniques such as string handling, file handling, arrays/records and event handling where the brief needs them Comments explain what each part of the code does Controls and variables have meaningful names The program has been compiled into an executable Any predefined code is acknowledged in comments	C1 C2 C3 C4 C5 C6 C7 Open in builder →
2C.M3	Develop a functional program that meets the brief Develop a fully functional program that meets the given brief.	Every user requirement in the brief is implemented The program runs without crashing for normal use Input is validated and errors are handled with helpful messages Calculations and outputs are correct (checked by testing) Data is stored and retrieved correctly where required	C3 C4 C5 C6 C7 Open in builder →
1C.5 / 2C.P5	Test for functionality and repair faults Test the program for functionality using the test plan and against the original requirements, and repair any faults.	Every test in the test plan has been carried out Actual results and pass/fail are recorded for each test Screenshots provide evidence of the tests The program is checked against each original requirement Faults are repaired and the failed tests are re-run The repairs are recorded (what was wrong and how it was fixed)	B5 C8 Open in builder →
2C.M4	Gather feedback and use it to improve Test the program using the test data, gather feedback from others on the usability and quality of the program, and use it to improve the software program. Repair any faults.	Feedback is gathered from real users or others (e.g. a questionnaire or interview) Feedback covers usability and quality (reliability, efficiency, maintainability, portability) The feedback is recorded with who gave it Changes made because of feedback are described and re-tested Faults found are repaired	C8 Open in builder →
2C.D3	Refine the program using code quality and feedback Refine the software program, taking account of the quality of the code and user feedback.	The code is reviewed for quality: names, comments, structure, repetition, efficiency Refinements improve code quality (e.g. subroutines instead of repeated code, constants, better validation) Refinements respond to user feedback Each refinement is explained and justified The refined program is re-tested and still meets the requirements Design documents are updated to match the final program	A4 C5 C8 Open in builder →

Assignment 3: Review the finished software program

Learning aim D. The client wants to know how well the program you developed in Assignment 2 meets their needs before it is used every day. Your teacher gives you the official brief and the format (a report or a presentation).

Hand in: A review report or presentation, with evidence from testing and feedback

Criterion	What the task asks (in plain English)	Checklist: a strong answer…	Help
1D.6 / 2D.P6	Explain how the program is suitable for the requirements and purpose For the software program, explain how the final program is suitable for the original requirements and purpose. Level 1 identifies how; Level 2 explains.	Each original requirement is listed with how the program meets it Fitness for purpose is explained: does it solve the client’s problem? Evidence is given (test results, screenshots) It is written in your own words, for the client	D1 Open in builder →
2D.M5	Review the extent to which requirements are met Review the extent to which the software program meets the original requirements, considering feedback from others and any constraints.	You judge how far each requirement is met (fully, partly, not met) with reasons User feedback is used as evidence User experience (ease of navigation, clarity) is reviewed Constraints are discussed: how they affected the program and how you worked around them Quality is reviewed using the quality measures	D1 Open in builder →
2D.D4	Evaluate against designs and code quality, and recommend improvements Evaluate the final software program against the initial designs and the quality of the code, justify any changes made, and make recommendations for further improvement.	The final program is compared with the initial design, element by element Every change from the design is identified and justified The quality of the code is evaluated with examples Strengths and weaknesses are weighed to reach supported conclusions Recommendations for further improvement are specific and justified	D1 A4 Open in builder →

Your own work, and using AI properly

BTEC assignments must be your own work. You sign a declaration saying so. Copying from the internet, another student or an AI tool, even if you change the words, is malpractice and can mean losing the unit.

Allowed: asking the AI tutor or coach to explain an idea, quiz you, check what a task is asking, help you plan, or tell you what is missing from your draft.
Not allowed: asking any AI to write your code, pseudocode, designs, test plans or reviews, or copying AI code or wording into your work. Your program must be written by you.
Be open: the Assignment builder keeps an AI-use log of every question you ask the coach. Download it and hand it in, and tell your teacher how AI helped you.
Do not put personal details (yours or anyone else’s) into the tutor.