Tag: Elicitation

Smart Business Analysts Ask the Obvious Questions

Written by Ryan McPherson on October 10, 2018. Posted in Articles.

“Never make assumptions” is some of the most popular advice given to business analysts. How not to is the obvious question that so rarely seems to have an answer included.

But let’s rewind and approach this from an entirely different angle. Let’s talk about asking obvious questions like that instead. Now I know we’re all fond of the saying “there are no stupid questions,” but we all know that twinge when we worry for just moment that a question might be too obvious. There are a bunch of reasons to ask these questions, though.

The first is to remove the stigma of expertise. Once people assume you’re an expert, they stop telling you things that they think you already know. This is maybe the most dangerous type of assumption: the kind others make on your behalf. You don’t know these assumptions are being made, and you have no way to discover them as they’re occurring. You might catch them in a requirements review session, or you might catch them in user acceptance testing, or you might catch them after you go-live. If you’re asking me though, I’d rather catch them much earlier than any of those touchpoints. If we make a point of verbalizing our thoughts when we catch ourselves thinking something like “this probably means”, we are actively encouraging people to talk to us like they’re training us, rather than as a peer.

Dispelling the illusion of expertise can also be vital in relaxing the room. When people are dealing with someone they perceive to be an expert, some folks will feel pressure to keep up with the expert, or to demonstrate their own expertise. This can often be exacerbated when their manager is in the room. Lots of people are understandably uncomfortable with having their experience and expertise being outshone in front of their boss. This can manifest in all kinds of counterproductive behaviours, but even if it doesn’t, why would we ever want a stakeholder, subject matter expert, or user to feel intimidated? This completely undermines any sense of engagement, and it’s how we can do all the right steps in building consensus and yet still end up with users that are adamantly opposed to change. Reducing resistance to change is one of the outcomes organizations typically expect when they make the investment to involve business analysts, so it’s important that we do everything in our power to ensure that we’re delivering in that area.

Another way that becoming less of an expert in the eyes of your stakeholders can be of benefit to you is that it tends to lead to more realistic expectations. I’m not suggesting that we should pursue lowered expectations as a means of achieving success more consistently, but it is important that the users we represent have a realistic impression of what we actually know. We often reveal to people aspects of the bigger picture that exist outside of their bubble, and this leads to an impression of being all-knowing. That sometimes translates into an assumption that we must know their piece of the process just as well, and we need to actively work against that. If user level stakeholders think you must know everything, they’ll be sorely disappointed when the solution you deliver doesn’t address their concerns. Even if those specific concerns never came up.

But in addition to improving the quality of our work, asking these types of questions can reduce the risk of project delays.

We can apply this general technique to business processes. Everything happens for reason, whether it’s a good one. Understanding why each stakeholder thinks each step is necessary, or what it accomplishes in the big picture prevents assumptions. Once you’ve got your swim lane diagram finished, it should be easy for you to point to any step and explain what its purpose is, or what business value we think we’re getting from it. If not, then you’ll risk finding yourself frequently having to decide whether we can make an assumption or if we need to do additional follow-up investigation. It usually doesn’t add much time to ask what the benefit or necessity of a given activity is, but it can add substantial delay to a project to have to schedule repeated follow-up meetings.

Asking the obvious question can also be an effective means of bridging resistance to change. If we think it’s possible that a process can be substantially improved by a change that the users or process owners may find radical, we may need to challenge some deeply held assumptions.

We can do that by trying to sell the change on its pros and cons, but this doesn’t instill a sense of ownership in the people affected by the change. Sometimes that’s acceptable. But where we encounter resistance, we might be wise to consider asking instead of telling.

We can dig into greater detail on the steps where we think there might be opportunity for change, which can naturally allow us to begin asking for more information on the purpose of those steps. By asking the obvious questions, we challenge our users and stakeholders to explain the reason behind a process, which brings them on board in thinking about it from a requirements perspective rather than a solution perspective. When they get to participate in discussing whether a change is viable from the perspective of trying to meet the underlying requirements, we get buy-in built into the solution.

Is this the answer to how not to make assumptions? It’s one way that might help. Where it doesn’t, I think you’ll still find ample value in asking anyways.

5 indicators that you are NOT thinking requirements

Written by Kumud Mishra on October 9, 2018. Posted in Articles. 1 Comment on 5 indicators that you are NOT thinking requirements

Often human minds are geared towards solving a problem, this task uses creativity, logic and it’s a fun thing to do.

As a Business Analyst professional we see this all the time, which can be sometimes challenging when we are trying to elicit requirements.

Sometimes there are other practical reasons why the stakeholders and the project team members might get into the solution mode before requirements definition. Examples of such are Cost (eliciting requirements takes time), Experience / Confidence (we know exactly what we want), Unclear or Disguised Agenda (solving the problem which is not part of the project scope but making it look like it’s the best fit for the project)

Whatever the reasons may be, one of the key aspects of the Business Analysis task is to get the breadth and the depth of the requirements based on the project stage. When we begin to talk about solution before the requirements we may not be utilizing full potential of the project resources including creativity, out-of-box thinking, expertise and experience that the team brings with them. Focusing on the solution before requirements definition comes with a risk, where the end product may not really address the problem, or may just solve a portion of the problem.

Here are five indicators that we are in solution mode before requirements definition

1. We need a new user interface that looks exactly like the user interface ‘A’ with different parameters.

Here the stakeholder is convinced that adding a new user interface similar to the existing one is what they want. Stakeholders have been very impressed with the existing interface and feel that having such an interface for other problem areas is the solution. The issue here is that the detailed implementation requirement is mentioned without clearly stating the business problem that needs to be solved.

2. It’s very simple, just add the new parameter into the existing calculation and it should work.

Here the stakeholder is convinced that adding the new parameter into the existing calculation should work. Are we changing the scope of the existing calculations? Has the business definition changed for what the calculation stands for? There might be downstream impacts of changing the existing calculation to represent something different. Again, without knowing the WHY it is difficult to say that adding an existing element will solve the problem (we don’t have the problem definition yet)

3. Just add these attributes to the user interface.

What are these new attributes, and what do they do? Do we have them in our organization domain or is it brand new concept to our organization? Is it captured elsewhere today? If yes how are we going to manage the updates? What would be the system of record for these new attributes? So many questions, and again the business problem is not identified.

4. We need to implement ‘Solution A’ because that is what other similar industries are using.

We need to understand the problem we are trying to solve by implementing ‘Solution A’. It may be a standard or a practice similar organizations may follow, but to compare we need to understand company culture, business relationships, team size, team hierarchy/structure, environment, etc., (tangibles and non-tangibles). Collecting such information objectively is harder than defining the actual business problem; because once we have the definition, we can get the solution that is best suited for our organization.

5. Buzz words – By using buzz word “zzz” all of our problems will be solved; we would not be in this mess.

Need to understand the concept that is relayed by the buzz word “zzz”; although we feel amazed by this new concept in the industry, we have to go through the scrutiny of understanding what problems can be addressed by this new concept. Again, it starts with a clear definition of the problem statement we are trying to address. Sometimes things may not be broken, but we may want to upgrade to new technology. Even if we decide to upgrade our existing unbroken system, we still need the rationale, the problem statement.

One of the ways to bring the project team members back to requirements is to clearly define the one or two key business problems/issues we are trying to solve as part of the project. Note that the real problem definition will not be in IT terms, it will be in business terms to explain why they need something.

Sometimes it is crucial to drill down to 4 or 5 whys to get to the root of the problem statement; note that understanding the rationale why something is needed is a very important in order to frame an accurate problem statement. This is the hardest part. Once this is defined, we need to declare the scope and then the train will be on the right tracks. If the business problem and requirements are defined clearly, with some degree of accuracy, the solution will fall in place.

Well-defined Data Part 8 – Attributes That Classify

Written by Dan Tasker on October 4, 2018. Posted in Articles.

A classification attribute allows the recording of a meaningful fact about an entity instance, with that fact drawn from a pre-established set of values.

Common forms for presenting a set of such values to users include drop-down lists, checkboxes and radio buttons.

This article will discuss three levels of complexity of attribute-based classification:

Self-defining — where the attribute represents something that is either true or not.
Value-only — where any one of the predefined values may be applicable to a given entity instance.
Complex — where one value that is applicable to an entity instance impacts other values that can be applicable to that instance.

Naming and maintaining value sets will also be discussed.

Self-defining Classification Attributes

A self-defining classification attribute is one where the fact it represents either applies or doesn’t apply to a given instance. Examples include a person holding a valid passport (or not) or eggs being from free-range chickens (or not). Because the valid set of values is a simple yes/no (or true/false) pair, it’s up to the attribute name and definition to provide the business meaning of a positive or negative value. The name of the attribute need only be descriptive enough to allow people to understand the general nature of the classification — e.g. ‘Has Valid Passport’, ‘Is Free-Range’. The attribute’s definition should provide further business details related to an appropriate choice in a given instance.

NOTE: It’s recommended that self-defining classification attributes represent the active (or positive) condition. This avoids responses that involve a double negative — e.g. ‘No Valid Passport’ requires a response of ‘No’ to indicate that the person actually has a valid passport.

Also worth noting is that there is a difference between a self-defining classification attribute and a classification attribute that has only two possible business values. For example, in accounting systems, a journal entry is classified as being either a ‘debit’ or a ‘credit’. It would be possible to define a classification attribute named ‘Is a Debit’, where a value ‘false’ implies that the entry is a credit. However, from a well-defined data perspective, the value set should be composed of the valid business values.

Value-only Classification Attributes

A value-only classification attribute is one where the only thing the organization cares about is the business-meaningful values in the classification scheme. These values may be made available for selection or be derived based on defined business rules. For example, a car dealership will classify each car by color, from a fixed value set relevant to their business, including ‘black’, ‘white’, ‘red’, etc. This set of values is sufficient for sales staff and car buyers to find all of the cars they are looking for in a specific color.

Conversely, to an organization that manufactures cars, paint color is a critical component in the manufacturing process. In this context, ‘paint color’ would be a full-fledged business entity with its own business entity identifier, plus naming, quantifying, and classification attributes of its own.

Complex Classification Attributes

A complex classification attribute is one that not only has a set of valid values, but those values involve relationships to other classification values. Continuing with the car business example, the dealership will deal with cars from different manufacturers, which will call for one value set for a car manufacturer and a second value set for the car model. There is a parent/child-type relationship between these two attributes, with a manufacturer being the parent of multiple car models. Implementation of a parent/child relationship in a user interface might involve the user initially selecting a parent value from one combo box and then selecting a child value from a second combo box, which would list only those child values relevant to the selected parent.

Another type of relationship between classification attribute values involves allowable transitions within the same value set. For example, consider the case of a business entity that has a defined set of status values, but the business wants to ensure that an instance is only allowed to transition to a selected subset of other values based on its current ‘status’ value. In addition to the value set, each value needs to identify the other values that it can transition to. State transition diagrams are good for graphically representing valid value transitions.

Classification Attribute Naming

The terms type, class, and category are often used when naming a classification attribute (e.g. ‘Customer Type’, ‘Product Category’, ‘Class of Service’). An organization’s users — familiar with existing business processes that involve one of these generically-named attributes — will also be familiar with their value sets. A classification attribute having a name that provides no clue regarding the classification scheme is only ‘well defined’ when examples of its values are available. For example, the name ‘Customer Type’ is, by itself, meaningless. Add example values ‘new’ and ‘existing’ and all becomes clear.

Value Set Change Process

The maintenance of value sets within an IT-based system typically takes place under the ‘Administration’ functionality. The process should ensure that all change requests originate from an authorized source. Users of the classification scheme ideally are given advance notice of any changes.

A value that becomes no longer applicable for the organization, and should therefore no longer be available for selection, should be end-dated rather than deleted. Similarly, a newly added value should have an effective date associated with it, unless all new values for a given classification scheme take effect immediately.

Additional complexity in changing a value set arises when the classification values are involved in business rules, process flows, or interfaces to other systems. Any added value needs to be accounted for in the rule specification, in existing or added process flow decision points, and/or interfaces. Both the value change and the associated system changes will need to be tested before they are put into production.

Well-defined Classification Attributes

The attribute should have the best name that the organization can provide. Similarly, the values, when textual, should also be as meaningful as possible. As with attributes that name (discussed in Part 6 of this series) the organization may want, in addition to the full ‘name’ of each value, an abbreviated and/or code value. When this is the case, these should be included as part of the definition.

At attribute definition time, the full value set may or may not be known or available. If not, or if it’s a large value set, enough examples should be included to make the classification scheme understandable. The definition should indicate whether the values are examples or they represent the complete value set.

Where classification values are derivable, that derivation should be identified, either as part of the definition or by referencing the derivation business rules (maintained separately).

The example values provided should be sufficient for designers to know what is needed from a database-definition perspective. The examples should be indicative of field size, data type, and precision if required for numeric value sets, and so these properties should not be required.

NOTE: As mentioned at the beginning of this article, there are a number of ways value sets can be presented in user interfaces (e.g. combo-boxes, checkboxes, radio buttons). Usability is a design issue and, as such, is outside the scope of this series.

Coming in Part 9 — Point in Time Attributes

Click here for Part 1 – Series Introduction

Well-defined Data Part 7 – Attributes that Quantify

Written by Dan Tasker on September 19, 2018. Posted in Articles.

Having discussed attributes intended to name entity instances in Part 6 of this series, we move on to attributes intended to satisfy the need to say something quantitatively about an instance.

Well-defined quantity attributes require particular attention be paid to their unit of measure (UoM) and precision.

Numbers verses Quantities

There are attributes whose values only contain numeric digits, such Credit Card Number. There are others, such as Part Number, whose name implies that values are numbers, but in some organizations, values of these attributes are allowed to include alphabetic characters. The objective of these sorts of attributes is actually to name or identify an entity instance, not to quantify it.

Genuine quantities have magnitude. A value can be bigger, smaller, or the same size as another value. If you double a quantity value (i.e. multiply it by 2), the resulting value is twice as big (unless of course the original value was zero). It would not make business sense to double a credit card number, or subtract one from another.

Unit(s) of Measure (UoM)

The following table contains types and examples of units of measure commonly used in relation to quantity attributes.

Type of Unit of Measure	Example Measurement Units
Length	Feet, Metres, Miles, Kilometres
Area	Square Feet, Square Metres
Volume	Cubic Feet, Cubic Metres, Gallons, Litres
Weight	Ounces, Tons, Grams, Kilograms
Time	Seconds, Hours, Days, Years
Temperature	Degrees Fahrenheit, Degrees Celsius
Power	Amps, Watts
Currency	US Dollars, GB Pounds, Euros
Count	Each, Carton
None	Percentage, Multiplier

NOTE: In the table above, ‘None’ represents types of quantities that are intended to be used in calculations but themselves have no unit of measure. E.g. An additional 10% discount, intended to be applied to the value contained in a ‘price’ attribute.

The unit of measure that applies to a given quantity attribute may be defined globally for the organization, apply to a number of attributes within a given entity, apply to a single attribute, or be different for each attribute instance.

Organizational Level — An organization may deal in a single unit of measure for a given measurement type. For example, the organization’s customers and suppliers are all local, and so all dealings with them are always in one currency. In such situations, the unit of measure can be defined once, as an assumption or as a non-functional requirement. E.g. “All currency amounts represent US Dollars.”

Entity Level — An entity may contain a number of quantity attributes that are of the same unit of measure type, and for any given instance, all of the quantities involving that UoM type will be of the same units. E.g. An Order entity with attributes Net Amount, Tax, and Gross Amount all being in a given currency for an order. Each of these attributes can be identified as the “Currency” UoM type and a separate Currency attribute in the entity used to identify the specific currency that applies for a given order instance.

Attribute Level — A quantity attribute within an entity can always involve values of the same unit of measure. E.g. Hours Worked. Even if the UoM is part of the attribute name, it should still be defined explicitly as a property of the attribute within the data dictionary.

Entity Instance Level — In an entity where a quantity attribute can involve a different UoM per instance, one or more additional attributes will be required to identify the unit(s) that apply. E.g. A Service Contract with the quantity attribute Charge-out Rate, where for one instance the rate can be in US Dollars per hour and for another in Euros per day. In the service contract example there would need to be one attribute to capture the currency type and another for the applicable unit of time.

Precision

For most quantity attributes, their precision can be specified as a number of decimal places required by the organization. E.g. integer indicating no decimal places, or cents for currency quantities, implying two decimal places. The following are examples of precision that require special attention when defining the quantity attribute.

Smallest Reportable Time Increment — Many time recording systems capture the time worked in hours and portions of an hour. Typically, those portions of hours are restricted to specific increments. If the portions are in units of minutes, the precision may actually be limited to increments of 15 (i.e. 0, 15, 30 or 45). If the hours being recorded allow decimal values, up to two decimal places are allowed, but the actual precision may be limited to quarters of an hour (.25, .5, .75).

Orders of Magnitude Quantities — Where a quantity attribute represents what an organization considers a very large amount, the precision can be defined as an order of magnitude. E.g. the value 1 intended to represent one million, or one billion. The order of magnitude quantity could be defined to allow some number of decimal places, e.g. 1.3 indicating the value ‘one million, three hundred thousand’.

Sources of Quantity Values

As with other types of data, quantity values can be provided from sources external to the organization or from internal sources. A third source, in the case of quantity attributes, is derivations.

Externally-Sourced Values — Quantities that are sourced externally in real-time can be validated individually. The real-time process should be designed to deal with an invalid value, preventing the process from completing successfully if necessary. When batches of records containing quantities are received, the business needs to decide how it wants to deal with errors — either rejecting only those records that have problems or rejecting the entire batch, until the invalid values have been dealt with.

Internally-Sourced Values — When a quantity is sourced internally, it is useful to identify the organizational role(s) that have responsibility for providing values. Some quantities, often price-related, are decided by product owners. Other quantities are simply part of an operational process, where staff members record values that come to them as part of the process. Where money is involved, and potentially large amounts, there is often a ‘separation of duty’ (SOD) process where a dollar value is entered by one person but required to be validated by a second person before the process is allowed to complete.

Derivable Values — Where two or more values from different attributes are used to produce a new value of interest to the organization, an attribute should be defined to represent the derived value, associated with the entity it quantifies. The derivation should be described as part of that attribute’s definition. NOTE:

The derived attribute represents values that are meaningful to the business. Designers are left to decide whether a derived value should be physically stored, or derived as needed.

Both UoM and precision are important when defining a derivation. As the saying goes, “You can’t add apples and oranges.” Also to be considered is where two or more quantities are of the same units, but of different orders of magnitude. Those magnitudes will need to be brought into alignment within the derivation.

NOTE: Where derivations involve more than multiplying or dividing two or more decimal values, rounding can be an issue. Where and how to round is outside the scope of these articles.

Well-defined Quantity Attributes

From a data dictionary template perspective, a well-defined quantity attribute should have the following quantity-specific properties addressed:

Unit(s) of measure — Even if the attribute name says something about its units, the unit(s) should be identified explicitly. Where the unit(s) vary per instance and are captured in a separate attribute, that attribute should be referenced.
Precision — Most often a simple statement of the number of decimal places. Exceptions, as discussed above, should be described in text.
Maximum — The business question that should be answered by a subject matter expert is, “What’s the largest value of this quantity ever encountered or that needs to be catered for?” NOTE: Using nines (e.g. 999,999) to describe a large value is not business oriented. If, for example, the answer to the question is ‘850,000’ then designers will understand what’s required.
Can be negative? — yes/no
Zero ok? — yes/no
Derivation — For the attribute being derived, a business definition or rule describing it. This can be in the form of an algebraic formula, a step-by-step process, a flow chart, or formal business rule definition language. Ideally one or more worked examples containing realistic values would be included.

Coming in Part 8 —Attributes That Classify

Well-defined Data Part 6 – Attributes that Name

Written by Dan Tasker on September 13, 2018. Posted in Articles.

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).

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’, ‘[email protected]’.

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