Systems Development, Acquisition and Change Management
Build, buy or configure
Systems development covers how an organisation conceives, builds or acquires a system and then changes it safely. Candidates should know the life cycle stages, the main delivery approaches, and the controls that keep change from breaking production.
Concepts to master
- Life cycle: feasibility, requirements, design, build or configure, test, implement, operate, retire. Each stage has entry and exit criteria and deliverables.
- Approaches: waterfall (sequential, heavy documentation), agile (iterative increments, product owner, backlog), hybrid, and commercial off-the-shelf configuration. Low-code platforms trade speed for governance risk.
- Requirements: functional versus non-functional (performance, availability, security, usability); traceability from requirement to test.
- Testing levels: unit, integration, system, user acceptance, regression, and non-functional testing such as load and penetration testing.
- Change management controls: request logging, impact and risk assessment, approval by the right authority, segregation between developer and production access, testing evidence, back-out plan, post-implementation review.
- Acquisition: requirements-based evaluation, vendor due diligence, contract terms on service levels, data ownership and exit.
- Data migration: cleansing, mapping, reconciliation and cut-over planning.
Traps in questions
- Confusing user acceptance testing (business fitness for purpose) with system testing (technical correctness).
- Allowing emergency changes to bypass approval entirely; they may be fast-tracked but must be retrospectively reviewed.
- Assuming agile means no documentation or controls; it changes form, not the need for evidence.
- Overlooking non-functional requirements until go-live, when they are expensive to fix.
Worked rule of thumb
For any change question, apply separate, approve, test, back out. Developers must not promote their own code to production; approval must come from someone accountable for the business risk; a tested back-out plan must exist; and the change record must close with a post-implementation review.