Systems Development, Acquisition and Change Management

Introduction

Accounting information systems (AIS) are not static collections of software. They are socio-technical systems comprising people, procedures, data, technology, controls and management responsibilities. When an organisation introduces a new enterprise resource planning (ERP) system, replaces a payroll application, automates accounts payable or moves accounting records to the cloud, it is changing how transactions are authorised, recorded, reported and controlled.

Systems development and acquisition therefore require more than selecting technically attractive software. The organisation must identify business needs, evaluate risks and feasibility, design appropriate processes and controls, test the solution, convert data, train users and manage the transition. Poorly managed change can produce inaccurate financial reporting, control failures, service disruption, privacy breaches and resistance from employees.

This chapter explains the systems development life cycle (SDLC), requirements analysis, feasibility, system design, testing, conversion, documentation and maintenance. It also compares building, buying, outsourcing and cloud-based solutions, and examines implementation and user adoption from an accounting and governance perspective.

Learning Objectives

By the end of this chapter, a student should be able to:

1. Explain the stages and governance principles of the SDLC.
2. Analyse accounting information system requirements and distinguish functional from non-functional requirements.
3. Evaluate technical, economic, operational, legal and schedule feasibility.
4. Compare in-house development, packaged software, outsourcing and cloud services.
5. Explain logical and physical system design, including internal controls.
6. Distinguish unit, integration, system, performance, security and user acceptance testing.
7. Compare direct, parallel, pilot and phased conversion strategies.
8. Explain documentation, maintenance, configuration management and change control.
9. Recommend practices that support implementation, ethical governance and user adoption.

1. The Systems Development Life Cycle

The SDLC is a structured framework for planning, creating, implementing and maintaining an information system. Although organisations use different names and models, the principal stages are:

1. Initiation and planning – identify a business problem or opportunity, define scope, appoint sponsors and prepare an initial business case.
2. Requirements analysis – determine what users, managers, auditors and regulators require from the system.
3. Feasibility and acquisition decision – assess whether the proposed solution is viable and decide whether to build, buy, outsource or use a cloud service.
4. Design – specify processes, data structures, interfaces, controls, reports, security and technical architecture.
5. Development or configuration – create software or configure and integrate a purchased product.
6. Testing – evaluate whether the system operates correctly, securely and in accordance with approved requirements.
7. Implementation and conversion – install the system, migrate data, train users and move into production.
8. Operation, maintenance and review – monitor performance, correct defects, implement approved changes and evaluate whether benefits have been achieved.

The traditional waterfall approach completes these stages sequentially, with formal approval points between them. It provides traceability and predictable documentation but may respond slowly to changing requirements. Agile approaches use short iterations, frequent demonstrations and continuous stakeholder feedback. Agile can improve usability and responsiveness, but it still requires strong accounting controls, documented approvals, testing evidence and audit trails. Agile does not mean uncontrolled development.

A hybrid approach is common in AIS projects: iterative development may be used for user-facing functions, while formal governance controls major interfaces, data migration, access rights and financial reporting.

2. Project Initiation and Governance

A project begins with a clearly defined problem rather than a preferred technology. For example, “purchase a cloud ERP” is a proposed solution; “reduce invoice-processing delays and eliminate duplicate payments” is a business problem.

A project charter normally identifies:

• the business objective and expected benefits;
• project scope, exclusions and assumptions;
• sponsor, project manager and decision rights;
• stakeholders and affected departments;
• estimated resources, costs and schedule;
• major risks and dependencies;
• approval criteria and governance arrangements.

A steering committee should include business, finance, information technology, internal audit, security and operational representatives. Segregation of duties is important: the person responsible for defining requirements should not unilaterally approve vendor selection, and developers should not independently move untested code into production.

A business case should compare expected benefits with total costs and risks. Costs include software licences or subscriptions, implementation services, data migration, training, controls, integration, support, downtime and future enhancements. Benefits may include faster processing, fewer errors, better compliance, improved information quality and reduced operating costs. Benefits should be measurable where possible.

A simple net-benefit relationship is:

This relationship is useful for comparing alternatives, but it is not sufficient by itself. It assumes that benefits and costs can be estimated reliably and that non-financial factors—such as privacy, resilience, strategic fit and regulatory exposure—are also assessed.

3. Requirements Analysis

Requirements analysis translates organisational needs into testable statements. It is one of the most important stages because defects or omissions discovered after implementation are usually more expensive to correct.

Functional and Non-functional Requirements

A functional requirement describes what the system must do. Examples include:

• calculate sales tax according to approved tax rules;
• prevent posting to a closed accounting period;
• match a purchase order, goods receipt and supplier invoice;
• produce an aged accounts receivable report;
• record who approved a journal and when.

A non-functional requirement describes a quality, constraint or operating condition. Examples include:

• authorised users must authenticate using multi-factor authentication;
• monthly reports must be available within a specified time;
• the system must retain audit logs for the required period;
• the service must meet an agreed availability level;
• personal data must be encrypted in transit and at rest.

Requirements should be unambiguous, necessary, prioritised, traceable and testable. “The system should be user-friendly” is weak because it is subjective. “A trained accounts clerk shall complete a standard supplier-invoice entry in no more than five screens” is more testable, although the organisation would still need to define the test conditions.

Requirements-Gathering Techniques

Common techniques include interviews, workshops, observation, document review, questionnaires, process modelling, prototypes and analysis of existing system logs. Each has limitations. Interviews reveal perceptions but may omit unrecognised workarounds. Observation shows actual practice but may influence behaviour. Workshops encourage agreement but dominant participants can suppress minority views. Prototypes help users evaluate screens but may create unrealistic expectations if users mistake a prototype for a finished system.

A requirements catalogue should identify the requirement, source, priority, owner, acceptance test and status. A traceability matrix links each requirement to design components, test cases and implementation evidence. This is particularly valuable for financial reporting controls and audit examinations.

Process and Data Analysis

Analysts should document current processes (“as-is”) and proposed processes (“to-be”). They should identify inputs, outputs, decision points, hand-offs, exceptions, control activities and information owners. Data analysis should address definitions, formats, duplicates, completeness, retention, master-data ownership and relationships among customers, suppliers, employees, accounts and transactions.

Accounting requirements deserve special attention. The system should preserve transaction evidence, maintain an audit trail, enforce appropriate approval limits, support period close, protect segregation of duties and produce reports consistent with the organisation’s accounting policies and applicable reporting framework.

4. Feasibility Analysis

Feasibility analysis determines whether an alternative is practicable and worth pursuing. It should be performed before major commitments are made and revisited when assumptions change.

Economic evaluation should include recurring costs and exit costs, not only the initial purchase price. Sensitivity analysis is useful because estimates may be uncertain. For example, the business case can be tested under higher implementation costs, lower adoption, delayed benefits or increased subscription fees.

A technically feasible system may still be operationally infeasible if staff cannot use it, data owners are unavailable or the organisation lacks a sustainable support capability. Similarly, a low-cost solution may be unacceptable if it creates excessive privacy or business-continuity risk.

5. Build, Buy, Outsource and Cloud Options

In-house Development

Building software internally provides control over functionality, architecture and change priorities. It may be appropriate where processes are strategically distinctive or commercial products cannot meet important requirements. Its disadvantages include high development cost, dependence on scarce skills, longer delivery time and responsibility for ongoing security and maintenance.

Packaged Software

Commercial packages contain standardised functionality and may incorporate established accounting practices, tax features and reporting capabilities. They are usually faster to implement than a completely new system. However, the organisation may need to change its processes, pay for customisation and manage upgrades. Excessive customisation can destroy the benefits of standardisation and make future upgrades difficult.

Outsourcing

Outsourcing transfers selected development or operational responsibilities to an external provider. It may provide specialist skills, scale and predictable service arrangements. It also creates risks involving vendor dependence, confidentiality, service quality, subcontractors, data location, intellectual property and exit capability. A contract should specify service levels, security responsibilities, incident notification, audit rights, data ownership, business continuity, termination assistance and return or deletion of data.

Cloud Computing

Cloud services provide computing resources or applications through a network. In software as a service (SaaS), the provider operates the application and infrastructure while the customer configures business settings and remains accountable for appropriate use, access and data governance. Cloud services may improve scalability, remote access and speed of deployment, but they do not eliminate risk. Important questions concern availability, identity management, data residency, integration, backup, resilience, concentration risk and the organisation’s ability to retrieve data if the contract ends.

The decision should be based on requirements, risk appetite, total lifecycle cost and strategic importance—not on fashion or initial price alone.

6. System Design

System design converts approved requirements into an implementable blueprint. Logical design describes what the system does independently of a particular technology. It includes business processes, data entities, rules, inputs, outputs and controls. Physical design specifies the technology, databases, networks, program components, configurations and deployment arrangements.

Important design concerns include:

• chart of accounts and accounting dimensions;
• master-data structures and ownership;
• transaction validation and authorisation;
• interfaces with banking, payroll, inventory and tax systems;
• report definitions and reconciliation procedures;
• access roles and least-privilege permissions;
• audit logs and evidence retention;
• backup, recovery and continuity arrangements;
• privacy, encryption and secure integration.

Controls should be designed into the system rather than added after development. Preventive controls may include approval limits, field validation and segregation of duties. Detective controls may include exception reports, reconciliations and review of audit logs. Corrective controls may include controlled reversals, recovery procedures and incident response.

A role-based access model assigns permissions according to job responsibilities. For example, a user may prepare a supplier invoice but not approve the same invoice or release the payment. Access should be reviewed periodically, especially after transfers, resignations and organisational restructuring.

7. Development, Configuration and Testing

Development involves programming, configuration, integration and preparation of technical environments. A controlled environment normally separates development, testing and production. Developers should not make unreviewed changes directly in production.

Testing provides evidence that the system meets requirements and that controls operate as intended. Important testing levels include:

1. Unit testing – tests an individual program component or configuration element.
2. Integration testing – tests interfaces and data exchange between components or systems.
3. System testing – evaluates the complete system against specified requirements.
4. Performance testing – assesses response time, capacity and behaviour under expected or peak workloads.
5. Security testing – evaluates authentication, authorisation, vulnerabilities, logging and resilience.
6. User acceptance testing (UAT) – authorised business users determine whether the system is fit for operational use.
7. Regression testing – confirms that a change has not damaged previously functioning features.

Test cases should specify preconditions, inputs, expected results, actual results, evidence, tester and status. Financial systems require both normal and exceptional scenarios: duplicate invoices, invalid tax codes, over-limit purchases, back-dated entries, interrupted interfaces, cancelled payments and unauthorised journal attempts.

Testing should use representative data while protecting personal and confidential information. Production data should not be copied into test environments without appropriate masking, authorisation and security controls.

A defect is not necessarily evidence that requirements were wrong; it may reflect a coding error, configuration error, ambiguous requirement or unsuitable design. Defects should be classified by severity and resolved through controlled procedures.

8. Conversion and Implementation

Conversion transfers the organisation from an old system to a new one. Before migration, data should be profiled, cleansed, mapped, transformed and reconciled. Master data and opening balances require particular care. A migration reconciliation may compare the number and monetary value of records before and after conversion, investigate differences and obtain formal sign-off.

Four common conversion strategies are:

• Direct conversion: the old system is stopped and the new system starts immediately. It is fast and inexpensive but carries high operational risk.
• Parallel conversion: old and new systems operate together for a period. It provides comparison and assurance but costs more and increases workload.
• Pilot conversion: the new system is introduced in one location or department first. Lessons can be applied before wider deployment.
• Phased conversion: functions, modules or business units are introduced in stages. It reduces concentration of risk but may require temporary interfaces between old and new systems.

The appropriate strategy depends on risk, criticality, system complexity, data quality and available resources. A cutover plan should define responsibilities, timing, decision gates, contingency arrangements, rollback criteria and communication channels.

Implementation also includes user training, help-desk support, updated procedures, access provisioning, management reporting and post-implementation review. Training should be role-based and practical. Users need to understand not only which buttons to press but also why controls exist and how exceptions should be handled.

9. Documentation and Maintenance

Documentation supports operation, training, audit, continuity and future change. Important documents include:

• project charter and business case;
• requirements catalogue and traceability matrix;
• process maps and data-flow diagrams;
• logical and physical designs;
• data dictionary and interface specifications;
• control descriptions and access matrices;
• test plans, results and acceptance approvals;
• conversion plans and reconciliation evidence;
• user manuals and operating procedures;
• disaster recovery and incident procedures;
• change records and configuration baselines.

Maintenance is commonly classified as:

• Corrective: fixing defects discovered after implementation;
• Adaptive: modifying the system for new laws, platforms or environments;
• Perfective: improving performance, usability or functionality;
• Preventive: reducing the likelihood of future failures.

All changes should pass through a change-control process. A change request should explain the reason, scope, affected components, risks, cost, testing requirements, implementation plan and rollback method. Emergency changes may follow an accelerated process, but they should be reviewed retrospectively. Version control and configuration management ensure that the organisation knows which approved version is operating in production.

10. Change Management and User Adoption

Technology implementation is also organisational change. Users may resist because they fear job loss, loss of expertise, increased monitoring, unfamiliar procedures or failure. Resistance is not always irrational; it may reveal genuine design defects or unrealistic workloads.

Effective change management includes:

1. visible executive sponsorship;
2. early involvement of representative users;
3. clear explanation of the reason and expected benefits;
4. change-impact assessment by role and process;
5. training, practice environments and local champions;
6. accessible support during and after go-live;
7. measurement of adoption, errors, processing time and control compliance;
8. reinforcement through feedback, recognition and updated performance expectations.

A useful principle is that participation should be meaningful, not merely symbolic. Users should be able to challenge requirements and report risks without fear of retaliation. Management should distinguish legitimate control requirements from unnecessary complexity.

11. Case Study: Meridian Retailers’ Accounts Payable Transformation

The following is an illustrative case.

Background

Meridian Retailers operates 35 stores and a central warehouse. Its accounts payable process uses email approvals, spreadsheets and a ten-year-old accounting application. Duplicate supplier invoices occur, management cannot reliably identify invoices awaiting approval and month-end close takes twelve working days.

Problem

The finance director proposes a cloud-based procure-to-pay module integrated with the general ledger. The project team must determine whether to build a custom workflow, buy a package, outsource processing or adopt a SaaS platform.

Analysis

Requirements workshops identify the need for purchase-order matching, delegated approval limits, supplier master-data controls, electronic audit trails, exception reporting, segregation of duties and integration with inventory and banking systems. The team also identifies non-functional requirements for availability, response time, privacy, data retention and business continuity.

A feasibility review finds that Meridian lacks the skills to build and support a secure workflow application. A commercial package provides most required functions, while SaaS reduces infrastructure responsibility. However, the team identifies risks involving data residency, vendor concentration, integration failure and inability to operate during an outage.

Approach and Solution

Meridian selects a SaaS package after a competitive evaluation. The contract includes security obligations, service-level commitments, incident notification, audit rights, data export, exit assistance and recovery requirements. The organisation rejects extensive customisation and changes several approval processes to fit standard functionality.

The project team cleanses supplier records, removes duplicates and maps legacy account codes to the new chart of accounts. It performs unit, integration, security, performance and user acceptance testing. Test scenarios include duplicate invoices, split purchases, rejected invoices, over-limit approvals and interrupted bank interfaces.

A pilot begins in six stores. During the pilot, users identify that temporary managers require delegated approval rights and that one supplier’s invoice format causes matching exceptions. The design is adjusted before a phased rollout to the remaining stores. Parallel operation is used for the first monthly close.

Outcome

After implementation, invoice visibility improves and duplicate-payment exceptions decline. The first close using the new process takes longer because users are learning the system, but subsequent closes are faster. Internal audit confirms that approval evidence and access reviews are stronger than under the former process.

Learning Points

The case demonstrates that successful implementation depends on process analysis, data quality, control design, vendor governance, testing and user participation. Cloud adoption does not transfer all accountability to the provider, and standardisation may be preferable to costly customisation.

12. Ethical, Regulatory and Contemporary Issues

AIS projects process information that may be financially sensitive or personally identifiable. Ethical governance requires confidentiality, integrity, availability, fairness and accountability. Organisations should collect only necessary data, restrict access, retain records for legitimate purposes and dispose of information securely.

Regulatory obligations may concern financial reporting, taxation, electronic records, privacy, cybersecurity, outsourcing and data localisation. Responsibilities should be allocated explicitly between the organisation and its service providers. Internal and external auditors may require evidence of approvals, testing, access reviews, reconciliations and change control.

Artificial intelligence is increasingly used for invoice extraction, anomaly detection, forecasting and conversational assistance. These tools may improve efficiency but introduce risks of inaccurate classification, biased outputs, opaque decisions, unauthorised disclosure and overreliance. AI-generated entries or recommendations should be subject to human review, appropriate validation, audit logging and clear accountability. An AI tool should not be treated as an autonomous substitute for accounting judgement or control ownership.

Contemporary best practice emphasises secure-by-design development, privacy by design, automated testing, continuous monitoring, resilient architecture, identity-centric security and measurable benefits realisation. Nevertheless, automation does not remove the need for reconciliations, review, segregation of duties and professional scepticism.

Chapter Summary

The SDLC provides a disciplined framework for developing, acquiring and maintaining accounting information systems. Effective projects begin with a well-defined business problem and proceed through requirements analysis, feasibility assessment, design, development or configuration, testing, implementation and maintenance. Requirements must be specific, prioritised and testable, with traceability from business needs to design and test evidence.

Organisations may build, buy, outsource or use cloud services. Each option involves trade-offs involving control, cost, speed, capability, integration, security and vendor dependence. System design must incorporate accounting processes, data quality, access controls, audit trails, segregation of duties, continuity and reporting requirements.

Testing should cover components, interfaces, complete processes, security, performance, regression and user acceptance. Conversion requires data cleansing, mapping, reconciliation and a carefully selected cutover strategy. Documentation and formal change control preserve reliability after implementation. Finally, communication, training, sponsorship, user involvement and support are essential to adoption. Successful AIS change is therefore both a technical and an organisational achievement.

Key Terms

SDLC: A structured framework for planning, developing, implementing and maintaining information systems.

Requirements analysis: The process of identifying, documenting and validating what a system must do.

Functional requirement: A statement describing a system capability or behaviour.

Non-functional requirement: A statement describing quality, constraint or operating condition.

Feasibility analysis: Evaluation of whether a proposed system is practical and worthwhile.

Logical design: Description of system processes, data and controls independent of specific technology.

Physical design: Specification of the technology and implementation architecture.

Packaged software: Commercial software developed for use by multiple organisations.

Outsourcing: Obtaining selected services or capabilities from an external provider.

SaaS: Software delivered and operated as a service by a cloud provider.

Data migration: Transfer and transformation of data from one system to another.

Direct conversion: Immediate replacement of the old system by the new system.

Parallel conversion: Operation of old and new systems simultaneously for a period.

Pilot conversion: Initial implementation in a limited organisational area.

User acceptance testing: Formal evaluation by business users of operational fitness.

Regression testing: Testing to ensure that changes have not damaged existing functions.

Change control: Formal evaluation, approval, testing and recording of system changes.

Segregation of duties: Dividing responsibilities so that one person cannot control incompatible activities.

Traceability matrix: A record linking requirements to design elements, tests and approvals.

Review Questions

5 Short Answer Questions

1. What is the purpose of the systems development life cycle?
2. Distinguish between a functional and a non-functional requirement.
3. Identify four dimensions of feasibility analysis.
4. What is the difference between logical and physical design?
5. Why is user acceptance testing important in an AIS project?

5 Long Answer Questions

1. Explain the major SDLC stages and discuss why governance gates are important.
2. Compare building, buying, outsourcing and adopting a SaaS solution for an accounting system.
3. Explain how data migration should be planned and controlled during implementation.
4. Discuss the role of internal controls in requirements analysis and system design.
5. Explain corrective, adaptive, perfective and preventive maintenance, giving an example of each.

3 Analytical / Application Questions

1. A medium-sized manufacturer is considering replacing its payroll system with a cloud service. Analyse the technical, economic, operational, legal and schedule feasibility issues it should investigate.
2. An organisation plans to use direct conversion for a high-volume billing system. Evaluate the risks and recommend an alternative or safeguards.
3. A new invoice-processing system is technically successful but users continue to maintain unofficial spreadsheets. Diagnose the likely causes and propose a change-management plan.

Multiple Choice Questions with Answers

Question 1

Which SDLC stage primarily identifies and documents what users and the organisation require from a system?

A. Requirements analysis

B. Conversion

C. Maintenance

D. Production monitoring

Correct Answer: A. Requirements analysis

Question 2

Which is a non-functional requirement?

A. The system must create a supplier invoice

B. The system must match an invoice to a purchase order

C. The system must require multi-factor authentication

D. The system must calculate sales tax

Correct Answer: C. The system must require multi-factor authentication

Question 3

Which conversion strategy operates the old and new systems at the same time?

A. Direct conversion

B. Parallel conversion

C. Pilot conversion

D. Phased conversion

Correct Answer: B. Parallel conversion

Question 4

What is the main purpose of user acceptance testing?

A. To compile source code

B. To determine whether business users consider the system fit for use

C. To select a cloud provider

D. To cleanse supplier data

Correct Answer: B. To determine whether business users consider the system fit for use

Question 5

Which option generally provides the greatest control over highly distinctive functionality but requires substantial internal capability?

A. In-house development

B. SaaS subscription

C. Unmodified packaged software

D. Outsourced processing

Correct Answer: A. In-house development

Question 6

Which activity is most directly associated with data migration?

A. Mapping legacy account codes to the new system

B. Writing the project charter

C. Conducting a staff satisfaction survey

D. Setting annual sales targets

Correct Answer: A. Mapping legacy account codes to the new system

Question 7

A change that modifies an accounting system to comply with a new tax law is best classified as what type of maintenance?

A. Corrective

B. Adaptive

C. Perfective

D. Preventive

Correct Answer: B. Adaptive

Question 8

Which control principle helps prevent one employee from creating a supplier and approving payment to that supplier?

A. Data compression

B. Segregation of duties

C. Parallel conversion

D. Regression testing

Correct Answer: B. Segregation of duties

Question 9

Which statement about cloud SaaS is most accurate?

A. The customer has no responsibility for access controls

B. Cloud services eliminate all business-continuity risks

C. The provider operates much of the service, but the customer retains important governance responsibilities

D. SaaS cannot be integrated with other systems

Correct Answer: C. The provider operates much of the service, but the customer retains important governance responsibilities

Question 10

What is the primary value of a requirements traceability matrix?

A. It links requirements to design, testing and approval evidence

B. It calculates depreciation automatically

C. It replaces user training

D. It guarantees that a project will be delivered on time

Correct Answer: A. It links requirements to design, testing and approval evidence