## Learning Outcomes

After reading this article, you will be able to explain the steps involved in testing new or changed business systems, including how requirements are verified through test planning, execution, and acceptance procedures. You will understand different types of testing, user roles in acceptance, and the documentation needed to confirm a system meets its original requirements.

## ACCA Business and Technology (BT) Syllabus

For ACCA Business and Technology (BT), you are required to understand how business systems are developed, tested, and accepted, ensuring they meet user requirements. This article covers key syllabus points:

- The purpose and process of requirements testing in systems development
- Types and levels of testing, including user acceptance testing
- The importance of clear acceptance criteria and sign-off procedures
- Roles of users and business in testing and acceptance
- The documentation and communication needed throughout testing and acceptance

## Test Your Knowledge

_Attempt these questions before reading this article. If you find some difficult or cannot remember the answers, look more closely at that area during your revision._

1. What is the main objective of requirements testing in the context of business systems development?
2. Name two differences between system testing and user acceptance testing.
3. Who is responsible for approving system acceptance before a new system goes live?
4. What must be included in formal system acceptance documentation?

## Introduction

Testing new or changed systems is essential for confirming that business requirements have been met. A robust testing and acceptance process helps prevent costly errors, minimises operational disruption, and ensures user needs are satisfied. Knowing the approach to requirements testing and formal acceptance is a key part of business technology and change management.

> **Key Term: Requirements testing**
> The process of evaluating a new or changed system to confirm it functions as specified in the original business requirements.
>
> **Test Tip:**
> When revising Requirements testing and acceptance, connect each definition, method, or rule to the kind of question the assessment is likely to ask.

### The purpose of requirements testing

Systems development should always be tied to specific, documented requirements—these describe what the system must do, who will use it, and the conditions it must operate under. Requirements testing ensures that these are properly delivered when the system is built or updated. All relevant groups—users, IT staff, and management—must confirm the system performs as expected under real operating conditions.

### Types and stages of testing

Several types of testing occur before a system can be accepted.

### Unit and assembly testing

Developers test individual components (unit testing) to confirm that isolated modules or programs work correctly. Assembly testing checks that multiple components operate together as intended.

### System testing

Once modules are combined, system testing is performed to verify that the entire application or process works according to design. Test cases trace directly to the documented requirements.

### User acceptance testing (UAT)

User acceptance testing evaluates the system as a whole under conditions similar to normal daily operations.

> **Key Term: User acceptance testing (UAT)**
> Testing carried out by end users to confirm that a new or changed system meets agreed business requirements and is ready for use in practice.

Users play a direct role, working with sample data and real-life scenarios agreed in advance. Their goal is to confirm the system is usable, complete, and fit for its intended purpose.

### Regression testing

Whenever changes are made or faults are corrected, regression testing is used to verify these changes do not have unwanted side effects elsewhere in the system.

### Acceptance criteria

At the start of any system project, measurable acceptance criteria should be agreed by the business, IT, and other key stakeholders. These criteria must relate directly to the documented requirements.

> **Key Term: Acceptance criteria**
> A set of agreed standards, outputs, and conditions that a system must meet for formal business acceptance.

Examples of acceptance criteria:

- The system processes transactions at the required speed
- Reports contain all required data fields without errors
- The interface meets accessibility needs for users

### The acceptance process

Once all planned testing has been completed, the system is subject to a formal acceptance process.

![Requirements testing and formal acceptance stages from documented requirements through UAT, defect resolution, regression testing, sign-off, and go-live approval.](https://static.pastpaperhero.com/images/acca-bt-systems-development-and-change-requirements-testing-and-acceptance_00.png)

_System verification process showing agreed acceptance criteria, planned testing stages, defect remediation and regression, then user sign-off and go-live approval._

### Steps in system acceptance

1. **Summary of test evidence:** A report is prepared summarising test results, issues found, and evidence that all requirements have been covered.
2. **User sign-off:** Users, usually key representatives from the business, review the evidence and perform their own final checks.
3. **Formal acceptance:** If all acceptance criteria are met and outstanding issues are deemed acceptable, designated business representatives sign a formal acceptance document.
4. **Go-live approval:** Only after acceptance is signed can the system be deployed to operational use.

### Worked Example 1.1

A new payroll system is developed for a large company. After system testing by IT, HR users perform UAT, using actual employee records and checking payslips, deductions, and end-of-year reports.

**Question:** What steps must occur before the payroll system can replace the current one?

> **Answer:**
> HR users must confirm all requirements are met through acceptance testing and sign an official acceptance document. Only then can the system go live.

### Roles and responsibilities

Clear roles must be defined in the requirements testing and acceptance process.

- **Developers** build and unit-test the system components.
- **Testers** (often a mix of users and IT staff) ensure system and assembly testing is thorough.
- **Business users** carry out and approve user acceptance testing, confirming that the system is suitable for real use.
- **Management or project sponsor** authorises the final acceptance, based on evidence provided.

> **Key Term: Sign-off**
> The formal procedure where an authorised person certifies that a system or deliverable has met all specified requirements.

### Test planning and documentation

A well-controlled testing and acceptance process relies on thorough documentation.

- **Test plan:** Outlines all requirements, the tests to be carried out, resources and schedules.
- **Test scripts:** Detailed instructions or step-by-step scenarios used to check each requirement.
- **Test results log:** Records evidence for each test, including outcomes and any defects found.
- **Acceptance report:** A summary for business and management sign-off.

Proper records provide assurance that due process was followed and protect the organisation in the event of future disputes.

### Dealing with test failures or issues

It is common to discover defects or discrepancies during testing. All issues must be logged, investigated, and either resolved or agreed for later correction (with business approval). Only the business can authorise "go live" with known issues, and any risks must be clearly documented.

### Worked Example 1.2

During UAT for a new inventory system, users discover that certain reports do not sort data in the required order.

**Question:** What should be done before the system is accepted?

> **Answer:**
> The issue must be logged, evaluated, and either fixed before acceptance or, if agreed acceptable by business users, noted in the acceptance documentation with an action plan to address it after go-live.

### Importance of clear acceptance procedures

A formal acceptance process:

- Assigns responsibility for decision-making to the business, ensuring the system meets practical needs
- Documents which requirements have been tested and signed off
- Protects against "scope creep" by focusing only on agreed requirements

Without robust testing and acceptance, costly errors or operational failures may occur.

> **Exam Warning:**
> Never assume a system can go live just because IT testing is complete. Formal business sign-off is always required for true acceptance.

## Summary

Requirements testing and acceptance confirm that business systems or changes deliver on agreed needs before going live. Successful acceptance relies on clear criteria, documented evidence, thorough user testing, and formal sign-off by the business. This ensures that systems truly deliver value and minimise risk.

## Key Point Checklist

_This article has covered the following key knowledge points:_

- The stages and objectives of requirements testing in systems development
- Differences between system testing and user acceptance testing (UAT)
- The function and content of acceptance criteria and sign-off
- The roles of developers, testers, users, and management in the acceptance process
- The importance of thorough documentation throughout the testing and acceptance process
- Actions to take when discrepancies are found during testing
- The necessity of formal business sign-off before a new system goes live

## Key Terms and Concepts

- Requirements testing
- User acceptance testing (UAT)
- Acceptance criteria
- Sign-off


Systems development and change - Requirements testing and acceptance