Software development literature and practice (in many projects) tend to propose certain activities to deliver reliable software. These activities are either learned from industry experience or advice and vision laid out by different methodology thinkers. It is a common practice to perform planning, analysis and design tasks (under any other name) at the beginning of major software tasks.
Software programming is an activity that could benefit from knowledge gained by performing those tasks.Programming is not usually the starting point (or the only task) in a serious projects. Development teams are usually composed of people playing different roles. Programming is only one of these roles.
The Business analyst's role is to aid in the process of discovering, documenting and validating the business requirements from the view point of the stake holders and customers, data modelers build the ERD to satisfy those requirements, Architects determine the optimal environment and integration methods to deliver the solution, DBAs tune the database design, Programmers work on delivering the code and may produce system prototypes to solicit early customer feedback etc.
Technical tools such as UML diagrams may be used by different roles at various stages of the system life cycle to document how the system is packaged, parts of the object model, process flow(s), etc.
As @Raythal indicated, the process of requirements determination is not performed in isolation of customers (unless you are creating a novel tool or product) and the analysis process has an iterative nature in non-trivial projects. The relationship between IT and the end-customer need not stop after system analysis has finished. In fact it is good to have controlled customer involvement during the entire project life cycle. The Project Management role should facilitate the interaction between the appropriate team members and the customer and should observe the interests of both parties in doing so.
The contents of the document you mentioned in your question is what matters. It should contain sufficient information for all involved parties to provide their corresponding deliverable. For example, a data modeler can't build a correct data model without business rules. A developer can't produce a prototype if the business process flow(s) is/are unknown and so on.
In practice it is not uncommon to see applications begin in unorganized manner, however, this is not the practice to follow if reliability counts.
You'll find much more about the answer to your question under the subject "software development life cycle" and in particular "Requirements Engineering/Management".