I think yes. You need to know all parts involved in the development. The database schema, how many tables you need, the relations, the fields, the type of every field. About the programming instead, you have to know what classes, interfaces, abstracts. How relate to each other, the vendor classes you need, the user cases.

Analysis is so important because a good analysis becomes to less painfully development, and in the initial point less changes for the first version of your application.

You need to understand exactly what problem you are trying to solve. In that sense, analysis is really important. But analysis for months and attempting to come up with a full set of requirements and a complete design of the final product, will be detrimental to the project. Making a minimum viable product and iterating over it is a lot more important. However, understanding the context and making informed decisions about the architecture is important. But the view about the entire project needs to be really high level. Abstract thinking. No details. Focus on details should be only when a specific problem is actually solved, or it will eat so much time, you end up never starting to do anything, but instead thinking about doing the job.

Detailed analysis is an obstacle for progress. And I say this from experience. Sadly, the way I work is waterfall, and all project needs to be defined, so it can be estimated, budgeted, outsourced... The trouble is that after 6 months, we are just finishing the analysis. If we would have started with developing features we knew we would need and iterate on that, we would have been almost finished by this time. However, in order to go for an agile approach, there has to be a culture for that in the company. If politics prevent this from happening, analysis paralysis will inevitably follow.

In my opinion, analysis is absolutely essential before development. Specially if you are working in a team, because the interfaces should be clear to everyone. Once the design is on the paper with sufficient detail, implementation should be trivial.

When I first started as a programmer, I hated the design and analysis part because I felt it was disingenuous to write a high level document without knowing how it was actually going to be implemented. But the real reason it made me uncomfortable was that I was bogged down into details of implementation. I was an amateur who couldn't get my head beyond code itself.

I think so, even on small project, it's always nice to prevent issues to have a bigger picture of what you're gonna do. This is a good habit in my opinion...