From Software Requirements to a Useful UML Use Case Diagram

Plan an accurate use case diagram for a student resource portal by identifying actors, goals, system boundaries and assumptions.

A UML use case diagram is a short map of what different users need the system to do. It is not a screen design or a database diagram. This guide uses an educational resource portal to explain actors, goals, boundaries and common modelling mistakes.

Define a narrow system boundary

Assume the system is a study resource portal with public files and a restricted administration area. Draw a rectangle labelled Study Resource Portal. Only activities supplied by that system belong inside it.

Avoid placing external processes such as 'student studies at home' inside the boundary. That activity may be the reason for the system, but it is not itself a software service the system performs.

Identify actors and user goals

Actors represent roles that interact with the system, not individual names. For this example, a Visitor can browse resources; a Registered Student can bookmark a resource; and an Administrator can publish a resource.

Turn each goal into an action-oriented use case. Prefer 'Search resources' and 'Publish resource' over vague nouns like 'Search' or technical implementation labels such as 'Run SQL'.

• Visitor — browse public resources, view a resource.
• Registered Student — sign in, save a bookmark.
• Administrator — review and publish resources.
• External identity provider — include only if authentication interaction is part of scope.

Use include and extend carefully

An include relationship describes behaviour that is always reused by a use case. An extend relationship describes optional or conditional behaviour. Many introductory diagrams are clearer without either relationship.

Do not add include arrows just because two screens share a button. Describe the actual required behaviour first. If the diagram is getting complicated, create a text use case specification showing triggers, preconditions, main flow and alternate paths.

Validate the diagram against scenarios

Walk through a visitor opening a free paper without logging in. If your diagram requires 'Sign in' for all resource access, it contradicts the agreed requirement and should be corrected.

Then test an admin publishing a file and a student bookmarking it. Check that every use case connects to an actor who gains value, and that each goal can be verified with a functional test.

Quick checklist

• The system boundary has a meaningful name.
• Actors represent roles, not actual people.
• Use cases describe observable goals.
• No unrelated business activity appears inside the boundary.
• Include/extend arrows have a justified meaning.
• The diagram supports a written, testable scenario.

Always confirm current syllabus, coursework and assessment rules with your institute or lecturer.