Systems Development and Agile

Systems Development and Agile

Every information system must be designed, built, and deployed. The process by which this happens — the systems development lifecycle (SDLC) — is one of the most critical disciplines in information systems management. How organisations approach development profoundly affects whether systems succeed, how much they cost, and how well they meet business needs. This lecture covers the traditional waterfall SDLC and the Agile approach that has transformed software development practice.

Why Systems Development Matters

Building information systems is complex, expensive, and risky. Common failure modes include:

• Systems that do not meet user needs because requirements were poorly understood
• Projects that run significantly over time and budget
• Systems that work technically but are not adopted by users
• Changes to requirements discovered late in development when they are expensive to accommodate

Structured development methods exist to reduce these risks by providing a disciplined framework for planning, building, and delivering systems.

The Traditional Waterfall SDLC

The traditional waterfall model organises systems development into six sequential phases, each of which must be substantially complete before the next begins (hence "waterfall" — work flows downward, not backward):

1. Planning — define the problem, assess feasibility (technical, financial, operational), identify stakeholders, develop project plan and resource allocation. Key output: project charter and feasibility study.
2. Systems Analysis — conduct detailed analysis of current systems and processes; gather and document requirements from stakeholders; understand what the new system must do. Key output: requirements specification.
3. Systems Design — translate requirements into a detailed technical blueprint: database design, user interface design, system architecture, integration design, security design. Key output: systems design document.
4. Systems Development (Build) — write the code and configure the system according to the design; create databases; develop interfaces. This is where the system is actually built.
5. Testing — systematically test the system against requirements: unit testing (individual components), integration testing (components working together), user acceptance testing (UAT — business users verify the system meets their needs). Defects are identified and corrected.
6. Implementation (Deployment) — roll out the system to production; train users; migrate data from old systems; go live. This phase also includes post-implementation review and ongoing maintenance.

Requirements: Functional and Non-Functional

A critical phase of the SDLC is requirements gathering. Requirements fall into two categories:

• Functional requirements — describe what the system must do; specific behaviours and functions the system must perform. Examples: the system must generate a daily transaction report; the system must allow users to reset their passwords; the system must display customer order history.
• Non-functional requirements — describe how the system must perform; quality attributes and constraints. Examples: the system must process 500 transactions per second; the system must be available 99.9% of the time; the system must comply with Australian Privacy Principles; the system must encrypt all stored passwords.

Both types of requirements are essential. A system that does what it is supposed to do (functional) but is too slow to use (non-functional) has failed to meet requirements.

Strengths and Weaknesses of the Waterfall Model

Strengths:

• Clear structure and milestones — easy to track progress and manage the project
• Comprehensive documentation — the system is well-documented, supporting future maintenance
• Appropriate for stable, well-understood requirements — works well when what needs to be built is clear from the start

Weaknesses:

• Inflexibility — requirements discovered to be wrong late in the cycle are very expensive to change; the waterfall does not flow back uphill easily
• Late delivery of value — users do not see working software until near the end of the project
• Requirements instability risk — in many real projects, requirements are not fully known at the start and change as the project proceeds
• User involvement limited — users are heavily engaged at requirements and UAT phases, but largely absent in between, increasing misalignment risk

The Agile Approach

Agile development was created by practitioners frustrated with excessive planning, documentation, and bureaucracy in traditional SDLC approaches. In 2001, a group of software developers articulated the Agile Manifesto, which states four core values:

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following the plan

The Agile Manifesto does not reject planning, documentation, tools, or contracts — it places higher value on the items on the left.

Agile in Practice: Sprints and Iterative Development

Agile organises work into short, time-boxed cycles called sprints or iterations, typically 2–4 weeks long. At the end of each sprint, a piece of working software is delivered and demonstrated. This approach enables:

• Frequent delivery of working software — users see value early and often
• Continuous feedback — stakeholders review working software each sprint and provide input that shapes subsequent development
• Adaptability — requirements can change between sprints without disrupting the entire project
• Early detection of problems — issues are discovered in small increments, not at the end of a year-long project

Waterfall vs Agile: When to Use Each

Neither approach is universally superior. Waterfall is most appropriate when requirements are stable and well-defined upfront, the project is large and complex with many dependencies, regulatory compliance requires comprehensive documentation, or the client relationship is contract-based with fixed scope. Agile is most appropriate when requirements are complex and likely to change, early delivery of value is important, the team and customer can work collaboratively and continuously, or the project is innovative with significant uncertainty.