- ✓UML (Unified Modelling Language) is a standardised visual language for describing the structure and behaviour of software systems, providing a common vocabulary that both technical and non-technical stakeholders can engage with.
- ✓Use case diagrams model the interactions between users (actors) and a system, capturing what the system must do without specifying how it will do it, and are particularly valuable in requirements gathering and stakeholder communication.
- ✓User stories are brief, informal descriptions of a feature from the perspective of an end user (typically in the format 'As a [user type], I want [an action] so that [a benefit]') that keep the focus on user value rather than technical implementation.
- ✓Sequence diagrams model how objects interact over time to accomplish a specific function, making them particularly useful for designing and communicating complex workflows and multi-system integrations.
- ✓Combining different behavioural design techniques, using use cases and user stories to capture requirements and UML diagrams to model the proposed solution, produces a much richer and more robust design than any single technique alone.
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: Welcome back to The Study Podcast. Today we're looking at behavioural design techniques in software development: UML, use cases and user stories. Sam, these are the tools that bridge the gap between requirements and implementation, aren't they?
Sam: Exactly. They're how you represent what a system needs to do in a way that's precise enough to guide development but accessible enough for non-technical stakeholders to understand and validate. Getting this translation right is one of the most valuable skills in software development, and it's consistently undervalued.
Alex: Let's start with UML. What is it and what is it used for?
Sam: UML, the Unified Modelling Language, is a standardised visual notation for modelling software systems. It's not a programming language or a development process: it's a set of diagram types that each capture a different aspect of a system's structure or behaviour. There are fourteen diagram types in the full UML specification, but in practice a handful are used regularly: use case diagrams, class diagrams, sequence diagrams and activity diagrams are the most common.
Alex: What does a use case diagram capture?
Sam: A use case diagram shows the interactions between users, called actors, and the system. Each use case is a specific goal that an actor wants to achieve using the system: 'place an order', 'view account balance', 'reset password'. The diagram shows which actors are involved in which use cases and how use cases relate to each other. It's particularly useful in the requirements gathering phase because it focuses attention on what users need to accomplish rather than how the system will work internally.
Alex: And a sequence diagram is different because it shows the order of interactions?
Sam: Yes. A sequence diagram shows how objects or components interact over time to accomplish a specific function. It has a vertical time axis and shows messages passing between actors and system components in chronological order. It's very useful for designing and communicating complex workflows, API interactions and multi-system integrations, because it makes the sequence and timing of messages explicit in a way that a prose description cannot.
Alex: User stories are a more Agile-oriented approach to capturing requirements, aren't they?
Sam: Yes, and they're quite deliberately informal compared to use cases. The typical format is: 'As a [type of user], I want [to take some action] so that [I achieve some goal or benefit].' The format keeps the focus on user value rather than system behaviour, which is intentional. The 'so that' clause is particularly important: it articulates why the user wants this capability, which helps the development team make better decisions about how to implement it.
Alex: What are acceptance criteria and how do they relate to user stories?
Sam: Acceptance criteria define the specific conditions that must be met for a user story to be considered complete. They're typically written as 'given, when, then' statements: 'given a user is logged in, when they click the download button, then a PDF is generated and downloaded within five seconds'. They translate the user story from a business requirement into something that can be tested, which is essential for both development and quality assurance.
Alex: Really valuable practical knowledge for the assessment. Thanks, Sam. We'll wrap up Unit 7 in the next lesson.