Author: Graeme C. Simsion and Graham C. Witt Chapter 9 Understanding the Business Requirements.

Author: Graeme C. Simsion and Graham C. Witt

Chapter 9Understanding the Business

Requirements

Copyright: ©2005 by Elsevier Inc. All rights reserved. 2

The story thus far…• We have learned the drawing conventions

and a few structural principles.

• The real challenges of understanding a set of business requirements and designing a sound data model remains.

• This lecture we cover the overall process of forming a data model (including its maintenance) and gathering business requirements in the context of the process of data modeling


Challenges in the ‘real world’

• Data modelers work in the context of an information systems development or enhancement project, or a program of change that requires the development of several databases.

• Challenges loom:– ensuring that the project plan allows for the development

and proper use of high quality data models.– developing a series of deliverables that will culminate in a

complete physical data model and, along the way, provide sufficient information for other participants in the project to carry out their work.

– ensuring adaptability of data models and databases (if important)


Roles and Responsibilities

• How many and what sort of people should participate in the development of a data model? Two extremes:– a specialist data modeler, working largely alone and

gathering information from documentation and one-on-one interviews, and

– joint applications development (JAD) style of session, which brings business people, data modelers, and other systems staff together in facilitated workshops.

• key objectives: (a) we want to produce the best possible models at each stage, and (b) we need to have them accepted by all stakeholders.


Satisfying the Objectives

• Involve a a fairly large group of people, firstly to maximize the “brainstorming” power– Not constant involvement – Allow for reflection to maximize brainstorming

• Build commitment to the result. • Delegated some tasks to one or two people, with the

group being responsible for checking the result.– diagram production, detailed entity class and attribute

definition, and follow-up of business issues that are beyond the expertise of the group.


A useful tip• Nominate a small core team: one or two specialist data modelers

and a subject matter expert • Gather a larger team of other stakeholders:

– further owner/user representatives, process modelers, a member of the physical database design team, and perhaps a more senior experienced data modeler.

– may include subject area specialists, the project manager(s), and the data administrator.

• The larger team meets regularly to discuss the model:– initial stages, focus on generating ideas and exploring alternatives. Later,

review and verify.

• The smaller team manages the process:– developing ideas into workable models, ensuring that the models are

technically sound, preparing material for review, and incorporating suggestions for change.


Typical process/stages and deliverables in data modeling

DesignPhysical

Data Model

DesignLogical

Data Model

BuildConceptualData Model

DevelopInformation

Requirements

Data Modeler

Database Designer

BusinessSpecialist

ReviewInformation

Requirements

BusinessSpecialist

ReviewConceptualData Model

ReviewLogical

Data Model

ReviewPhysical

Data Model

Data Modeler

Database Designer

Business Requirements

Information Requirements

DBMS & Platform

Specification

Performance Requirements

Conceptual Data Model

Logical Data Model

Physical Data Model


Maintaining the Model• changes during a model’s development are inevitable

(apart from usual iteration).– changes in scope or requirements that may arise during the

project, – The data modeler’s understanding of requirements will

grow as further interactions occur with stakeholders. – stakeholders increasingly understand the implications of

the system proposed

• it makes good sense to publish an early draft to check that requirements are “in the ballpark”.– Refinement often involves generalizations and Entity Class

or attribute renaming


Managing Change in the Modeling Process

• many changes to the data model are “long transactions.”– produce a list of intended changes before actually making

them.– Each change decision should be listed in business terms,

followed by the individual types of model changes that are required, for example:

• Addition of entity classes or relationships• Changes to the attributes of an entity class• Moving attributes/relationships• Changing relationship cardinality• Changing identification data items• Renaming


Essential Deliverables

• Whatever formal or informal data modeling methodology you are using, the data modeling process should deliver:– A broad summary of requirements

covering scope, objectives, and future business directions.

– Inputs to the model: interview summaries, reverse-engineered models, process models, etc.

– A conceptual data model

– Entity class definitions, and attribute lists, and attribute definitions for every entity class in the model

– Documentation of constraints and business rules that cannot be put in a diagram

– A logical data model– Design notes covering

decisions made in translating the conceptual model to a logical model

– Cross-reference to the process model

– Higher level and local versions of the model to facilitate presentation (as necessary).

– A physical data model


Gathering Requirements• Good design begins with an understanding of the big

picture and will take the form of (a) written structured deliverables and (b) knowledge that may never be formally recorded, but that will inform data modelers’ decisions.

• This early phase in a project provides an excellent opportunity to build relationships with the business stakeholders and the other systems developers.

• Sources of information:– The business case for the project(s) influencing the data modelling

task– Interviews and workshops– Riding the Trucks– Existing Systems– Organisational Processes

• We cover this in the remainder of this lecture


The Business Case• In reviewing a business case, you should take particular

note of the following matters:– The broad justification for the application, beneficiaries,

and those disadvantaged (if applicable).– The business concepts, rules, and terminology.– The critical success factors for the system.– The scope of the system.– System size and timeframes.– Performance-related information.– Management information requirements for the system to

meet.– The expected lifetime and likely changes.– Interfaces to other systems (internal and external)


Interviews and Workshops

• Essential for requirements gathering.• Rule: invite

– (a) the people whom we believe collectively understand the requirements of the system and

– (b) anyone likely to say, after the task is complete, “why wasn’t I asked?”

• Be wary of being directed to the “user representative”—the single person delegated to answer all of your questions about the business — (the real users get on with his/her work)


Should You Model in Interviews and Workshops?

• Use anything but data models.• Data models are not a comfortable language for

most business people (they prefer activities).• You need to be able to accept all terms offered

by stakeholders, be they entity classes, attributes, relationships, classification schemes, categories or even instances of any of these.


Interviews with Senior Managers

• CEOs and other senior managers are usually the best placed to paint a picture of future directions (future context for database(s)).

• Keep time demands limited and explain in concise terms the importance of the manager’s contribution to the success of the system.

• Ensure that you are familiar with their area of business and focus on future directions.

• Be aware of what the project as a whole will deliver for the interviewee.


Interviews with Subject Matter Experts

• These are the people we speak to in order to understand the data requirements in depth. Encourage them to talk about the processes and the data they use and to look critically at how well their needs are met.

• A goal and process based approach is often the best structure for the interview.– “What is the purpose of what you do?” – This leads to an examination of how the goals are

achieved and what data is (ideally) required to support them.


Facilitated Workshops• These are great for identifying and verifying requirements

by brainstorming, and ensuring that a wide range of stakeholders have an opportunity to contribute.

• Some guidelines:– Use an experienced facilitator– If your expertise is in data modeling, avoid facilitating

the workshop yourself.– Give the facilitator time to prepare an approach and

discuss it with you.– Appoint an informed note-taker– Avoid “modeling as you go.”– Do not try to solve everything in the workshop.


Riding the Trucks• Spend time with the hands-on users of the

existing system as they go about their day-to-day work. When you do, look for, :– Variations in practices and interpretation of business

rules at different locations– Variations in understanding of the meaning of data.– Terminology used by the real users of the system– Availability and correct use of data (on several

occasions we have heard, “No-one ever looks at this field, so we just make it up.”)

– Misuse or undocumented use of data fields (“Everyone knows that an ‘F’ at the beginning of the comment field signifies a difficult customer.”)


Existing Systems and Reverse Engineering

• Existing database designs provide a set of entity classes, relationships, and attributes that we can use to ask the question, “How does our new model support this?”

• If you are very fortunate, the underlying data model will be properly documented. Otherwise, you should produce at least an E-R diagram, short definitions, and attribute lists by “reverse engineering”:– Represent existing files, segments, record types, tables, or

equivalents as entity classes.– Normalize.– Identify relationships supported by “hard links.”– Identify relationships supported by foreign keys.– List the attributes for each entity class and define each entity class

and attribute.


Process Models• The data required by individual processes may be

documented explicitly (e.g., as data stores) or implicitly within the process description (e.g., “Amend product price on invoice.”).

• You must verify the data model against the process model when it is available and allow time for enhancement of the data model.

• A one or two level data flow diagram or interaction diagram a valuable adjunct to communicating the impact of different data models on the system as a whole.


On to modeling itself…

• Now we are ready to commence conceptual data modeling

• Next lecture we cover– The process of data modeling uncovered– Starting modeling (with conceptual data modeling)– Patterns and Generic Models– When there is no pattern– Overwhelming complexity

Author: Graeme C. Simsion and Graham C. Witt Chapter 9 Understanding the Business Requirements.

Documents

data administrator

sound data model

specialist data modelers

adaptability of data

process of data modeling

complete physical data

real world data modelers

business people