Core Requirements Component: Entities (Data)

Data requirements are most commonly analyzed using the entity relationship diagramming technique. This technique defines three data components: entities, attributes, and relationships (business rules). Every business analysis professional should be familiar with the entity relationship diagramming analysis technique and understand why data requirements are important. One of the best and most readable resources on entity relationship diagramming is Data Modeling Essentials by Simsion and Witt (2005). Business analysis professionals should include it in their library.

An entity (in entity relationship diagramming) is a uniquely identifiable person, thing, or concept whose information is important to a business. These entities are the big, important things that the business manages. Common examples include CUSTOMER, PRODUCT, and ORDER. When working in a Unified Modeling Language (UML) or object-oriented (OO) methodology, these would be referred to as objects or classes. Entities are named with nouns or noun phrases. The names are very important because these entities will be referred to frequently in other requirements. Names must be clearly defined in a glossary and, most importantly, used consistently. One of the most common mistakes made by inexperienced analysts is inconsistent use of terminology.

Traditionally, entities were elicited and documented in requirements because they represented data or information that needed to be stored in a database for software development. But there is a more important reason for performing data analysis. Understanding the information that a business area uses to accomplish its goals ensures the BA knows the “materials” and “products” of the business. Little business work can be done without information. To ignore business information and focus only on process and business rules is like trying to build a table with only two legs. It will not stand up.

Unfortunately, people who do not understand the meaning and importance of the words data and information often ignore these requirements because they “already have a database” or “are not building software.” When a project involves an existing application, a vendor package, or a process change, data requirements seem like a logical task to skip. However, ignoring business data requirements almost always leads to problems. Business people need information constantly. They want it on reports, on display screens, and on forms. They want it to be accurate, available, and flexible so that it can be manipulated as needed. Regardless of the type of project to which you are assigned—don’t ignore the data. See Table 6.2 for an entity list template.

Core Requirements Component: Attributes (Data)

Attributes (also from entity relationship diagramming) represent pieces of information that further describe entities. In other words, when you recognize that CUSTOMER information is important to the business, its attributes become obvious: FIRST NAME, LAST NAME, MAILING ADDRESS, E-MAIL ADDRESS, PHONE NUMBER. These individual data elements describe the important characteristics of each entity. Attributes, like entities, are named using nouns or noun phrases because they represent things (in UML and OO diagrams, they are also referred to as attributes, characteristics of objects, or classes). See Table 6.3 for an example of an attribute template. (Attributes and their descriptions may also be collected in a data dictionary.)

Attributes are everywhere in the business infrastructure: reports, screens, forms, phone systems, procedures, guidelines, policies, etc. It is imperative that the analyst identify and document all needed attributes during requirements elicitation.

As recommended for entities, attributes should be carefully named and defined. Business terminology must be used—not IT terminology. Names like NEW CUSTOMER INDICATOR or CUSTOMER FLAG are meaningless to business stakeholders. The excellent analyst discusses the meaning and description of each data element and names it appropriately. This does not imply that the common name used by a business is always the best name. Common names or phrases used in business areas are occasionally inaccurate and have evolved over time in a way that is no longer meaningful. An expert in business analysis will help business stakeholders name each attribute accurately without including past or future technology bias.

Table 6.2: Sample Entity List Template
			Number of Occurrences
Entity ID	Name	Unique Identifier	Current	Future	Owner/Author
E1	CLASS SESSION	Class session number	10/mo	15/mo	Owner: TA
E2	COURSE (Content)	Course title	15	30	Owner: TA
E3	COURSE EQUIPMENT	(Course title + Course equipment type)	25	40	Owner: TA
E4	INSTRUCTOR	(Instructor last name + instructor first name)	5	7	Owner: TA
E5	INSTRUCTOR QUALIFICATION	(Instructor first name + Instructor last name + Course title)			Owner: TA
E6	LOCATION	Location name	2	3	Owner: Facilities
E7	REGISTRATION	(Student number + Class session number)	200/mo	350/mo	Owner: TA
E8	STUDENT	Student number (same as human resources employee number)	1000	3000	Owner: HR

For data that is already stored in a database, the analyst’s questions should be: “Where and in how many databases?” Many organizations store an important piece of business information (an attribute) in tens or hundreds of places. Think about an attribute like CUSTOMER NUMBER. How many files, databases, or spreadsheets in your organization store this piece of information? Redundant data storage often results in an ongoing data integrity problem. If there are names and addresses in multiple places, which occurrence of the customer name and address is the correct one? Are they all kept in sync? Who maintains them? With data stored in existing databases, data requirements become even more important because instead of defining what data is needed, the analyst needs to be a detective, searching out all of the possible places where a piece of data is stored and then determining which of the many locations holds the correct value for this particular solution.

Table 6.3: Sample Attribute Template
Name	U	M	R	Date Type/ Length	Valid Values	Default Value	Owner	Definition
ID: Class session number	Y	Y	N	Number	1–999999		Training management	Unique number assigned to each class session for tracking purposes
Class session start date	N	Y	N	Date			Training management	Classes are only held on business days
Class minimum number of students	N	Y	N	Number	5–20	5	Training management	Least number of students that the class session will be held for
Class maximum number of students	N	Y	N	Number	5–20	14	Training management	for
Class current number of registrations	N	N	N	Number	5–20	0	Derived	Tally of the number of registrants to date
Class setup	N	N	N	Char (50)			Training management	Description of any setup required for the class
Class session room number	N	N	N	Char (3)			Corp. meeting room system	the class will be held
Course title	N	Y	N	See COURSE for attribute characteristics
Location name	N	Y	N	See LOCATION for attribute characteristics
Instructor last name	N	N	N	See INSTRUCTOR for attribute characteristics
Instructor first name	N	N	N	See INSTRUCTOR for attribute characteristics

U = unique, M = mandatory, R = repetitions.

In addition to naming and defining each attribute, there are detailed characteristics to be considered by the analyst. These characteristics further describe the attribute, helping the analyst to more completely understand the business need. They often uncover business rules and reveal more detailed and complex requirements that might otherwise be missed.