In a business analysis report, you want to break down requirements into four core components: data, process, external agents/actors, and business rules. This will allow those stakeholders reading your report to zero in to their own specific area of expertise.
Data is information that frequently gets stored. Whether it’s big data (such as volumes and volumes of multimedia or real-time information) or small everyday data (such as invoices, billing, sale projections, and personnel records), requirements for business data define what each piece of data is, what it’s for, what it means, how it’s represented, and what relationship it has to other pieces of data.
You typically store information in a database with both a physical and a logical design. The database is a physical place with structures (tables and columns) that capture and organize all its data. Physical database designs represent the technical requirements for how the business data will be stored, and these are frequently designed by the database administrators or data engineers.
The logical design reflects what the solution’s functional data requirements are to support the business needs. It’s called logical because it shows logically how the business thinks about the data and its interconnected relationships from the business perspective. The business analyst frequently defines logical representations of data requirements after the information is elicited from the business stakeholders.
Defining business data from the logical perspective presents three major concerns: the entities, their attributes, and the relationships between them.
The business may want to store a lot of valuable information, but when it comes to the question of storage and whether the business would pay to keep track of it, you need to push your business stakeholders to think about their data requirements carefully, remembering that data stored must be maintained, managed, tracked, validated, and retrieved.
Make sure you walk your stakeholders through the financial impact their data requirements will have.
Entities
Entities are the biggest pieces of business data, and they represent major information elements. An entity is a uniquely identifiable person, thing, or concept that the business cares about and wants to store information for. Entity data is stored within tables, but as a requirement, an entity is a named noun, described by a textual definition.
Attributes
Named with nouns or noun phrases, attributes capture the many details known about an entity. They are stored as columns within a table and are pieces of information typically included on screens, web pages, and reports. The most important kinds of attributes collect information about the business data entities.
To make it obvious which attributes describe data fields for which entity, business analysts commonly prefix attributes with their entity name in capitals. Some examples are EMPLOYEE.first-name, EMPLOYEE.last-name, and BUSINESS-UNIT.name.
Beyond the business information, you must also be concerned with attributes of the attributes. These characteristics describe the meta data about an entity and its attributes. Meta data is essentially data about the data. Attributes from a business perspective store business information about the entities, but attributes from a requirements perspective store information about the physical characteristics of each data field within the table.
Clearly identifying what these characteristics are is critical for the data requirements and for ensuring the appropriate behavior of the solution. These sub-attributes include uniqueness and cardinality:
Uniqueness: The first question to be answered about an attribute is whether it’s unique for every occurrence. For example, if the attribute PERSON.first-name is specified as a unique attribute, one and only one occurrence of that entity can have that value. If your personal information is captured within the solution, then no other person occurring in the database can have the same first name as you — ever.
Cardinality: The second and third questions deal with the attribute’s cardinality (whether an attribute may or must have zero, one, or multiple values). First, you must determine whether the attribute is a mandatory field: Must data for this attribute be captured, or can the attribute value be left blank? If the attribute is optional, no data needs to be captured — blanks are okay.
If the attribute is mandatory, something must be entered or an error will occur. In the first name example, if first name is mandatory, you must enter a name of some sort. You can’t enter anyone into the database and not know and record what his first name is.
The third question is about repetition. If an attribute has or is allowed repetition, then the business expects to collect multiple valid values for that attribute. You must consider whether the business is describing a single-value field — where the entity has one and only one of these things — or whether the entity the attribute describes may have many of these attributes.
Repetitive attributes are frequently used to allow business stakeholders to collect different types of the same attributes or the same attributes across different points in time. An example of a repetitive attribute is PERSON.address.
Think about how many addresses a person may have: a home address, a work address, a shipping address they prefer for deliveries, a billing address, and maybe even a vacation address.
Relationships
The last major concern in data requirements is the data’s relationship to other pieces of data in a database. Relationships are defined by using keys, or relationship identifiers, that connect data tables together. They’re also attributes, but they’re special attributes in that they provide unique identifiers for individual data elements and denote relationships an entity has to other entities or attributes.
Data relationships also have cardinality defined. You must define whether a relationship must exist (for example, if salary data is captured, it must be related to an employee) or is optional (a person may or may not have a dependent), and whether any relationship that exists is expected to be repetitive between the related entities (a person may have a relationship to more than one dependent).