SDLC Phases Overview

The life of a system

Building a system is like building a house. You decide whether it’s worth it, agree what rooms you need, draw the plans, build it, have it inspected, move in, and later check it’s what you wanted. Change your mind about where the kitchen goes while drawing the plans and it costs an eraser; change it after the walls are up and it costs a fortune.

The system development life cycle (SDLC) is that same sequence for software.

Feasibility, requirements, design, build, test, implement, post-implementation review.

Phase	Purpose	Key outputs and controls
Feasibility	Is it worth doing, and possible?	Business case, feasibility analysis, approval to go ahead
Requirements	What must the system do?	Functional and non-functional requirements, including security, control, audit trail and compliance needs; user sign-off
Design	How will it do it?	Architecture, data design, interfaces, controls design; design review
Build	Make it	Code to standards, peer review, unit testing, version control
Test	Does it work, and meet requirements?	Integration, system, security, performance and user acceptance testing; sign-off
Implement	Put it into use	Data conversion and reconciliation, training, cutover plan, go-live approval, rollback plan
Post-implementation review	Did it deliver?	Comparison with objectives and benefits; lessons learned

When software is bought rather than built, the path looks slightly different: requirements → request for proposal → vendor evaluation → contract → configuration → testing.

Build controls in early

The cost of fixing a missing control rises from requirements to design to build to after go-live.

Fixing a problem gets more expensive the later it’s found. A missing audit trail spotted in requirements is a line in a document. Spotted after go-live, it may mean redesigning database tables and interfaces. So:

control, security and audit requirements belong in the requirements phase
design reviews check those controls are specified before coding
the auditor’s involvement is most cost-effective early

Example. In a payments project, the auditor reviews the requirements and notices there’s no requirement for two people to approve large payments. Adding it now costs a few days of design. Found after go-live, it would need a change project and leave months of exposure.

Users throughout

Users define the requirements, take part in design reviews, do the acceptance testing, and formally accept the system. Weak user involvement is one of the most common reasons projects fail.

The auditor at each phase

Requirements: are control and security needs included and approved?
Design: are audit trails, input and processing controls, and access roles designed in?
Build and test: are standards followed, and is testing adequate?
Implementation: is data conversion controlled, and is go-live properly approved?
Post-implementation: were the objectives met?

The auditor advises and reviews; they don’t approve deliverables.

How the exam asks about it

If the question asks…	The answer is usually…
The most cost-effective phase to build in controls	Requirements definition / design
The phase where user involvement matters most	Requirements (and acceptance testing)
Risk if users don’t approve the requirements	The system won’t meet business needs
The phase that confirms benefits were achieved	Post-implementation review
Best time for the auditor to get involved	Early, from requirements onward

In short

A typical SDLC: feasibility, requirements, design, build, test, implement, and post-implementation review.
Controls and security should be built in from the requirements phase, because adding them later costs far more.
In traditional models each phase ends with a deliverable and an approval before the next starts.
User involvement matters most in requirements and acceptance testing.
The auditor reviews controls at each phase; getting involved early is most cost-effective.
Errors found in requirements cost far less to fix than errors found after go-live.

Exam traps

The cheapest time to build in controls and audit trails is the requirements and design phases.
Requirements without user sign-off are a major project risk.
Testing doesn't create quality; it confirms quality that was designed in.
The post-implementation review is part of the SDLC, not optional.

Slides

Click the slide and use the arrow keys. F toggles full screen.

If the question asks…	Answer
Cheapest phase to build in controls	Requirements / design
Phase where user involvement matters most	Requirements (and acceptance testing)
Risk if users don't approve requirements	The system won't meet business needs
Phase that checks benefits were achieved	Post-implementation review
Best time for the auditor to get involved	Early, from requirements