Thursday, 13 September 2018 09:51

Well-defined Data Part 6 - Attributes that Name

Written by

In this article we focus on people-oriented identifier attributes — ones intended to record the name by which the person or thing is known, addressed, or referred to.

Unlike the business entity identifier attributes discussed in Part 5, name values may change over time, and values may not be expected to be unique, e.g. names of persons.

There are instances of things that an organization establishes internally, and therefore has the right to name. These things include positions within its organizational structure, its general ledger accounts, the products it produces, the services it offers, and the locations it manages for operations and sales purposes.

Things that an organization does not have the right to name include its staff members, customers, and suppliers.

Full, Abbreviated and Coded Name Attributes

When a business entity is the type of thing that has named instances, there is a good chance that there will be requirements for more than one name attribute. Wherever names consist of a number of full words, the organization will most likely have a shorter version of the name that it uses in its business processes.

And where a name is used frequently, and keystrokes are to be minimized, there is likely to be an extra-short code version of the name.

Full Names – Where a name is intended to be descriptive, it’s value contains full words. E.g. ‘Tee Hinge 200mm Zinc Plated’, ‘Human Resources Department’, ‘California’. Full name attributes often have the term name or label in the attribute’s name.
Abbreviated Names – An abbreviated name is intended for ‘everyday use’ by the organization. Words found in a full name may be abbreviated, reduced to initials, or to an acronym. Someone new to the organization may not immediately recognize an abbreviated name, but it’s the name the thing is commonly known by within the organization. E.g. ‘T-hng 200mm Zn Plt’, ‘HR’, ‘Cal’.
Coded Names – A coded name is intended to take up the minimum amount of screen or report real estate. A cost of this space saving is the learning curve for new users of the system. 'Old-timers' in the organization know the code values so well they have trouble understanding that they are not obvious to everyone.
Coded name attributes often have the term code or the abbreviation cd as part of its attribute name. Values can be as short as a single character, but more typically utilize between two and six characters. Codes longer than six characters are venturing into the realm of abbreviations.
Where a business entity is common to multiple organizations, such as country or currency, standardized code values may be available. The International Standards Organization (ISO) maintains codes for countries, regions within countries (states or provinces), languages, and currencies. Other organizations offer standards for more industry-specific codes. An example is the International Air Transport Association (IATA), which maintains the three-character codes used by all airlines to identify commercial airports, e.g. LAX, JFK, LHR).

Advertisement

Non-word Names

Not all names consist of words or abbreviations. Street names are a good example. The majority of street names do involve words like ‘Main’ or ‘Maple’, or are named after people or places. But there are also street names based simply on numbers or letters, e.g. ‘1st Avenue’, ‘2nd Avenue’, ‘A Street’, ‘B Street’.

Another example of non-word names are floors within a multi-story building. The floors will have full names, such as ‘Ground Floor’, ‘Fifth Floor’, ‘Parking Level One’, or ‘Penthouse’. But the organization may only require the coded versions of floor names (e.g. ‘G’, ‘5’, ‘P1’ ‘PH’).

Person Names

Person names are different again. One difference is that there is seldom an expectation that a person name will be unique. Another difference is that a normal part of life involves individuals changing their name, either legally or simply to the latest way they prefer to be addressed.

For entities that represent persons, such as Staff Member or Customer, there are four basic name-related attributes that may be necessary to support an organization’s business processes:

  • Legal Name — (1) Required to support business processes that involve regulatory organizations, where those organizations require identifying individuals (and companies) by their full legal name, e.g. tax authorities. (2) Required during business processes initially verifying a person’s identity, when that name is used to match with other organizations that also maintain a person’s legal name for such purposes, e.g. ‘Thomas Albert Jones’.
  • Contact Name — The name a person wants to be recognized by at their points of contact, such as when receiving snail mail or when contacted by phone. It’s expected (but not required) to include one or more ‘given’ names plus a family name, e.g. ‘Tom Jones’.
  • Preferred Name — The name a person prefers to be addressed by within the organization and/or by customers, e.g. ‘Tommy’ — displayed on the employee’s ID badge. For customers, it’s the name that the person prefers to see as part of their online user experience, e.g. ‘Welcome back, Tommy’.
  • User ID — The name chosen by or assigned to an online user of an IT-based system. Typically it’s some version of the person’s name. These names are required to be unique within the context of the system (but can change over time if required), e.g. ‘TJones’, ‘Tom.Jones64@Email.com’.

When the legal and/or contact names are expected to be sorted by family name, the family portion of the name would need to be its own separate attribute.

NOTE: Some organizations choose to prefix a person name with a title such as ‘Mr’ or ‘Mrs’. Similarly, an organization may want to present a person’s name followed by one or more recognized qualifications, such as 'MD', 'Ph.D.', or 'QC'. Such before and after values should be maintained as separate attributes, as they are classifications rather than an actual part of a person’s name.

Well-defined Name Attributes

From a well-defined data perspective, there must be an existing business entity that the name is an attribute of, e.g. Position, GL Account, Staff Member, Customer. For entities whose instances have just one name, the attribute can simply be called Name. Ideally, the attribute definition would include one or more examples that make it clear what is expected in the way of values for instances.

Name values that originate from within the organization can be made to fit within whatever length limit the organization specifies. Ideally, externally-sourced name attributes would allow for enough characters to accommodate the longest possible value. If not, then the process of capturing a name needs to allow for the value to be abbreviated or truncated to fit the available space.

Each name attribute should have a maximum length specified (testers will test this). A subject matter expert should be able to give an indication of how many characters will be sufficient. In the cases of codes, the organization may also want to specify a minimum number of characters.

In terms of restricting allowable characters within a name, internally-created names can be restricted if there is a business reason to do so (e.g. only alpha characters and spaces). Externally-sourced names are best left unrestricted unless there is a business reason to restrict allowed characters. The question becomes, “What should the IT system do if a valid external name is received that contains one or more restricted characters?” Leaving them unrestricted eliminates this question.

Name Values — The Bottom line

The majority of internally-sourced names come from the organization’s decision makers. If there is a technical reason that one or more special characters should not be allowed within a name, then validating to avoid them is a reasonable thing to do. Externally-sourced names, if they are from valid sources, simply are what they are. The organization that needs to support them within an IT system should not be told by that system (in an error message) that they can’t. It’s just as possible for the value of a name to be entered incorrectly using allowed characters, e.g. ‘Tom Bones’ entered rather than the actual name ‘Tom Jones’.

There should be a system-supported business process that allows an incorrect name to be corrected.

Coming in Part 7 — Attributes that Quantify

Read 798 times
Dan Tasker

The author of two books and numerous articles, Dan draws on over 20 years experience as a Business Analyst working across multiple industry sectors in four countries. He recently lead a volunteer project to create a complete end-to-end example of business, stakeholder, solution and transition requirements (awaiting potential publication by the IIBA).

He continues to be passionate about quality requirements and helping business analysts produce them.

Dan is always happy to receive feedback on his published works. He can be contacted at dantaskernz@gmail.com

© BA Times.com 2017

macgregor logo white web