Requirements Analyis

ABSTRACT

We will see the different steps of the requirements analysis in this article. Requirements analysis is one of the most important phases of the DDLC as the users’ requirements are captured during this phase. If this phase is not done properly, we will end up designing a system that the user does not want or something that does not satisfy the user’s business needs.

CONTENTS

Introduction
Business Objects
Business Rules
Users of Data
Requirements Analysis Documentation
Data Flow Diagram
User Views
Summary

INTRODUCTION

The first step in implementing a database system is to find out what is required. What kind of a database is needed for the organization, what is the volume of the data that must be handled on a day-to-day basis (transaction data), how much data is to be stored in the master files, and so on. This phase is called the Requirements Analysis.

Requirements analysis is the first and most important stage in the DDLC. It is also the most labor-intensive for the database designer. This stage involves assessing the informational needs of an organization so that a database can be designed to meet those needs. 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:

• Examine the existing database(s)
• Conduct user interviews
• Create a data flow diagram (if needed)
• Determine user views
• Document all findings

It is critical for the designer to approach requirements analysis armed with a plan for each task in the process. Experience is the great teacher when it comes to assessing informational needs, but there is no substitute for preparation, especially 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, and scrutinizing its perception of how it uses stored data (for example, gaining familiarity with its business rules) provides that framework.

BUSINESS OBJECTS

Identifying an organization’s business objects is typically the first order of business during requirements analysis. Since most database design situations involve businesses that already have some sort of database in place, the first place to look for business objects is in the existing database, whether legacy, paper-based, or both.

Business objects are things (both tangible and intangible) in a business environment that are related, and about which data is (or needs to be) stored. Employees, projects, customers, appointments, products, orders, suppliers–all of these are objects about which organizations store information. During requirements analysis, business objects must be identified and sorted according to subject. If two or more distinct subject categories appear, a database should be created for each. Keep in mind that every organization makes decisions about which business objects it will and will not store data about. For example, for a small business, the owners might decide they do not want to have any data about themselves (as owners/employees) stored on the company database. Business objects are converted into entities in the logical design stage. Entities, in turn, are ultimately translated into database tables with SQL. Every business object has characteristics that describe it. Customers, employees and suppliers, for example, will have names, addresses, phone numbers, and so on. Products will have names, prices, descriptions, and so on. Appointments will have times, dates, and so on. In fact, if you cannot identify two or more characteristics of a business object, there’s a strong possibility it’s not a business object at all. Figure 1 gives a list of sample business objects and their characteristics, appropriate to a wide range of databases.

Figure 1 SDLC phases and their relationship with DDLC

The characteristics of business objects are converted into the attributes of entities in the logical design stage. Attributes, in turn, are ultimately translated into table fields with SQL. Business objects relate to each other in some form or fashion. Customers place orders, employees take orders, orders are for products, products come from suppliers, and so on. Relationships between objects can be complex, so establishing relationships at this point in the design process is quite preliminary. It is important to note, however, what objects are generally related, especially in the existing database(s). As part of requirements analysis, database designers list and document the business objects stored in the client’s existing database(s), along with their characteristics and a preliminary idea of how they are related.

BUSINESS RULES

Business rules describe the business policies that apply to the data stored on a company’s databases. In other words, business rules reflect how a business perceives its use of data. Some business rules are especially important to the database designer because they can be incorporated into the logical schema of the database. There are certain constraints that designers apply to ensure that a database honors a company’s business rules. These constraints help preserve data integrity. Business-rule constraints fall into two categories—field constraints within tables, and relationship constraints between tables. There are various field constraints that can be imposed on a database to honor business rules. Consider the example below:

• Business rule: We ship our products to customers in four states only: Kerala, Tamilnadu, Karnataka and Andhra Pradesh.
• Field constraint: These states are represented in a Customers table in a field called State as: Kerala, Tamilnadu, Karnataka and Andhra Pradesh. A constraint is placed on the State field so that only those four states are accepted into the database for that specific table.

Constraints are especially common on date fields, where dates would become meaningless in a database if a product’s ship date, for example, was earlier than the customer-order date for that product, or if an employee’s termination date was prior to his/her hire date! There are also various constraints that can be placed on the relationships (links) between tables. Consider the example below:

• Business rule: Every vendor must supply at least one product.
• Relationship constraint: The relationship between the Vendors table and Products table must be governed by a participation constraint wherein a single record in the Vendors table must be related to at least one record in the Products table.

Additionally, relationship constraints dictate that certain tables in a relationship have mandatory status, while others have optional status. Documentation continues for the designer, who should be creating a list of business rules for the organization as reflected in any constraints (if applicable) placed on the existing database(s). Developing an eye for constraints is mostly a matter of experience.

USERS OF DATA

Having completed your analysis of the existing business objects and rules, the next logical step in the process of Requirements Analysis is to interview those within the organization who use the data in the database. Their collective insights into how data is used helps in revising (for example, adding to or subtracting from) the list of business objects and rules collected earlier. Users of data include an organization’s employees and managers. There are three major reasons why users of data are interviewed by database designers:

• To determine how data are currently being used and perceived
• To determine whether users require additional information
• To determine future growth requirements

How an organization currently uses its data is determined not only by examining the existing database(s), but also by interviewing those who use the data. Pegasus Books, for example, has a data-entry form to process customer orders and a listing of its distributors in a Rolodex. Current informational needs of the company prescribe that distributors be considered a business object.

Interviewing the current users of data—the owners of the store, in this case—has uncovered this “out of sight” paper-based data sources. Rarely will an analysis of an organization’s existing database–whether legacy or paper-based–reveal the full range of an organization’s informational needs. If that were the case, the role of the database designer in creating a database would be greatly diminished. Interviewing data users about future needs enables the designer to rethink design options. For example, if the interview of owners revealed that they intended to sell Books outside India in about 18 months, the designer might refrain from placing any field constraints on address-related fields that would preclude data entry about overseas customers. Again, documentation of the interviews is extremely important. As questions arise while designing the logical schema, notes taken here are reviewed and can point the designer in the right direction if more user information is needed.

REQUIREMENTS ANALYSIS AND DOCUMENTATION

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

• A preliminary list of business objects (sorted by subject), their characteristics, and how they relate to one another
• A specification sheet for business rules (including possible constraints)
• An assessment of future informational needs
• A specifications sheet for user views (including needed calculations)
• 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.

DATA FLOW DIAGRAM

As part of Requirements Analysis, the designer may request organizational charts from the business, and supplement these charts with information gathered during interviews with users to assess how data flow is handled within the organization. He or she uses this information to create a data flow diagram. These diagrams are useful to the designer in establishing user views across multiple databases (and also in determining if multiple databases are needed) and in sorting business objects by subject matter.

While there are different styles of data flow diagrams, they are quite similar in appearance and function and are read in the very same way. The two main styles of data flow diagrams are the Yourdon/DeMarco style and the Gane & Sarson style. The Yourdon/DeMarco uses squares, circles, and parallel lines to represent data handlers, processes, and databases, respectively. The Gane & Sarson style, on the other hand, uses squares, round-cornered rectangles, and open-ended rectangles to represent data handlers, processes, and databases, respectively. The Yourdon/DeMarco data flow diagram (see Figure 2), for example, includes symbols that illustrate:

• Who handles the data (text enclosed in a square)
• Where the data moves (arrows on the diagram)
• Where the data are stored (text surrounded by parallel lines)
• What is done to the data (text inside a circle)

Figure 2 Data Flow Diagram

Figure 2 illustrates a typical Yourdon/DeMarco data flow diagram. Given below is the explanation of the different steps shown in the figure:

1. An employee takes the customer order.
2. The order is stored in the database.
3. An employee prepares the order for shipment.
4. The order is shipped to the customer.
5. The ship date is recorded in the database.

Also note the use of the symbols in the diagram:

• Text surrounded by a square indicates people who handle the data.
• Arrows connecting text indicate the movement of data.
• Text within circles indicates an operation performed on the data.
• Text enclosed by parallel lines indicates where the data is stored.

It is not always necessary to create a data flow diagram. For example, Pegasus Books is small, with only one subject database. It is not necessary to create a diagram to understand the flow of data in this instance. Views created for this company would provide specific information in a specific format, and those views could be documented without recourse to a data flow diagram. However, a large organization with several subject databases (or one very large database) will require numerous user views that draw from different databases. In this case, a data flow diagram is important for two reasons:

• To determine what data from which databases go into different user views
• To assist application designers in planning database application programs

The larger the organization for which you’re designing database(s), the more important it is to create a data flow diagram.

USER VIEWS

The data flow diagram, combined with specific questions posed to users of data about their needs, paves the way for the designer to create user views. User views are specific views of data created with SQL. The designer defines what data (from what database tables) are made available in these stored queries. There are three important reasons for creating user views:

• Data security – User views were defined earlier in terms of data security. They specify which users are permitted access to what data in a database (or across databases). User views ensure that sensitive data remains hidden from unauthorized eyes.
• Specific user needs – Creating views to meet specific user needs is the flipside of the data security issue. Users must have access to certain data to perform their jobs. It is counterproductive for users to have to wade through data that is irrelevant to their work.
• Calculated fields – The tables actually stored in a database (called base tables) should not have any type of calculations built into their fields. The reason for this is simple: every field in a base table uniquely and independently stores data about the subject of its table. If calculation were permitted in base tables, then the data stored in some fields would depend for their values on data stored in other fields. User views, however, store their data in virtual tables that consist of fields loaded into computer memory from base tables. Virtual tables themselves are not stored in the database; rather, the definition of the view is stored and given a name. Users call up that name, and the view is created (from base tables) on the fly. When a user closes the view, it “disappears” from memory, only to be recreated the next time its name is invoked. A user view (like a database application) allows calculations to be performed on the data contained in its fields. That’s because these field calculations within virtual tables have no effect on the data stored in the base tables. One significant reason to create user views, then, is because, through calculations, views can deliver extremely useful information.

User views, therefore, not only protect sensitive data within an organization; they also protect users from being inundated with useless data.

SUMMARY

We have seen the different steps of the requirements analysis. Requirements analysis is one of the most important phases of the DDLC as the users’ requirements are captured during this phase. If this phase is not done properly, we will end up designing a system that the user does not want or something that does not satisfy the user’s business needs.

RELATED ARTICLES:

01. Database Development Life Cycle (DDLC)