I'm working on my final-year project report, which is a major project at the end of my university program, and I've had to create the usual UML documentation: use-case diagrams, class diagrams, and sequence diagrams for the main workflows.
The application's overall logic is fixed, so I understand what the system is supposed to do. The confusing part is deciding whether the visual model is actually "correct." There can be several reasonable ways to represent the same requirements. Two people might choose different class structures or group use cases differently, and neither design would necessarily be wrong.
When a jury reviews these diagrams, are they looking for one specific answer, or are they mainly checking that the models are internally consistent and show a reasonable understanding of the system? How can you validate a diagram when there is no single ground truth to compare it with?
For context, my report is organized around development sprints. Each sprint has its own objective and backlog, and I'm expected to create updated use-case, class, and sometimes sequence diagrams for that sprint. In a report with six sprints, this can result in dozens of diagrams, many of which represent smaller versions of the same system. That repetition is part of why I'm unsure how strict the correctness criteria are for each individual diagram.
3 Answers
Try connecting every important class, use case, and relationship to a backlog item, requirement, or technical constraint from the sprint. That turns the diagrams into documentation of actual design decisions instead of isolated illustrations. If a reviewer can trace a diagram element back to something the system needs to do, it becomes much easier to justify.
Focus on being able to defend each modeling choice. If someone asks why an actor, class, or relationship exists, you should be able to point to a requirement or explain the design reason. Also check that the diagrams agree with the implemented code and with one another; internal consistency is often a more realistic standard than trying to find one universal UML solution.
In my experience, juries care more about the reasoning behind a diagram than about matching one supposedly perfect structure. Keep the diagrams consistent with the requirements and with each other, and be ready to explain why you modeled something that way. They’re usually evaluating your understanding and design decisions, not searching for a single officially correct answer.
Exactly. The explanation behind the model usually matters much more than whether someone else would have drawn the same relationships or grouped the same use cases differently.