When speaking of analysis, most people think of gathering information, or requirements, and analyzing those requirements in order to begin modeling a database. This chapter discusses the process of gathering requirements and beginning to analyze those requirements. In subsequent chapters, we will show how to actually convert the requirements into diagrams and eventually design the tables that comprise the database. Before getting too anxious and starting to model the database prematurely, the development team should take a step back, take a deep breath, and review the activities of analysis. The military calls this process an “after action review.”
5
GATHERINGBUSINESSANDSYSTEMREQUIREMENTS
Database designers refer to this process as evaluation of analysis, which is a way of preparing for the next phases, database modeling and design, by reviewing the results of the analysis phase.
When evaluating analysis, or the work achieved so far, it is most important to check the requirements for completeness. Although completeness is checked many times up to this point, this is the last chance you will have to verify the completeness of the information gathered before modeling the database. Of course, requirements can always be established or redefined throughout database design, but not without taking a step back. It is best to follow all steps outlined in the design methodology used for any changes or additions to existing requirements to ensure that all deliverables and diagrams are consistent.
Involve the customer, end user, and management as much as possible during the evaluation of analysis. Begin by reviewing the interviews, the questions asked, and the responses obtained.
Review the goals set forth for the database, and ensure that the interviews were conducted appropriately to gather the required information. Allow all parties to take part in the evaluation, reviewing all deliverables one last time as if issuing a stamp of approval.
Because a significant part of information gathering and requirements analysis involves drawing diagrams, the most important action taken during evaluation is to review all diagrams used as deliverables. The diagrams should be checked for consistency and accuracy according to the requirements that have been established. Are the diagrams accurate representations of the busi-ness, and the business’s needs for a database? With regard to processes (functions), the evalua-tion of the analysis is complete when all the business requirements related to the database are mapped to a function, and each system requirement is associated with a function. With regard to data, all data and data-related business rules must be incorporated into the ERD.
If inadequacies in requirements are found, they should be addressed as early as possi-ble in the design process to minimize the overall effects on work and time involved to implement changes. For instance, more work will be required if the database has already been designed, and missing requirements are found that will alter the struc-ture of the database. If a process or entity is added or changed, all appropriate dia-grams should be modified to avoid confusion in the future.
N
OTEERDs should be checked to ensure that data has been completely defined. Process models are checked to ensure that all processes related to the database or application have been defined.
Data flow diagrams are checked for accuracy for data access by processes. Function hierarchy diagrams are checked to ensure that all processes, or functions, are properly related to one
another. If using an automated design tool, reports can be run to check the completeness of analysis. For example, some tools can generate matrix reports that illustrate entities that are affected by processes, and processes that affect entities. This type of report is an excellent tool to use to check for completeness concerning accessibility of data.
The following considerations should be taken to measure the completeness of information gathering and requirements analysis:
• Have all steps been followed so far?
• Is the direction of design still within the scope of the mission statement and objectives?
• Have all requirements been gathered in order to design a database?
• Is the Entity Relationship Diagram (ERD) correct?
• Is the function hierarchy correct?
• Are all database requirements on schedule for implementation?
• Do the requirements make sense to the development team?
• Were all deliverables acceptable to customer, end user, and management?
• Were all objectives of requirements analysis met?
• Are all appropriate parties comfortable with moving forward?
Summary
Taking time to gather the requirements that an organization has for a database is the most important part of design because a database cannot be created without these requirements.
Without completely gathering requirements, a database can be created, but can lack a great deal of functionality to the end user, or can even be unusable. The different types of require-ments discussed were business requirerequire-ments and system requirerequire-ments. Business requirerequire-ments are those related to the functionality of the business. Business requirements are used to estab-lish system requirements. System requirements are the requirements of the database and the end-user application based on the needs of the business. Requirements analysis is the process of analyzing the requirements that have been gathered, and converting the business require-ments into system requirerequire-ments.
Business requirements are obtained through interviews with management, the customer, and the end user. Interviews are conducted by various members of the design team. When conduct-ing interviews, it is important that there is a variety of both interviewers and interviewees, in order to view the business from different perspectives, thus completely gathering all require-ments. After all requirements are gathered, the design team draws various diagrams which depict the data and processes that belong to the business. The most typical diagrams, which are quite vague at this point, include entity relationship diagrams (illustrate the data), process
5
GATHERINGBUSINESSANDSYSTEMREQUIREMENTS
model diagrams, function hierarchy diagrams, and data flow diagrams. Detail is added to diagrams when converting business requirements into system requirements. For example, after a list of fields is determined for a given entity, attributes are added to the entity on the ERD.
System requirements are defined by identifying the data, breaking the data into logical groups, creating a list of fields for groups of data, and establishing data relationships.
Before information gathering and requirements analysis are complete, and the next major phase, modeling, is encountered, precautions must be taken to ensure that the project is moving on the right track. Before modeling begins, standards and naming conventions must be estab-lished so that all work is performed consistently. It is also important to begin documenting the activities conducted. The diagrams drawn comprise a significant part of documentation, which will be used by the design team, management, the customer, and the end user. Finally, all work performed is evaluated to ensure that the project is indeed moving in the right direction. The evaluation of analysis includes reviews of the interviews and all deliverables at this point.
Because it is often easy to get off track, it is important to verify that the focus of the project is still based on the original goals set forth for the system. If for some reason the goals of the sys-tem have changed from the time of their definition to now, it will be necessary to restart the process of gathering requirements to guarantee completeness.