- ✓SSADM, Structured Systems Analysis and Design Method, was developed for UK government IT projects and remains one of the most comprehensive traditional methodologies.
- ✓SSADM uses three key techniques: Logical Data Modelling, Data Flow Diagrams, and Entity Life Histories to model different aspects of a system.
- ✓DSDM, Dynamic Systems Development Method, is a framework for agile project delivery that emphasises collaboration, iterative development, and business focus.
- ✓Understanding established methodologies, even older ones, provides valuable context for understanding how current approaches evolved and what problems they were designed to solve.
- ✓Professional systems analysts are expected to justify their methodology choices rather than defaulting to whichever approach they find most familiar.
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: Today we're examining specific systems analysis methodologies in depth. Sam, let's start with SSADM.
Sam: SSADM stands for Structured Systems Analysis and Design Method, and it was developed in the 1980s specifically for UK government IT projects. It's a comprehensive, tightly defined methodology with a specific set of stages, steps, and techniques. The three central techniques are Logical Data Modelling, which is essentially entity-relationship modelling; Data Flow Diagrams, which model how data moves through the system; and Entity Life Histories, which model how entities change state over time in response to events.
Alex: When would SSADM be appropriate today?
Sam: SSADM in its full form is rarely used today outside of very specific government and regulated industry contexts. However, studying it is genuinely valuable because it provides deep insight into what a comprehensive, rigorous systems analysis process looks like. The individual techniques it uses, particularly data flow diagrams and entity life histories, are still used selectively within more modern methodologies. Understanding SSADM contextualises the development of later approaches.
Alex: What about DSDM?
Sam: DSDM, which stands for Dynamic Systems Development Method, emerged in the 1990s as a response to the perceived inflexibility of traditional approaches. It's an agile framework with a strong focus on business value and delivery within fixed timescales. DSDM places the business at the centre of the project, with strong emphasis on business involvement throughout and on delivering products that meet prioritised requirements within the available time and budget.
Alex: How does DSDM handle the tension between fixed requirements and agile flexibility?
Sam: Through what it calls the MoSCoW prioritisation technique: Must have, Should have, Could have, and Won't have this time. Requirements are categorised into these groups, and the team commits to delivering all the Must haves within the fixed timescale. If time pressure mounts, the Should haves and Could haves can be deferred to future iterations. This allows the timescale and budget to be fixed while retaining flexibility over scope.
Alex: Are there other methodologies worth knowing at this level?
Sam: Soft Systems Methodology, or SSM, is valuable for situations where the problem itself is not well-defined: where there are conflicting perspectives on what the system should do and why. Developed by Peter Checkland, SSM uses rich pictures and conceptual models to help stakeholders explore their different perceptions of a problem before moving to solutions. It's particularly useful for complex organisational change projects where technology is just one part of the solution.
Alex: How do you choose between these approaches in practice?
Sam: By understanding their underlying assumptions and matching them to the characteristics of your situation. SSADM suits stable, well-defined requirements and regulatory contexts. DSDM suits business-critical projects where delivery within a fixed timescale is paramount. SSM suits ill-defined, complex, organisational problems. And most real projects require elements from multiple approaches, which is why having broad methodological knowledge is more valuable than being expert in just one.
Alex: Excellent. Thanks Sam. Next we look at designing systems to meet requirements.