Tag: Elicitation

This article discusses details, common to both attributes and relationships , which need to be sourced from business stakeholders.

The answers to five questions are necessary to support the design and development of data-related requirements within an IT-based system. Ideally your requirements template, tool, or data dictionary provides support for recording the answers to these questions.

For the purpose of this discussion, imagine a new regulation from a health and safety authority:

In the event of an emergency involving a staff member, that person’s manager must be able to contact that person’s designated emergency contact person.

Satisfying this regulation involves knowing each staff member’s emergency contact’s name and contact number, and managers having access to those details for each person they currently manage.

Question #1 – What are possible sources of values?

A vital part of business analysis is understanding and documenting the source(s) of values for each required attribute and relationship. These sources can be:

• External to the organization – via real-time or batch interface
• Internal to the organization – via online user or system interface
• Derivable – using other attributes and/or relationships
• A current context – e.g. the user logged on being the customer
• A default value – e.g. the current date

The two attributes required to satisfy the health and safety regulation would have a source internal to the organization.

Either the staff member directly, if the system allowed them to maintain certain of their personal details, or indirectly by an HR person.

Providing the appropriate manager access to these values would require a ‘Staff Member manages Staff Member’ relationship. Ideally the HR system already includes this relationship, maintained by an existing HR process.

The process might record the relationship directly, or it might be derivable, based on processes that maintain relationships such as ‘Staff Member is assigned to Position’ coupled with ‘Position manages Position’. The source of this relationship would be ‘internal’ for the direct relationship, or both ‘internal’ and ‘derivable’ for the indirect relationship.

Question #2 – Optional or mandatory?

There are actually five possible answers to the question, “Optional or mandatory?”

Optional – implies that for entity instances that have no value, there will be no impact to business operations, reporting, or system interfaces.

Should have – indicates that a value is wanted, but lack of a value will not impede business operations, reporting, or interfaces. An example of this is ‘cancellation reason’ for an order. Given only ‘optional or mandatory’, business stakeholders will opt for ‘mandatory’ because they want a value. But if a value is not critical, ‘should have’ is a more realistic option.

Conditionally mandatory – under some conditions, the value is optional, but under other conditions it becomes mandatory. For example, the start and end dates for a contract. These can be optional up until the point where the contract is ‘agreed’.

From that point forward the contract is expected to include the correct dates.

Mandatory by definition – there is no question, from a business perspective, that a value is required. Examples include instances of ‘appointment’ needing to have a date and time, or an ‘order line item’ needing to identify a product.

Mandatory (and correct) – the business expectation is that a value will be provided and that the value provided is correct.

Unfortunately from an IT-supported system perspective the old principle of ‘garbage in, garbage out’ can apply.

In our health and safety example, the two attributes both need to contain values. But what prevents a user from providing ‘Mickey Mouse’ as a name? Or a contact number is provided, but on entry, two of the digits are transposed? Or the values are initially correct, but circumstances change making that person not the most appropriate contact?

A business stakeholder, expecting ‘mandatory’ values to be correct, needs to understand that the IT system can, at best, guarantee a valid value. But where it’s critical for a value to be correct there need to be additional measures or business processes put in place to ensure data quality.

---

---

Question #3 – Will there be only one current value?

This question can be about a single attribute, a group of attributes, or a relationship (which points to an entity that contains a group of attributes).

Examples:

• Single attribute — a person’s music preferences.
• Group of attributes — a customer’s shipping address.
• Relationship — ‘position has assigned staff member’ (where job sharing of a position is allowed).

A hand-drawn screen wireframe can be useful when working with business stakeholders to address this question. The attribute or relationship is a fact about some business entity, so that entity represents the context for the wireframe. Including a few well-understood, single-value attributes (such as ID number and name) sets the scene for the attribute or relationship in question. Going with the position-to-staff member relationship, does the wireframe need to accommodate just one staff member? Or is a list of currently-assigned ones needed? Along with the list, the wireframe might offer some mechanism that allows adding or removing members of the list.

NOTE: From a usability perspective, non-functional requirements should address the issue of ‘standard look and feel’ for dealing with lists of data (e.g. paging, sorting, support for filter criteria).

Question #4 – Are historical or future values needed?

This question should always be a follow-on question to #3, regardless of the answer to that question. Note that question #4 should always be about need. Ask a business user if they want history kept and the answer will almost always be ‘yes’. But since there are always additional costs associated with maintaining and presenting history, there should be identifiable business processes and/or reporting that depend on access to historical values to justify maintaining it. Similarly, if one or more future values are needed there need to be processes that maintain them and utilize them.

Again, hand-drawn wireframes are useful to fully understand the business stakeholder’s needs for history and future values. See the article Point in Time Attributes.

Question #5 – Do value changes require an audit trail?

Question #4 was about having historical or future values available to support business processes. Question #5 is about traceability of changes (i.e. who changed what value to what other value, and when). Auditing is required primarily where money is involved, to prevent and/or prove fraudulent activity. But it can also be used to monitor any IT System usage behaviour.

As with question #4, where auditing of any attribute or relationship is an option, business stakeholders will often want that option for much of their data (rather than need it). What business stakeholders should be advised is that, unlike historical data (which is visible in support of business processes), audit data is ‘logged’. Access to audit logs is meant to occur only in exception circumstances, and those logs are typically not user-friendly.

That said, when there is a genuine business need for an audit trail, those attributes and relationships that require change tracking should be explicitly identified.

The Need for Answers

The good news is that none of these questions needs to (or should) be asked about attributes or relationships as part of high-level requirements (Business and Stakeholder requirements in IIBA BABoK ® terminology). See the article Keeping High-level Requirements High-level.

Question #1 – The answer to the source being internal or external can be asked at the business entity level. The answer at that level should be applicable to most of the attributes and a number of the relationships for that entity. It’s likely that only a few of an entity’s attributes or relationships will be derivable, have a default value, or source their value from a current context. But given the possibility, the question should be asked for each.

Question #s 2, 3 and 4 should be asked about each attribute and relationship when dealing with detail requirements (Solution and Transition requirements in IIBA BABoK® terminology). Detail data requirements are really not complete without business stakeholders committing to the answers to these questions.

Question #5 begins with auditability being included as a non-functional requirement. If it isn’t, then this question doesn’t apply. If it is a requirement, then it’s critical to know exactly which attributes and/or relationships require an audit trail.

Additional Attribute-specific Questions

This article has addressed questions that apply to any business entity attribute or relationship. When dealing with detail requirements, there are additional questions that need answering about attributes, depending on the type of attribute. For example, for an attribute representing a quantity, there are questions about its magnitude, precision and unit of measure.

For more information about the different types of attributes and their type-specific details, see the Well-defined Data series of articles.