- Published
- 8 October 2026
- Last reviewed
- 8 October 2026
How to use this glossary
Use this glossary when exploring a business problem, reviewing requirements or preparing stakeholder conversations. These are introductory explanations, not the full definitions used in a certification syllabus.
Browse the alphabetical term index below. Select a term to jump to its definition, example and common mistake. Use the return link after each entry to browse again. You can also use your browser’s Find command to locate a word on this page. Definitions are original RDE plain-language explanations. All examples are fictional teaching scenarios.
Term index
12 terms, listed alphabetically.
- Acceptance criteria
- Assumption
- Business requirement
- Design
- Elicitation
- Functional requirement
- Non-functional requirement
- Requirement
- Stakeholder
- Traceability
- Transition requirement
- User story
Definitions and practical examples
Acceptance criteria
Meaning: Specific conditions used to decide whether a requirement or delivered item is acceptable.
Example: For a fictional contact form, a valid submission produces one reference number and one confirmation message.
Common mistake to avoid: Write observable conditions. “Works well” does not tell a reviewer what to check.
Assumption
Meaning: An unconfirmed statement used provisionally while planning or analysing work.
Example: A team assumes that coordinators can access the shared request system during every shift.
Common mistake to avoid: Record how and when it will be checked. An assumption is not evidence.
Business requirement
Meaning: An organisational objective explaining why a change is needed.
Example: A training provider wants fewer missed enquiries and a more reliable response process.
Common mistake to avoid: Keep the objective separate from a chosen software feature.
Design
Meaning: A representation of a proposed solution to a need.
Example: A prototype shows a priority queue for enquiries, with a filter for urgent requests.
Common mistake to avoid: A polished prototype does not establish that it meets the need.
Elicitation
Meaning: Work to uncover information needed to understand a change.
Example: An analyst interviews coordinators and observes how they identify urgent requests.
Common mistake to avoid: Do not rely solely on the loudest stakeholder or on leading questions.
Functional requirement
Meaning: A capability or behaviour that a solution should provide.
Example: The system must allow an authorised coordinator to assign an enquiry to an owner.
Common mistake to avoid: State the behaviour without assuming every implementation detail has been agreed.
Non-functional requirement
Meaning: A required quality or constraint affecting how a solution operates.
Example: The team specifies a measurable response-time target for opening the enquiry queue under defined load.
Common mistake to avoid: Specify conditions and a test method. “Fast” is not a measurable quality requirement.
Requirement
Meaning: A usable description of a need to be met.
Example: Coordinators need to identify enquiries that have not received a response within the agreed period.
Common mistake to avoid: Explain whose need is represented and the purpose it serves.
Stakeholder
Meaning: A person or group connected to the need, change or solution.
Example: Learners, administrators and the service owner have different interests in a new enquiry process.
Common mistake to avoid: Include affected users and decision makers, not only people attending the project meetings.
Traceability
Meaning: Recorded relationships connecting needs, requirements, designs and verification evidence.
Example: A requirement ID links to the original interview note, prototype decision and test result.
Common mistake to avoid: A list of requirements alone does not show these relationships.
Transition requirement
Meaning: A temporary capability needed to move from the current to the future state.
Example: Before launch, administrators need existing open enquiries transferred and checked in the new system.
Common mistake to avoid: Separate temporary migration needs from ongoing operating requirements.
User story
Meaning: A short description of a user goal that supports further discussion.
Example: As a coordinator, I want to see unassigned enquiries so that I can arrange a response.
Common mistake to avoid: A story is not a complete specification; discuss examples, boundaries and acceptance criteria.
A distinction worth keeping clear
A requirement gives a need a form that people can discuss and check. A design describes a proposed way to meet it. A request for a particular screen may contain both. Ask which need the screen should support before treating the proposed design as the only answer.
Practise using the terms
A team requests a dashboard because staff repeatedly miss urgent requests. Identify the need, one possible functional requirement and one acceptance criterion. Explain why the dashboard is a design choice rather than the need itself. Write your answer in your own notes before reading the explanation. No answer is submitted or stored by this page.
Suggested answer and explanation
The need is to recognise and act on urgent requests. A functional requirement could be to flag unresolved urgent requests for an authorised coordinator. An acceptance criterion could specify that a test urgent request appears in the coordinator queue with the correct priority. A dashboard is one possible way to present that information; the team must investigate whether it addresses the actual problem.
Sources and scope
The sources below support the terminology and relevant context. The definitions, examples, cautions and practice tasks on this page are original RDE teaching material, not verbatim extracts or a replacement for an official standard or certification syllabus. Reviewed 8 October 2026. Author: Jefferson Otonbara Imgbi.
Cover image: AI-generated illustrative scene created specifically for this resource.