Is it a good choice to start a project with Diagram Use Cases, then Class Diagram?

This response is based entirely on my opinion .

Diagrams is a very old management mode / specification / documentation.

Search to document your requests via User Stories . They are simpler to create, and after interpreting to develop.

Example of a User Story :

  

    

HOW a site visitor

         

WHEN I'm on the homepage of the site

         

I click on the "Register" link

         

THEN a registration form should open.

  

     

Form data: full name, email, and password.

Each user story has a type. Ex:

• Feature : New feature or change;
• Bug : Fix something implemented;
• Epic : Requires other user stories to be created to fulfill this desire.
• Tech : Changes proposed by developers that do not affect the business. How to update Nuget Packages, create tracking for Application Insights, etc.

They have phases:

• Icebox : They were only created in order to be analyzed in the future - which may be soon, in years or never. The idea is to never stop writing an idea and lose something ..
• Backlog : The story will be yes deployed and queued to be developed
• Finished : The story has already been developed or has been aborted.

Important : These phases do not necessarily reflect the phases of software development. Commonly yes, they reflect, but it is not the case of my example. It is common to see phases such as "Started", "Finished", "In tests", "Approved for production", etc.

And they have "Complexity Points" or "Effort Points". This should follow the Fibonacci Sequence :

• 1 pt : Only correction of typing, change of texts. It does not involve code changes.
• 2 pts : Minor code or screen changes. Nothing that changes business rules, criticality or specific tests.
• 3 pts : Regular effort how to create a new simple feature, screens, etc. It is the most common.
• 5 pts : Great effort, will touch on various points of the system, change big business rules, affect tests or integration with other systems.
• 8 pts : Epico. This story should be broken into yet simpler stories.

You can go further. There are strategies that go beyond 21 pts. I do not recommend it, it gets vague and difficult to understand what is 5pts and what is 8pts. But it's about your strategy and how your team feels comfortable.

These points have nothing to do with "hours of development" - which to me is also "old school," an obsolete way of managing project demand. Think like this: What is the complexity of sweeping a floor? It's very low, sweeping is simple. And what changes from sweeping a bathroom rug to a parking lot? The complexity is the same.

There are several systems to help you manage these stories.

• Visual Studio Team Services : Free up to 5 developers, also provides Git repository and Build & Release.
• Trello : Simple system of Kanban , free .
• Pivotal Tracker : Paid but excellent User Stories management system.

PS : I think your question will be closed because it is opinion.