Systems are not built in one step. They go through stages from first idea to retirement, and good documentation travels with them. This lesson covers the system development life cycle (SDLC) and the documents that support it.

Stages of the life cycle

A typical SDLC has these stages.

  • Analysis: understand the problem, gather requirements, study the existing system and produce a requirements specification.
  • Design: plan how the system will meet the requirements. This includes data structures, algorithms, screen layouts, hardware choices and test plans.
  • Implementation: build the system by writing and assembling the code, then install it.
  • Testing: check that the system works and meets the requirements.
  • Deployment: put the system into use (see the installation methods lesson).
  • Maintenance / evaluation: fix faults, adapt and improve, and judge whether the system achieved its goals.

Development models

  • Waterfall: stages follow one after another. Clear and well documented, but changes late in the project are expensive.
  • Iterative / agile: the system is built in short cycles. Working versions are delivered often and requirements can change along the way. Better when requirements are uncertain, but needs close, continuous user involvement.
  • Prototyping: an early working model is built so users can react to it. It reduces the risk of building the wrong thing.

Example: a team making a mobile game might use agile sprints to test ideas with players, while a team building flight-control software might favour a more formal, documented approach.

Documentation

Documentation records what a system is, how it works and how to use it. Types include:

  • User documentation: manuals, quick-start guides and help pages for end users.
  • Technical documentation: system specifications, diagrams, code comments and data dictionaries for developers and administrators.
  • Design documents: flowcharts, data flow diagrams, entity relationship diagrams and screen mock-ups.
  • Test documentation: test plans, test data and results.

Why it matters: documentation allows new staff to take over a system, makes maintenance faster and supports training. Without it, knowledge lives only in people’s heads and is lost when they leave.

Check your understanding

In which stage are requirements gathered?

  • Analysis
  • Deployment
  • Maintenance
  • Testing

Answer: Analysis. Interviews, observation and questionnaires establish what the system must do.

What is a main weakness of the waterfall model?

  • It has no stages
  • Changes late in the project are expensive
  • It cannot be documented
  • It requires no testing

Answer: Changes late in the project are expensive. Earlier stages are complete and signed off.

Who is technical documentation mainly written for?

  • Casual end users
  • Developers and administrators
  • Advertisers
  • Customers’ friends

Answer: Developers and administrators. It explains how the system is built and maintained.

What is the purpose of a prototype?

  • To replace testing
  • To let users react to an early model before the full build
  • To delete data
  • To speed up the CPU

Answer: To let users react to an early model before the full build. This reduces the risk of building the wrong thing.

PreviousNext