Tag: Methodologies

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

Well-defined Data Part 5 – A Business Entity Identifier Attribute

Written by Dan Tasker on August 24, 2018. Posted in Articles.

Having explored the concept of business entity in Parts 2, 3, and 4 of this series, the objective of Part 5 is to examine one particular kind of attribute — the business entity identifier.

Its purpose is to uniquely identify an instance of a business entity. Users of an IT-based system are expected to have knowledge of, or access to, this value. The value is used to start down, or stay on, the ‘happy path’ of any business process that deals with a specific business entity instance.

The concept of business entity identifier is like, but not exactly the same, as the concept primary key. Every table in a relational database is expected to have a primary key. A primary key can, however, involve combining more than one column to achieve uniqueness. It also may not be exposed to business users.

IDs and Numbers

Business entity identifiers are all around us. Our wallets and mobile phones are filled with them — values that have been exposed by the organizations we deal with. If you see an attribute name that ends in “ID” or “Number” there’s a good chance that its values are intended to identify a specific instance either of that entity, or some instance somewhere. The assumption is that we will have that value available when interacting with the organization that produced that value. These values are embossed on our credit and debit cards. They are printed on our membership cards, our discount cards, our driver’s license. Every phone number, email address, and app-specific contact we record is a business entity identifier value. We use these values when we want to ‘reach’ a specific person or interact with the issuing organization.

From the perspective of an IT-based business system, there is no doubt that given sufficient attributes, such as name, address, phone, etc., we can uniquely identify entity instances representing a person or organization. Similarly, there are attributes of a product, a sale, or a location that, taken in combination, will lead us to the instance we are seeking. The point of a business entity identifier is that it’s a ‘one stop shop’ — a single value that, if known, will get a user to the specific instance they are looking for at a given point in time.

Multi-fact Business Entity Identifiers

The simplest form of business entity identifier is one based on a numeric sequence (e.g. the last assigned number plus one). This simple form is often used where values only need to be unique within the organization, and there is no need for the identifier to be meaningful in any way. Entities such as Purchase Order, Store, and Asset fall into this category within many organizations.

An example of an identifier that contains at least one fact is Credit Card Number. It appears to cardholders to be just a number. But because that number needs to be unique across all organizations that issue similar cards, the first six digits of each value identifies the issuing organization. The digits that follow those six can be generated any way a given organization chooses. Typically, six or more of these are assigned based on the ‘last assigned value plus one’ algorithm.

The attribute Stock Keeping Unit Number (SKU) is an example of an identifier that utilizes multiple facts to make up unique values of the business entity Inventory Item. A retail clothing business might create its unique SKUs based on the combination of an item’s brand, clothing type, style, size and color. For example, the SKU Number ‘LEV-JN-ST-34-BL’ representing the inventory item Levi jeans, straight leg, waist size 34 in blue.

When a business entity identifier contains one or more facts, those facts should also be defined as separate attributes in the same or some other entity. This eliminates the need for business users to ‘pick apart’ an identifier to find a given fact. E.g. Obtain a list of all Jeans with a 34-inch waist.
NOTE: Any fact included in a business entity identifier should ideally involve values that will not change over time. Having ‘exposed’ the identifier to the business, dealing with communicating a change is not productive for anyone. If you have ever changed your phone number or email address, and needed to notify family and friends, you will have some appreciation of the resulting effort and inconvenience.

Optimizing User Experience Accessing a Business Entity Instance

Keeping the following four things in mind will help optimize the user experience when a business process needs to involve a single business entity instance:

Maximise exposure to users
Minimize manual entry
Avoid finding a wrong instance
Offer backup ‘find’ options

Maximize exposure to users — When a business entity includes a business entity identifier attribute, that value should be ‘exposed’ where it will best serve the business processes that deal with single instances. An Employee Number can be displayed on the employee ID badge, and printed on employee payslips. An Asset ID can be printed on a label attached to the asset. A retail product that has a unique Barcode value registered by the manufacturer should have that barcode and its numeric value printed on each instance of that product.

Minimize manual entry — More and more these days, business information systems are being ‘front-ended’ with data capture technology, web portals, and apps. Input devices can read a barcode, a magnetic stripe, an embedded chip, or a value broadcast via radio frequency (an RFID). The trend is also towards self-serve, where customers use web portals or apps to connect to a business information system. A user Logon ID is an example of a business entity identifier — one that requires minimum data entry effort, thanks to web browsers or mobile devices offering to remember the user’s value for a given site or app.

Avoid finding a wrong instance — In situations where technology is not able to provide the value needed and the user needs to resort to manually entering the value to access a business entity, one of the most common data entry errors is transposing one or more digits. This can result in an entity instance being found, but not the one wanted. E.g. wanting the instance with identifier value 12345 but accidentally entering the value 12354. A commonly used technique for avoiding this type of error is the inclusion of a check-digit when generating the identifier.

Offer backup ‘find’ options — For every happy path there are any number of alternate or exception paths. At least one of these paths should support the user finding the desired entity instance when the correct business entity identifier value is not available. The values of one or more other attributes (or relationships) need to be able to be used to find the desired instance.

NOTE: Just as the business entity identifier is not the same thing as a database table’s primary key, ‘other attributes used to find an instance’ is not the same thing as the database concept alternate key. An alternate key value, like the primary key, is intended to find exactly one instance of a table. The business capability of searching using ‘other attributes’ is intended to reduce the candidate instances down to a shortlist from which the desired instance can be determined. For example, where Passenger “Fred Jones” has lost their ticket, and therefore does not know their Passenger ID, searching based on the Flight Number and Flight Date can return a list of passengers that may contain only one passenger named “Jones, Fred”.

So, while Flight Number plus Name would not be a valid alternate key in a database (because it doesn’t guarantee uniqueness), using those two values can turn out to be ‘close enough’ to get us back onto the happy path in a business search scenario. Typically search capabilities for business entities offer multiple filter criteria and present several attributes useful for identifying the instance being searched for.

Well-defined Business Entity Identifier Attributes

From a well-defined data perspective, an essential part of defining a business entity is identifying an attribute that can act as its business entity identifier. A business entity identifier needs a business-friendly, meaningful name. For the sake of the IT-based system responsible for creating new instances of the identifier, any ‘facts’ within the identifier need to be described and, at some point, specified in detail with regard to position, length, and valid values and/or value ranges.

Click here for Part 6 — Attributes that Name

Well-defined Data Part 4 – Products Customers Sales and Locations

Written by Dan Tasker on August 21, 2018. Posted in Articles.

This article discusses entities supporting the concepts product, customer, sale, and location.

The names given to these entities varies depending on the line(s) of business an organization is in and, in particular, the organization’s sales processes.

Product-Related Entities

The concept of product within the context of this series was defined in Part 3 as covering both goods and services, where ‘goods’ are things a customer can take ownership of and ‘services’ are resources a customer uses for a period of time. Goods have inventory levels (i.e. one or more instances available for purchase). Services have resource availability, at designated times (i.e. trained or qualified individuals to perform the service, and/or equipment appropriate to fulfil the service).

An entity representing an organization’s products will do so as a type, a batch, or as an instance.

Product Type – The products offered for sale by many organizations are not unique. For example, clothes, furniture, electronics, and pre-packaged food found in retail stores. A product type entity is used to record the name, size, price, etc., where values for these attributes apply to all instances of a given product.

Product Batch – Products that are mass-produced can have one or more things vary within their production process (e.g. involve batches of components or ingredients from different suppliers). When it’s critical to an organization to track these variations, a product batch entity is needed. Its purpose is to maintain details about critical variable elements. Each product instance produced as part of that batch is associated with its batch instance.

Product Instance – Some goods products are, by their nature, unique. Examples include property (i.e. real estate) and works of art. Other goods start life as similar, mass-produced instances, but can take on individual characteristics over time as the result of normal use, instance-specific modifications, or damage.

When an organization sells used, modified, or damaged goods, an entity representing each product instance is needed. That entity may make reference to the instance’s product type, if available, to represent its time-independent attributes. The product instance entity will need attributes similar to those of the product type entity, where a value that was common when the product was new can change over time. Plus additional attributes will be needed in the product instance entity to classify and describe its current condition.

In the case of service products, a product instance entity is not for the purpose of representing changes over time. Its objective is to represent specific ‘offerings’ of the service. Examples include appointment time-slots, rental availability periods, a specific scheduled flight on a route, the designated time and venue for the screening of a film, a live performance, or sporting event.

Well-defined data about products involves recognizing which of the above levels are needed by the organization, and naming those entities appropriately. When multiple levels are involved, product details (attributes and relationships) are included at the appropriate level, including the linking between levels.

Customer-Related Entities

An organization supports processes to maintain details about its customers within an IT-based system for one or both of the following reasons:

The organization has an ongoing relationship with, or obligation to, its customers in relation to the sale of one or more of its products (e.g. supply of electricity, a loan, an insurance policy).
The organization wants to be able to communicate with its customers to sell them additional products (e.g. the newest generation of a consumer product, a one-off service that a customer can benefit from periodically).

There are many organizations, such as those involved in retail sales, which sell their products to unknown customers. One mechanism commonly used by organizations to know who their customers are is a customer loyalty scheme. The customer provides their name and contact details in exchange for discounts or other forms of rewards. Another mechanism is warranty registration, where a manufacturer records the end-consumer of its products, even though the product was not sold directly to that individual.

Some organizations offer some or all of their products only to qualified customers. Banks only provide loans to credit-worthy customers, but offer savings accounts to any customer. Some educational organizations want only the ‘best possible’ students to fill their limited student numbers. Training organizations that have more availability than students will typically accept anyone that applies. Certain healthcare procedures may require a patient to be in an appropriate state of fitness. Specific government services may only be provided to persons of a given status.

Depending on the products an organization offers, and its sales processes, the types of customers it maintains in its IT-based system may be one or more of the following:

An Individual — a person able to provide enough information that they can be distinguished from other individuals within the IT-based system. E.g. name, address, phone number, government-issued ID number.

Multiple Individuals — two or more people who are jointly involved in the sale of a product. E.g. a joint bank account, a family mobile phone plan.

An Association – a named group of individuals associated through a common factor (e.g. a profession, sport, or hobby). The association itself may be the customer, or individuals members of the association.

A Registered Business — an individual or organization that has officially registered to operate as a legally entity. E.g. a sole trader, a corporation.

A Reseller – an individual or organization involved in the sale of an organization’s products, either with the intent of reselling the products to their own customers, distributing the products further down a supply chain, or acting on behalf of individuals or organizations (e.g. a travel agent). A reseller may be franchised to use the branding of the organization.

A Governmental Branch or Department — an organization unit within a governing body with authority to procure goods or services from external sources. E.g. The Army, The Department of Education, a state-owned enterprise.

A Registered Internet User — a person that has established a unique logon ID with an organization’s internet site. The organization operating the site may or may not have a business process that associates the user to an existing customer. In cases where it does, the user is not an additional customer, but an individual with access to one or more self-service capabilities on behalf of that customer.

Well-defined data about customers recognizes the line-of-business-specific name the organization uses to reference them, such as Client, Agent, Patient, or Resident. Attributes maintained for customers include name, contact details, and information applicable to repeatable sales events (e.g. account balance, available credit, medical history).

Sale-Related Entities

The concept of sale within the context of this series was defined in Part 3 as any type of event where a customer commits to consuming one or more of the organization’s products. Depending on the product(s) involved, and the organization’s end-to-end sale process, there may be pre or post-sale event events triggering activities within the end-to-end process. These activities can involve additional sale-related entities.

Pre-Sale — A pre-sale process may be triggered by a customer or the organization. Where a customer is seeking a product offered by a particular organization, the customer triggers the process. Examples of pre-sale activities within the sales process include the customer filling out an application or order that identifies the desired product(s), or requesting an appointment, quote, or reservation.

Where the organization proactively seeks a sale by contacting a customer, each contact event is supported by an activity that can result in an offer being made to the customer.

Having initiated a pre-sale process, there can be additional events and their associated activities that take place prior to formal commitment to the sale. Examples include the customer making a refundable deposit, the organization providing a quote, submitting a bid, drafting a statement of work, or the customer and organization negotiating a contract.

Sale Commitment — Within an organization’s sale process there will be at least one activity representing the customer and/or the organization formally committing to the sale. The customer can be said to place an order, sign a contract, or pay for a booking.

Post-Sale Events — Lastly, there may be post-sale events related to the product sold, that trigger activities within the end-to-end sale processes, and involving post-sale-related entities. From the customer side these may involve subsequent purchases or usage of the product within the terms of a contract, either incurring an additional charge or utilizing pre-paid credit. Or the return of a rented item.

From the organization side, a post-sale event may involve charging a periodic service fee. Or a product may be delivered subsequent to the sale (e.g. the operation of a scheduled flight or an entertainment event taking place that was ticketed in advance). Payment may be due, or overdue for a product that was sold on credit. A service may involve periodic reporting, such as the production of a statement of account.

Well-defined data about a sale includes all entities involved in the end-to-end sales process, naming them in accordance with the line of business and organizational terminology. Attributes maintained for these entities can include the event-related dates, quantities of usage, and amounts charged to or paid by the customer.

Location-Related Entities

The concept of location within the context of this series was defined in Part 3 as a place managed by the organization for the purpose of the selling or the consuming of its products. Examples include retail stores, hotels, library branches, and properties provisioned for usage of utility services such as water or electricity.

As with products, customers, and sales, the organization’s location types relate to a given line of business. Locations have a positional aspect and an operational aspect.

The position of an organization’s locations can be:

Area-based — one or more named geopolitically-defined areas (e.g. suburbs, cities, states/provinces, countries), or map-drawn and named by the organization (e.g. sales districts, service coverage areas).

Line-based — Two or more named points defining start, end, and any intermediate stopping points. E.g. passenger air, rail or bus routes, goods transportation routes.

Point-based — A place identifiable by address and/or map-based reference. This includes locations the organization provisions with sales-related staff, such as a retail store, hotel, or bank branch. It also includes residential and commercial properties the organization has provisioned with network-based access to its product (e.g. water, gas, fibre).

Sub-Location — An identifiable point or area within a larger location. E.g. a designated floor within a building, section or seat within a sports/entertainment venue, a specific storage location within a warehouse.

Where goods are involved, an organization cares about its locations from both an operational and inventory perspective. Operational in the sense of business hours and sales staff on hand during those hours.

Where services are involved there is additional need for service-appropriate resources to support advanced or ‘walk-in’ sales. E.g. flight crew, medical staff, a rental vehicle, an aircraft or ship to provide seating or cargo space.

Well-defined data about locations involves line-of-business-specific entity names. Attributes within those entities are needed to represent its position, operation, inventory and other required resources.

NOTE: Depending on organizational context, a location can be an area or a point. E.g. from the perspective of a city authority, the city is a bounded area, but from the perspective of an airline it is a point.

Click here for Part 5 — A Business Entity Identifier Attribute

The Requirements Process

Written by Mani Ramasarma on August 14, 2018. Posted in Articles. 1 Comment on The Requirements Process

While it is second nature to many of us I thought it would help to put this up here – the various steps involved in eliciting, documenting and baselining requirements.

Do not be overwhelmed by the number of steps, over time it will all flow in one seamless sequence.

1. Identify stakeholders

Who are the stakeholders? A person or persons with an interest or concern in something. Google and you will find anywhere between 4 and 14 types of stakeholders. I look at stakeholders as project stakeholders, requirements stakeholders, etc. There could be some overlap but not always. For example., a VP could be a project stakeholder but not a requirement stakeholder. Project stakeholders are generally listed in the Project charter/concept document. Requirements stakeholders will be listed in the BRD or any variant of that. Keep the following in mind:

These are folks who will be using the system or affected by the system
Identify any ongoing projects or upstream/downstream systems that are likely to be impacted
Include all people in your list of requirements stakeholders.

2. Do you have a Statement of Work (SOW)?

In case you are buying a COTS product and have released an RFP, it is very likely the RFP contains a SOW that defines the high-level scope of the project. Should there be none start by defining the high level scope. Why? It is easy to define high-level scope and then distill into the detailed requirements. The possibility of getting stuck in the weeds is way too high the other way around.

3. Organize the requirements kick-off session

Here are the things to do:

Invite all stakeholders, project, requirements, etc.
Set the agenda and stick to it
Lead the session
Explain the 5W’s and 1H – who, what where, when, why and how of requirements.
Elaborate the requirements quality – Correct, Unambiguous, Complete, Necessary, Feasible, Verifiable and Traceable
Insist that ‘you’ understand the requirements. Documenting is impossible without a good understanding of the requirements.
Record the session (Announce it at the beginning., not all organizations view this favorably)
Circulate the summary of the discussion and seek feedback on a no-objection basis

Many times the stakeholders are not aware of the aspects and quality standards of the requirements. They also are under the impression that you, the BA, and they are on the same wavelength and understanding. It is better to clear the air upfront.

4. Check and validate AS-IS process

If the organization maintains an updated AS-IS process, I recommend buying a lottery ticket! You may be really lucky. Have the AS-IS process validated by the stakeholders to ensure it is up to date. If you are not lucky, document the AS-IS process. Simultaneously prepare a stakeholder interaction map that represents what transpires between any and all stakeholders. This is important as it can identify stakeholders that were missed in the first step.

5. Document pain points

For each of the AS-IS business process identified above critically evaluate with stakeholders the pain points. One way to do this is to mark the points on the process flows where the stakeholders feel things could be improved. Unless you are re-engineering the whole process, the pain points must be addressed as part of the requirements. On your part identify steps in the process that do not add any value and discuss with stakeholders the alternatives.

6. Identify high-level requirements

SOW/ high-level scope and pain points should serve as a good starting point to come up with high-level requirements. Share the list with the stakeholders and identify any missing ones. Ideally, there should be no more than 8-10 high-level requirements. Provide no more than a few sentence descriptions for each of the high-level requirements.

7. Chose elicitation techniques

There are over 50 of them identified in the BABOK. Not all are relevant for eliciting requirements. Also, each situation may demand using different techniques or a combination of techniques. For example, if requirements are non-existent, use brain storming. If they are nebulous, use questionnaire.

8. Organize elicitation sessions

Have a precise agenda and invite relevant stakeholders. Not all requirement stakeholders need be present in all meetings. It is not a good use of their time. Manage the sessions as things can go off-track very quickly. Record the sessions so that they may play them back if things are not clear. Circulate summary of discussion the same day and seek feedback on a no-objection basis. Give a day’s gap between elicitation sessions for you to document the requirements else you may not remember all that was discussed.

9. Choose the right template

Do not overdo the template. They merely provide a structure to the requirements document. The content is very important. Focus on that. Standard BRD templates have many sections to fill. Discuss with your organization if some of these sections can be left out. Of course, certain sections like an overview, in scope and not in scope items are mandatory. AS-IS process and TO-BE processes can be documented separately and references in the BRD.

10. Document requirements

It’s now time to document the requirements. Keep these in mind:

Quality standards
Do not combine two requirements in a sentence
Use a simple, active voice
Ensure logical flow to requirements. For example., checking user authenticity must precede every other requirement
Re-read the requirements, confirm they make sense and there are no conflicting requirements
Avoid implementation details as part of business requirements. For example., system must support multi-threading or parallel processing or JSP’s or some similar thing.
Don’t let existing system cloud your thoughts
Provide examples and samples where possible. It provides a lot of clarity

11. Define test scenarios

V-model suggests that test scenarios must be created along with business requirements. Not just positive but also negative test scenarios must also be considered. This is one way of identifying missing requirements. The scenarios will be elaborated into test cases at a later stage. Keep the following in mind:

For each requirement identify one or more scenarios
Always include negative scenarios
Role based test scenarios must be considered if they are important
Downstream and/or upstream test scenarios are important if systems are going to be impacted

12. Peer review artifacts

This is absolutely essential. Share the BRD; AS-IS flows, pain points, test scenarios and all other artifacts with a peer or a senior BA. This will ensure the requirements are of quality and every requirement is captured. It also ensures the test scenarios provide complete coverage of all requirements.

13. Request feedback

Seek feedback from business users. Update artifacts based on feedback received. If required organize more elicitation sessions to seek clarity. Test scenarios may have to be changed if requirements undergo a change. This is an iterative process.

14. Conduct sign-off walkthrough with users

This is the comprehensive final walk through with business stakeholders. In other words, it is the final chance for users to make necessary modifications, clarify requirements or add details if required.

15. Conduct walk-through with technical team

In case of in-house development conduct a walkthrough with the technical team. It also applies to COTS products or external vendors. This ensures requirements are technically feasible to implement and may require re-defining of requirements. For COTS products it gives an opportunity for vendors to identify gaps and ways to bridge it. This leads to the design phase in a typical waterfall model.

16. Obtain sign-off from business stakeholders

The final step in the process wherein business stakeholders agree on the requirements. Once done the requirements are ring-fenced and final. Any subsequent changes will result in a change request.

17. Baseline requirements

The signed-off requirements will be officially considered the first version. All changes will be incorporated and updated in this version.

Here is the diagrammatic representation of the process

Well-defined Data Part 3 – Line-Of-Business-Specific Entities

Written by Dan Tasker on August 1, 2018. Posted in Articles. 1 Comment on Well-defined Data Part 3 – Line-Of-Business-Specific Entities

This series is about well-defined data within the context of IT-based business information systems. In this article and the next, entities specific to an organization’s line(s) of business are discussed.

These entities represent an organization’s products, customers, sales, and sales-related locations. They will be viewed within the context of five line-of-business functions. These functions, taken in sequence, represent the business processes that support any product as it goes through its lifecycle.

For the purpose of the discussion of line-of-business-specific entities, the terms product, customer, sale, and location are defined as follows:

Product — This term is intended to represent either goods or services offered by an organization to its customers. Goods are things the customer can take ownership of, subject to available inventory. Services are resources (types of or specific persons or things) used by the customer for a period of time, subject to availability at a given point in time.

Customer — This term is used to represent an individual, group, or organization that consumes the organization’s products. Common industry-specific synonyms for the term include account holder, passenger, patient, and resident.

Sale — This term is used to represent any type of event where a customer commits to consuming one or more of the organization’s products. A sale can be immediate, such as a grocery purchase. The consuming related to a sale of a long-running product is ongoing, such as water or electricity usage. A sale can be a commitment to consume a product in the future, such as a ticket for a scheduled airline flight or concert.

Location — Within the context of line-of-business entities, a location is a place managed by the organization for the purpose of selling or the consuming of its products. Examples include, retail stores, hotels, library branches, and properties provisioned for access to utility services such as water or electricity.

Lines of Business

A line of business centres on the products an organization offers for sale to customers. Unlike generic business entities such as Staff Member or General Ledger Account, which have entity names, attributes, and relationships common across all organizations, the entity names, attributes, and relationships for entities representing the line-of-business concepts product, customer, sale, and location differ widely from business to business.

For example, in the commercial airline line-of-business, the entity representing the concept customer is referred to as a Passenger. The sales process can start with a Reservation for space within a specified seating class on a scheduled Flight. The good news is that while line-of-business-specific entities vary widely in this way, they tend to be similar among organizations in a given line of business.

Every organization will have at least one product, and therefore one line of business. An example of an organization that has multiple lines of business is the Walt Disney Company. Its products include films, film-related merchandise, and its Disney-themed amusement parks, hotel accommodations, and cruises.

Line-of-Business Functions

Entities representing customers, products, sales, and locations differ between different lines of business. However, there are five business functions that, taken in sequence, represent the business processes that support any product as it goes through its lifecycle. These functions are Marketing, Product Development, Sales, Customer Care, and Product Decommissioning.

Figure 1 — Line of Business Functions Supporting a Product Through Its Lifecycle

While at the highest level the line-of-business functions are common for any product, the business processes within each function will vary due to the differences in the types of products, customers, sales, and locations involved — for example, booking films with movie theatre operators involves very different processes than renting hotel accommodations to travellers. But while processes within each of these functions will differ based on the specific line of business, the overall objective of each function is common for any type of product.

Marketing — The objective of marketing is to identify and maintain products that strike a balance between the organization’s goals and objectives, and the affordable needs or wants of customers (or potential customers). Product-related decisions include what new products should be offered, what changes, if any, should be made to existing products, and when to cease offering a product. These decisions may be supported by a business case that presents projected revenues, costs, and risks for one or more options.

When the organization decides to move ahead with an option, the product development phase of the product’s lifecycle begins.

Product Development — The objective of the product development function is to ‘bring the product to market’. Having decided to add, change, or decommission a product, things need to happen within the organization. The decision may be as simple as changing the price of an existing product, or as complex as adding a whole new line of business. Existing business processes may require changing, or whole new processes needed to be put into place.

If new or existing business processes are to be supported by an IT-based system, that system needs to be put in place, modified, or data within it updated (e.g. pricing changes). If an existing IT system is being replaced by a new one, migration of data may need to be carried out. Where staff are affected by changes to processes and/or an IT system, training needs to be conducted for those affected.

Only after all the necessary additions or changes have been successfully ‘put into production’ is the organization ready for the sales phase for the product.

Sales — The objective of the sales function is to get customers through the product’s sales process (ideally along the process’s happy path). Where a process involves an IT-based system, the product development phase has done (and tested) what’s required to support the process. The products and locations have been set up in the system and are ready to be referenced during the sales process. The process may include adding a new customer. It will certainly involve recording details relevant to the sale. For long-running products, there will be processes for recording consumption over time.

NOTE: Where customers are encouraged or allowed to self-serve, they must be able to gain access to the appropriate user interfaces. Given access, well-defined data includes their being able to understand what information they need to provide to successfully carry out a given self-service process, such as purchasing products, or maintaining account details.

When a customer has a problem or issue after a sale, or during the operation of a long-running product, the processes within the product’s customer care lifecycle phase come into play.

Customer Care — The objective of the customer care function is to deal with customers in situations where something has gone wrong, or appears to have gone wrong, with the product they have been sold. For example, it’s broken, or is believed to be broken. Or the normal operation of a customer’s long-running product is not operating correctly, or appears to be not operating correctly. Or a customer wants to return the product, or cease consuming a long-running product.

To resolve these types of customer-related issues, customer care staff need access to line-of-business-specific details about the organization’s products, customers, sales, and locations. Ideally these have been recorded in an IT system during product development, sales, and customer care phases of the product lifecycle. Where customers are provided with self-serve support options, such as frequently asked questions) those product-specific details should be accessible.

Product Decommissioning — The objective of the product decommissioning function is to end access to an existing product within the sales process. From an IT-based system perspective, it’s about preventing new instances of the sale event from occurring. For long-running products, where possible, existing customers would be switched to an alternate product that has been added as a successor product, or some other similar, available product.

Additional business processes within this function would include such things as notifying sales staff of the product being decommissioned, removing it from any advertising campaigns, and (at a designated point) curtailing customer care for it.

Having looked at the objectives of line-of-business functions that support any type of product going through its lifecycle, the next article will take a closer look at the four concepts representing line-of-business-specific entities.

Click here for Part 4 — Product, Customer, Sale, and Location Entities