So I'm designing an Education Management System and I'm wondering if I should be creating the Use Cases or the Class Diagrams first?
- Anybody can ask a question
- Anybody can answer
- The best answers are voted up and rise to the top
You should be first defining how the tool you are creating is going to look, feel, and be used by your users/customers. That is what dictates how your software will be architected.
People use your software, not computers, so design how people will interact with it first. If you design around how software components should fit together, your user interface will be made for robots, not human beings.
Always create Use Cases first. However the detail with which use-cases are worked out depends on your familiarity/comfort with the domain, if you have worked within the domain before initially you can keep your use-cases brief and expand it later on along with the development.
Actually, Jim Coplien advises not to dive into the Use Case diagrams too soon, but rather to first find out the simplest mental model for the domain.
For if your system thinks about the domain in different terms and concepts than its users, they'll have trouble understanding each other. And if your domain model is solid, it will be easier to implement changing requirements on top of it.
So I think the answer is: That depends on what you're planning to put in those Use Case and Class diagrams.
I'd start thinking about classes for the domain model. Talk with people who currently are working in this domain, find out in which terms they think and talk about education. Once you understand the domain, think about the Use Cases. Then as you start implementing technical stuff, think about the classes and objects that you'll use to implement this.
Don't be shy to produce code rather than diagrams all along. A picture is nice, but compiling and running code is a lot more concrete. So classes that model your domain are a good first and reusable artefact, even better than a class diagram.