Requirements Analysis Documentation

All the tasks performed during Requirements Analysis should be carefully documented, as these documents carry over into the remaining DBLC design stages. After completing Requirements Analysis, the following documents should be in hand:

1. A preliminary list of business objects (sorted by subject), their characteristics, and how they relate to one another
2. A specification sheet for business rules (including possible constraints)
3. An assessment of future informational needs
4. A specifications sheet for user views (including needed calculations)
5. A data flow diagram (if it was determined one was needed)

Several of these documents will be immediately useful for creating the database's logical schema. The data flow diagram may come in handy later on for creating database applications and revising user views.
Documentation is also important should conflicts arise later about the quality of the database design. All interested parties should have access to clear and concise documentation about the entire process of needs analysis.

If legacy data are needed primarily as an archive, then a company may choose to leave the database and its applications as they stand. The challenge in this situation occurs when the hardware on which the DBMS and application programs run breaks down and cannot be repaired. The only alternative may be to recover as much of the data as possible and convert it to be compatible with newer software. Businesses that need legacy data integrated with more recent data must answer the question. Should the data be converted for storage in the current database, or should intermediate software be used to move data between the old and the new as needed? Because we are typically talking about large databases running on mainframes, neither solution is inexpensive.
The seemingly most logical alternative is to convert legacy data for storage in the current database. The data must be taken from the legacy database and reformatted for loading into the new database. An organization can hire one of a number of companies that specialize in data conversion, or it can perform the transfer itself. In both cases, a major component of the transfer process is a program that reads data from the legacy database, reformats them as necessary so that they match the requirements of the new database, and then loads them into the new database. Because the structure of legacy databases varies so much among organizations, the transfer program is usually custom-written for the business using it. The next lesson concludes this module.