Good database design begins
before the model. Documentation and user interviews may not be enjoyable to
you, but if you want your database to fulfill the business needs it is supposed
to address, they are critical processes. It is important that your client is
thinking about what data the application needs to be useful. Knowing the scope
of the application and what business purpose(s) it fulfills clarifies your
purpose and process.
Once the functional requirements are documented, the technical specifications should start taking shape. It is imperative that you ask questions clarifying how the data relates to other elements and discover additional business rules and data items. Users are generally more familiar with how the data relates to itself than they are aware. Asking a few simple questions makes your job a lot easier. Listen to your client; it will make your job easier and the project more successful. You do not want to intimidate the user(s) so do not speak about attributes, relations and domains. Instead, make them feel smart by speaking their language; ask if a member will ever have multiple addresses. Getting a handle on what data needs to be stored and how it relates to other data facilitates the database designing itself (seriously, they do that).
A well designed database accommodates all reporting so use the reporting requirements to ensure that you have all relevant elements; you should not need to adjust your design for reports. If you do, it may point to a design flaw or two.
To recap, requirements are important. They provide you an understanding of the client’s needs and show your understanding of what data needs to be stored and how the data relates to itself. Participate in the requirement gathering as the rest of your team may not ask the questions that you need answered. Requirements are the start of your database.