Attribute Uniqueness

Whether or not an attribute is unique tells the team if it should be used to look up, search, and find a particular set of data. For example, if CUSTOMER NUMBER is unique, it can be used to search the database for a particular customer. If the CUSTOMER PHONE NUMBER is not unique, a search on phone number may result in two or more customers. Understanding how data can best be searched and accessed is a very important part of business analysis. In addition, specifying uniqueness helps with ongoing data integrity. If the EMPLOYEE NUMBER attribute was defined as unique and another employee is added with the same number, there is a data problem.

The uniqueness characteristic of each attribute helps the analyst ask a very specific question about the business requirements: Is a value of this attribute unique among all values? Frequently, the business stakeholders will be able to answer this question easily and without reservation. Occasionally, however, the answer will not be simple. Analysts should listen for phrases like “Well, it is usually unique but we have had a couple of duplicates when . . .” or “I think it is unique, but I am not sure how it is assigned, so it may not be.” Answers like these must be followed up with more detailed conversation.

Mandatory or Optional

Another important question that should be asked for each attribute is: Is the attribute mandatory? When the answer to this question is no, the analyst must always follow up, looking for one or more business rules that guide its collection. For example, if a subject matter expert (SME) is asked if a CUSTOMER E-MAIL ADDRESS is mandatory, the answer “it depends” leads to business rules. When a customer places an order via the Web site, an e-mail address is required. But when a customer places an order by phone, it is not. This business rule can easily be missed if attributes are not thoroughly analyzed.

Attribute Repetitions

Can there be many occurrences of a particular attribute? For example, can a customer have more than one phone number? More than one e-mail address? Eliciting requirements around possible repeating attributes helps to open up discussions about possible values and their relevance to the business. Often, old application systems only had room for one phone number. Users with more than one phone number were forced to choose which one to enter. Valuable data has been lost because the existing database didn’t have a place for it. Sometimes users put extra information somewhere else in the database. “If the customer gives me a second e-mail address, I put it in the customer title field on the screen because we don’t usually enter titles.” These discussions point out specific problems with current business systems and will help analysts design better solutions for the future. In addition, they highlight current data integrity problems that may negatively impact new reports when existing data elements are used.

In addition to finding limitations with the current business system, the questions about attribute repetitions help the analyst to walk the SMEs through some what-if analysis. For example, if a customer has three e-mail addresses, will they all be stored? For what would they be used? How would which one to use to send the order confirmation be determined? Would it be sent to all three? Who will maintain these addresses?