- ✓Traditional structured methodologies like SSADM use a highly documented, plan-driven approach that prioritises completeness before implementation begins.
- ✓Agile systems analysis is iterative and incremental, refining requirements continuously through stakeholder collaboration and working software.
- ✓The choice between traditional and agile approaches depends on factors including project size, requirements volatility, and organisational culture.
- ✓Hybrid approaches that combine the upfront planning of traditional methods with the flexibility of agile are increasingly common in enterprise projects.
- ✓No methodology is inherently superior; a systems analyst's value lies in their ability to select and adapt approaches intelligently to specific contexts.
Listen to the full episode inside the course. Enrol to access all 80 episodes, plus assignments, tutor support and Student Finance funding.
Start learning →Alex: We're starting Unit 11: Systems Analysis and Design today. First lesson is comparing traditional and agile methodologies. Sam, we touched on this in Unit 7, but at Level 5 we're going deeper, right?
Sam: Much deeper. At Level 5, the expectation is that you can evaluate these methodologies critically: understand their underlying assumptions, assess their strengths and limitations with evidence and examples, and make well-reasoned judgements about when each is appropriate. It's not just describing what they are; it's analysing them.
Alex: Let's start with the traditional structured approach. What's its foundational philosophy?
Sam: Traditional structured methodologies, with SSADM being the prime UK example, are rooted in the assumption that requirements can be fully and accurately specified upfront, and that a carefully planned, sequential development process is the most reliable way to build a system that meets those requirements. Every phase produces comprehensive documentation that serves as the foundation for the next phase. The emphasis is on completeness, rigour, and control.
Alex: What are the genuine strengths of that approach?
Sam: For certain types of projects, those strengths are very real. When requirements are truly stable and well-understood, and when the cost of getting something wrong is very high, the thorough upfront analysis and documentation of structured approaches provides a level of rigour that agile methods struggle to match. Large infrastructure projects, safety-critical systems, and government IT projects with strict procurement and accountability requirements all benefit from the clarity and auditability of structured approaches.
Alex: And the limitations?
Sam: The assumption that requirements can be fully specified upfront is frequently wrong. Users often don't know what they want until they see something, and business contexts change during development. In a Waterfall project, discovering late that a key requirement was misunderstood is extremely costly to address. The extensive documentation required can also become an end in itself, consuming resources without adding proportionate value.
Alex: What does agile systems analysis look like in contrast?
Sam: Agile systems analysis is iterative and collaborative. Rather than trying to specify all requirements upfront, you work with stakeholders continuously throughout the project, refining understanding as you go. User stories capture requirements in a lightweight format that focuses on user needs and business value. The system evolves through successive iterations, with each iteration delivering working functionality that stakeholders can review and provide feedback on.
Alex: What are the strengths of the agile approach?
Sam: Flexibility and responsiveness. When requirements change, and they usually do, agile teams can incorporate those changes in the next iteration without the extensive rework that a waterfall project would require. Working software delivered early gives stakeholders something tangible to evaluate, which generates better feedback than reviewing documentation. And the continuous collaboration between business and development reduces the risk of building the wrong thing.
Alex: And limitations of agile?
Sam: Agile can struggle when a fixed price and scope are contractually required, when stakeholders can't dedicate time to active collaboration, or when the project requires comprehensive upfront documentation for regulatory purposes. It also requires significant discipline to maintain quality in an iterative environment; cutting corners on testing or design to meet sprint commitments can create technical debt that slows future development.
Alex: Thanks Sam. Next we look at producing a systems feasibility study.