In this article we focus on record name fields. These fields are intended to contain a user-recognizable value by which a person or thing is known, addressed, or referred to. Unlike a record business identifier field discussed in Part 5, a name field’s value may change over time. Also, there are ‘real world’ names for things (e.g. people, cities) for which valid duplicate values can exist.
NOTE: This article is Part 6 of Information System Data Fundamentals For Business Analysts. See Part 1 – Series Introduction for links to other articles in the series, plus definitions of the terms Information System, Record, and Field within the context of this series.
Name Field Value Uniqueness
Some information system records represent things ’owned’ by an organization. For example:
The organization has the right to assign name values, and to expect values for that record field to be unique.
Other information system records represent things external to the organization. For example:
- AREA (e.g. cities, countries)
The information system needs to ensure that the value for a given external record name field is correctly sourced, and as best as possible, kept in sync with any value changes that occur outside the organization. Relying on uniqueness of an external record field value depends on the organization’s ability to ‘trust’ the external source responsible for maintaining and providing values. E.g. an international standards organization.
Full, Abbreviated and Coded Names
When a record represents something that has named instances, there is a good chance that there will be requirements for more than one name field. Wherever names consist of several 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, its value contains full words. E.g. ‘Tee Hinge 200mm Zinc Plated’, ‘Human Resources Department’, ‘California’. Full name fields often have the term name or label as part of its field name.
Abbreviated Names – An abbreviated name is intended for ‘everyday use’ by the organization. Words making up a full name may be abbreviated, reduced to initials, or turned into 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 bare minimum amount of screen or report real estate. A cost of this space saving is the learning curve for new users of an information 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 fields often have the term code or the abbreviation cd as part of its field 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 thing is common across 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 to identify airports (e.g. ‘LAX’ for Los Angeles International Airport).
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 want to have coded versions of floor names (e.g. ‘G’, ‘5’, ‘P1’ ‘PH’).
Person Names
For records that represent persons, such as STAFF MEMBER or CUSTOMER, there are four fundamental name-types that may be needed to support an organization’s business process information needs:
- Legal Name — Required to support business processes that involve regulatory organizations such as tax authorities, where those organizations require identifying individuals (and companies) by their full legal name. E.g. ‘Thomas Albert Jones’.
- Contact Name — The name an individual 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, Tom’.
- User ID — The name chosen by or assigned to an online user of an information system. Typically it’s some version of the person’s name. These names can be required to be unique within the context of the system (but possibly allowed to change over time if required). E.g. ‘TJones’ for an internal user, ‘[email protected]’ for a user external to the organization.
When the information system is expected to treat the ‘parts’ of a person name as separately managed fields (e.g. First Name, Last Name, Middle Names), PERSON NAME should be considered its own record type containing a separate field for each meaningful part of a name. That allows those fields to be defined once and reused (related to) any number of records involving person names. (See PERSON NAME record and field examples in Trips-R-You Case Study Data Dictionary).
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', 'PhD', or 'QC'. If such prefixes and suffixes are intended to be selected from pre-established value sets they can be considered information about a name, but should be considered classification fields (see Part 9 – Classification Fields).
Name Field Properties
A name field should be within the context of a record that values are intended to identify, e.g. POSITION, GL ACCOUNT, STAFF MEMBER, CUSTOMER. For records whose instances have just one name, the field can simply be called Name. Ideally the field 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. Externally sourced name fields need to allow for enough characters to accommodate the longest possible ‘real world’ value. If not, then the process of capturing the name value needs to allow for it to be abbreviated or truncated to fit a system-imposed limit.
Each name field 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 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
Most 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. An organization that needs to support them within an information system should not be told by that system (in an error message) that it can’t accept a given value.
An information system can only do so much to validate name inputs. It’s possible for the value of a name to be entered incorrectly while still meeting all defined validation criteria. For example, ‘Tom Bones’ entered rather than the actual correct name ‘Tom Jones’. There should be a system capability that supports changing an incorrectly entered name value.
Next Article – Part 7 - Quantity Fields
Author: Dan Tasker
Dan is the author of over 30 requirements-related articles and other resources. His 45+ year career in Information Technology has involved organizations in a variety of industry sectors in the United States, Canada, Australia, and New Zealand. His business analysis experience includes projects involving in-house software development, software vendor solution development, and COTS software acquisition and implementation. He continues to be passionate about quality requirements and helping business analysts produce them. He can be contacted at [email protected].