3.1.4 - Formative project skills: requirements and success criteria
Requirements say what a proposed solution must provide; measurable success criteria make it possible to judge how well it provides it. You will practise writing precise behaviours, justifying an appropriate configuration and planning evidence for a conclusion. All cases and activities are formative project-skills practice, not a completed or certified H446/03 project.
Requirements describe necessary behaviour and constraints
A requirement states a necessary behaviour or constraint of the proposed solution, with enough detail to guide design and testing.
A functional requirement states what the solution must do. A non-functional requirement constrains qualities or conditions such as responsiveness, usability, compatibility or access. These categories help organise thinking; the important test is whether the wording communicates what is required and why.
For a fictional room-key checkout tool, “manage keys” is too vague. “Before confirming a loan, check whether the selected key has an active loan; reject confirmation if it does” specifies a decision and outcome. It leaves the developer free to design an appropriate algorithm. “Staff must be able to use the tool on the reception computer without internet access” states a deployment constraint that rules out an online-only solution.
Qualifiers matter. What counts as an active loan? Does the rejection leave records unchanged? Who can confirm a return? Resolve relevant uncertainty before using the statement as a test oracle. A test oracle is the basis for deciding the expected result. A vague requirement gives a vague oracle.
Requirements should trace back to evidence of needs. Duplicate active loans could cause staff to promise a key that has already been issued; this justifies the check. The reception's unreliable connection justifies offline operation. A requirement invented solely because a library makes it easy may add effort without solving the problem.
Do not require an implementation technique without a reason. “Use a database” says less about the necessary behaviour than “confirmed loan records must still be available after a normal restart”. Storage choices can then be justified against that behaviour and the volume, relationships and environment. You may need a particular technique where the actual constraints demand it, but it is not automatically essential.
Choose a configuration that fits the evidence
A hardware and software configuration is justified by what the solution needs to run and what the intended environment can supply.
Specify relevant hardware, operating-system compatibility, language/runtime, dependencies, storage and access conditions where appropriate. Avoid an unexplained specification such as “a powerful PC”, or an invented minimum amount of RAM. A small record-based tool does not require a graphics processor simply because one is available. If exact requirements have not been checked, identify the investigation needed rather than presenting a guess as a verified minimum.
For the key-checkout practice problem, suppose the receptionist uses one desk computer, the connection is unreliable and records must survive restarts. A local application with local persistent storage fits those facts. A suitable configuration investigation would check the intended operating system, runtime and GUI toolkit, permission to install dependencies, a writable data location and a backup location. It would also test behaviour on that actual computer with representative records. An external database server would need justification if the task does not require shared remote access.
Distinguish development from deployment. The IDE supports editing, running and debugging during development; it need not be a requirement for every end user. The runtime and required libraries must be available wherever the application runs. A development machine successfully running a prototype does not prove compatibility with the reception machine.
For H446/03, use a suitable text-based high-level general-purpose language and a suitable graphical interface. Python, the C family, Java, Visual Basic, PHP and Delphi appear in the current specification list; other choices require OCR consideration. Python console work alone does not establish the assessed GUI requirement. A desktop preparation route uses a suitable local IDE and an installed GUI toolkit; a web route uses a browser/editor and appropriate high-level processing with its required environment. HTML/CSS alone supply markup and presentation, rather than the substantial high-level code. The centre must check language approval and any exceptional command-line authorisation with OCR.
This build's NovaLearn console runner cannot verify graphical controls, external dependencies or deployment. Check those in the actual external environment. Describe that boundary accurately in a formative configuration proposal.
Continue this lesson.
You’re previewing NovaLearn without an account. Create a free account to read the rest.
Create free account