Use-cases are the description of the problem to solve, therefore, they must come before any other step in the process.

I’d argue that it’s not possible to make anything meaningful without knowing the problem.

Use-cases will then determine what you design, whether you make class diagrams before writing any code, however, is personal preference.

You “forgot” to mention it, but I assume you are talking about gathering requirements for a new software by using UML, right?

I think the first step in this should always be to understand the use cases (and I am not talking about fancy use case diagram, I am talking about the business process of your users, what they are doing and how the new software shall be integrated into their work). You can do this by interviewing people, by observing them or by working with them.

To safe the result of this process you can try to incorporate use case diagrams, but these diagrams will provide only a very high level abstraction of what you have learned in the step before. So you will have to add a more detailed description to any use case. This description can make use of other tools:

• verbal description of the processes in natural language
• example scenarios (also called “user stories”)
• class diagrams for modeling business entities and the data on a very detailed level
• class diagrams as a form of domain model like in “domain driven design”
• data flow diagrams (still missing in UML)
• UI drafts
• test cases
• other UML diagrams (though IMHO seldom really helpful)
• […]

So if your job is to model a high level overview of the system, you will probably create use case diagrams first, each one with a more or less small description. If you are going to flesh out the details of a certain use case, where the data to be processed is modeled down to the attribute level, you may start with only one use case and do a lot of detailed bottom-up modeling (maybe incorporating class diagrams as one of many tools) before you go to the next use case. So the order for modeling depends on what your assigned task is, and how big and complex the piece of software is you have to analyse.

Be aware that many software projects in the past have failed because they were completely overanalysed – hundreds of pages of specs created over months without building a line of code first (of course, other projects failed because they were not well analysed at all), so it is important to find the right balance. Be also aware that most software systems will be created release by release – so the task of gathering requirements for version 1.0 is only the first step. For version 2,3,4,5 you will typically have to describe only the additional requirements compared to the previous version. Often the set of use cases is mostly stable between releases, but the detailed differences between version n and n+1 are of interest. So the tools I listed above for the detailed use case description become typically more important than use case diagrams after version 1.0 is in production.

Use cases first is the right approach because tons of software engineers before us have found out already

I have not heard about people who prefer coding first (class diagrams) and think about it only afterwards (use cases) and still are able to produce non-trivial working software. On the contrary I have heard about many projects who failed completely, run out of budget etc. just because of that.

But maybe I have misunderstood the original intent of your question.

Some “cons of classes first” are: lessons learned, full size picture available as How Projects Really Work – http://www.projectcartoon.com

Some “pros of use cases first” are: because literature recommends it, e.g.

Scott W. Ambler in his online book “Agile Modeling” in chapter “Requirements Envisioning: An Agile Best Practice → What Should You Model Initially?” says:

For the first release of a system you need to take several days to identify some high-level requirements as well as the scope of the release (what you think the system should do). The goal is to get a good gut feel what the project is all about. For your initial requirements model my experience is that you need some form of:

• Usage model
• Domain model
• User interface model(s)

3.1 Usage Model

Usage models enable you to explore how users will work with your system, which is absolutely critical if you’re to understand what they need. Your usage model may be a collection of essential use cases or system use cases…

3.2 Domain Model

Part of your initial modeling efforts, particularly for a business application, will likely include the development of a conceptual domain model. This model should be very slim, capturing the main business entities and the relationships between them…your model doesn’t need to be complete, it just needs to cover enough information to make you comfortable with the primary business concepts…

3.3 User Interface Model(s)

The user interface (UI) is the portion of software with which a user directly interacts. For most stakeholders the UI is the system so it is crucial to the initial success of your project to ensure that you understand what stakeholders expect of the UI. One way to explore the requirements for the UI is to create what are called essential UI prototypes, also known as an abstract prototypes or paper prototypes…