I'm working on my final-year project report and have had to create the usual UML documentation: use-case diagrams, class diagrams, and sequence diagrams for the main workflows. The part I'm struggling with is figuring out how to judge whether my diagrams are actually correct.
The application's behavior and requirements are fixed, but UML gives you several valid ways to represent the same system. Two people could model the same requirements with different class structures, actor groupings, or relationships, and both designs might still be reasonable. When a jury reviews the report, are they looking for one specific modeling solution, or are they mainly checking that the diagrams are consistent and show a sound understanding of the application?
For context, my report follows a sprint-based structure. Each sprint has its own objective and backlog, and we're expected to include updated use-case, class, and sometimes sequence diagrams for that sprint. This can result in many diagrams across the report—one example I found had six sprints and around 57 figures. Since the diagrams are effectively smaller views of the system at different stages, I'm also wondering how strict the expected correctness is for each individual sprint.
For anyone who has gone through an academic defense, code review, or a similar process: how do you validate diagrams when there is no single reference model to compare them with?
3 Answers
Try linking every element in the diagrams to something concrete: a requirement, a backlog item, a sprint objective, or a technical constraint. A use case should represent a meaningful user goal, classes should support the responsibilities in the design, and sequence diagrams should match the actual flow implemented in the code. That turns the diagrams into documentation of your decisions instead of decorative figures.
Focus on being able to defend each modeling choice. If someone asks why two classes are associated, why an actor is connected to a use case, or why a responsibility belongs to one class instead of another, you should have a clear requirement or design principle to point to. Different models can be valid, but unexplained contradictions, outdated diagrams, and relationships that do not match the application are much harder to justify.
In my experience, juries care more about the reasoning behind the diagram than about matching one supposedly perfect version. The important things are that the model is internally consistent, reflects the requirements, and agrees with the code or architecture you actually built. Be ready to explain why you chose a particular class, relationship, actor, or flow. They’re usually evaluating your understanding and design decisions, not hunting for one exact arrangement.
That makes sense. So the explanation and consistency between the diagrams, implementation, and requirements matter more than reproducing a reference diagram.