REQUIREMENTS GATHERING - A Developer's Guide to Data Modeling for SQL Server - page 116

Again, consider the example of our teacher work-flow application.
What if, instead of being designed for one school, the school board decides
that this application should span all schools in the district so that it could
centralize reporting and maintenance? Suddenly, the model you were de-
veloping for 200 users at a school with 1,200 students may need to support
1,200 users managing records for 7,200 students. Before, the response
times were based on application servers in a school interacting with data-
base servers in the same room. Now, there may be application servers all
over, or possibly at the central administration offices, and there may be
only one database server to support them all. However, the organization
still expects the same response time even though the application (and data-
base) will have to handle an increased load and latency. You will need to
compile and review this information during design to ensure that your
model will scale well. Do you need any additional entities or relationships?
Are there new attributes to existing entities? And, when physically imple-
mented, will your data model support the new requirements?
Summary
Gathering requirements is daunting and sometimes tedious, but it is a cru-
cial step in the design phase of a functional data model. The key is to
gather as much data as possible; documents, screen captures, code, spread-
sheets, interviews, observations, and use cases are all things you can use to
figure out exactly what the new design will be. Here we've presented some
techniques for gathering data. In the next chapter, we look at how to take
the volumes of data we've gathered and turn it into requirements that will
guide the design and development process for our fictitious company,
Mountain View Music.