How much should I worry about the analysis phase or writing UML diagrams or ER diagrams for it? And what should be the flow on that? What should I start drawing?
Analysis of requirements is very important to get acceptance of the final product. Not understanding requirements or understanding vague requirements does not lead to faster applications. Instead, this generally leads to delivering the wrong product fast. Look at this inequality:
Cost(Analysis + Implementation + Testing) ? Cost(Analysis + Implementation + Testing) + Cost(Analysis + Implementation + Testing) +...
I argue that the "?" is "<". Even if you replace the Cost with "Quality" or "Customer Confidence". This is based on my own experience.
Some people understand iterative development as deliver something and fix it later, but this does not work well in general. This is especially true with the complex software engineering cycle that today's software has to go through.
The idea behind UML and ER diagrams in general are mainly:
1-To make you think deeply about the problem without too much syntax, code, etc.
2-To make you document what you think precisely.
3-To make others understand precisely what you think, so that knowledge is shared.
4-To produce code when possible from the diagrams.
5-Get/Give a feel of the application complexity, so that project/cycle planning can be accurate.
If you have not practiced use case diagrams, class diagrams, ER diagrams, etc. you will be surprised how many questions will arise when you try to model. Some of these questions should be answered by the customers or the users of the application and if you don't ask those there is a good chance that you will deliver less than a perfect product. The other set of questions will turn into design decisions that you will make in a code-less environment.
One of the classical funny, yet close to reality, diagrams that shows the value of requirements is here.
In summary, diagrams (and requirements specifications in general) are not just pretty pictures and in most cases, they are not a waste of time. In most cases, customers may not think high of you if you deliver the wrong product. If your application is not trivial, consider modeling as a serious activity.
As for the 2nd part of your question, the order of producing diagrams depends on whether you are going to use Pure OO approach or Mixed OO and Relational approach where a class represents a physical table. In a design leaning towards an OO approach a Class diagram is required. In the later case, you can build an ER diagram, and depending on your toolset, derive the Class Diagram from the database and possible generate the ORM code.