Requirements Analysis Documentation

Requirements analysis is a crucial phase in the database life cycle, during which the system's functional and non-functional requirements are identified, documented, and analyzed. The goal is to gain a clear understanding of the needs and expectations of the users, as well as the technical and operational constraints. This phase lays the foundation for the subsequent design, development, and deployment of a successful database system. The following documents are typically produced during requirements analysis:

1. Requirements Specification Document: This is the primary output of the requirements analysis phase. It is a comprehensive, organized, and structured document that outlines the detailed functional and non-functional requirements of the database system. The requirements specification document typically includes:
   
   1. Introduction: Overview, objectives, scope, and constraints of the project.
   2. Functional Requirements: Descriptions of the features, capabilities, and data processing needs of the system.
   3. Non-functional Requirements: Performance, usability, security, maintainability, and other quality attributes.
   4. Data Requirements: Data types, attributes, entities, relationships, and constraints.
   5. Business Rules: Domain-specific rules, regulations, and standards that must be adhered to by the system.
   6. Use Cases and Scenarios: Real-world examples illustrating how the system will be used by different user roles.
2. Data Flow Diagrams (DFDs): These are graphical representations that depict the flow of data within the system, illustrating how data is input, processed, stored, and output. DFDs help visualize the overall structure and the relationships between different components and processes, making it easier to understand complex systems.
3. Entity-Relationship Diagrams (ERDs): ERDs are another form of graphical representation that focuses on the entities, attributes, and relationships within the database system. These diagrams help to identify and document the key data structures, as well as the cardinalities and dependencies among them.
4. User Stories: User stories are informal, natural language descriptions of one or more aspects of the system, written from the perspective of the end-users. They capture specific needs and expectations in a concise and easily understandable format. User stories serve as a basis for deriving more detailed requirements and are valuable in maintaining a user-centric approach throughout the development process.
5. Requirements Traceability Matrix (RTM): The RTM is a document that tracks the relationships between requirements and their corresponding design, development, and testing artifacts. It helps ensure that all requirements are addressed and provides a mechanism for managing changes and assessing the impact of modifications throughout the project.

The documents produced during requirements analysis are essential for guiding subsequent phases of the database life cycle, such as logical and physical design, implementation, testing, and deployment. They serve as the foundation for effective communication and collaboration among stakeholders, ensuring that the final system meets user expectations and business objectives.

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.