Purpose of Requirements Analysis

The overall purpose of Requirements Analysis is to gather every bit of information needed to design a database that meets the informational needs of an organization. This is accomplished by performing a series of related tasks:

1. Examine the existing database(s)
2. Conduct user interviews
3. Create a data flow diagram (if needed)
4. Determine user views
5. Document all findings

As mentioned earlier in this course, Requirements Analysis is the most important and most labor-intensive stage in the DBLC. It is critical for the designer to approach Requirements Analysis armed with a plan for each task in the process.

The sequence in which the tasks associated with Requirements Analysis are performed is not etched in stone. Nor are the tasks themselves necessarily performed in isolation from one another. For example, tasks are documented while they are being performed; a data flow diagram is often created while conducting interviews; user views are frequently sketched while examining the existing database(s), and so forth. Requirements analysis in systems engineering and software engineering, encompasses those tasks that go into determining the needs or conditions for a new or altered product and taking account of the possibly conflicting requirements of the various stakeholders.
Requirements analysis is critical to the success of a development project. For this reasons requirements must be documented, actionable, measurable, testable, and related to identified business needs or opportunities.
Requirements can be architectural, structural, behavioral, functional, and non-functional.

Experience is the great teacher when it comes to assessing informational needs, but there is no substitute for preparation, specially for new designers. Most database designers begin Requirements Analysis by examining the existing database(s) to establish a framework for the remaining tasks. Analyzing how an organization stores data about its business objects^[1], and scrutinizing its perception of how it uses stored data (for example, gaining familiarity with its business rules)^[2] provides that framework.

The database requirements are determined by interviewing both the producers and users of data and using the information to produce a formal requirements specification. That specification includes the data required for processing, the natural data relationships, and the software platform for the database implementation. For example products, customers, salespersons, and orders can be formulated in the mind of the end user during the interview process.
The information needed to build a data model is gathered during the requirments analysis. Although not formally considered part of the data modeling stage by some methodologies, in reality 1) the requirements analysis and 2) the ER diagramming part of the data model are done at the same time.

The goals of the requirements analysis are:

1. To determine the data requirements of the database in terms of primitive objects
2. To classify and describe the information about these objects
3. To identify and classify the relationships among the objects
4. To determine the types of transactions that will be executed on the database and the interactions between the data and the transactions
5. To identify rules governing the integrity of the data

The modeler works with the end users of an organization to determine the data requirements of the database. Information needed for the requirements analysis can be gathered in several ways:
Review of existing documents: Such documents include existing forms and reports, written guidelines, job descriptions, and personal narratives. Paper documentation is a good way to become familiar with the organization or activity you need to model.

These can be a combination of individual or group meetings. Try to keep group sessions to under five or six people. If possible, try to have everyone with the same function in one meeting. Use a blackboard or overhead transparencies to record information gathered from the interviews.
Review of existing automated systems: If the organization already has an automated system, review the system design specifications and documentation. The requirements analysis is usually done at the same time as the data modeling. As information is collected, data objects are identified and classified as either entities, attributes, or relationship. They are then assigned names and defined using terms familiar to the end-users. The objects are then modeled and analysed using an ER diagram. The diagram can be reviewed by the modeler and the end-users to determine its completeness and accuracy. If the model is not correct, it is modified, which sometimes requires additional information to be collected. The review and edit cycle continues until the model is certified as correct.

[1]business objects: Items in a business environment that are related, and about which data need to be stored (e.g., customers, products, orders, etc.).

[2]Business rules: A set of rules or conditions describing the business polices that apply to the data stored on a company databases.