1. technology and computing
2. software
3. databases

the
CONNECTING BUSINESS REQUIREMENTS TO TECHNOLOGY
Fall/Winter 2004
Why Does
a Business
Analyst Need
to Worry
About Data?
Book Review
Data Modeling
Essentials
Ask the Experts
Data Requirements for
a Maintenance Project
Tool Review
AllFusion ERwin
Data Modeler
Project Manager’s
Role in Gathering
Requirements
letter from the editors
or our second issue of the bridge, we decided to highlight the importance of Data Requirements as part of
F
business analysis. Business data or information is an organization’s most valuable asset. This is a topic that
often comes to light after a system implementation when a major data requirement was missed or defined
incorrectly in a mission critical system. Most organizations feel that they have other roles responsible for data:
Database Designers, Data Warehouse Architectures, or others in IT. These roles maintain the computerized
storage of information, but the Business Analyst should identify the data important to the business and
communicate to IT that it needs to be stored.
We encourage you to read the articles on pages 3 and 11 which highlight why we feel so strongly about the
need for Business Analysts to completely define and detail the Data Requirements in addition to the other
requirements. Also included in this issue is an article on tips for Project Managers to utilize Business Analysts to
the fullest during analysis. A book review for those that wish to learn more about Data Modeling is included
along with a tool that is widely used in the industry for defining logical and physical data models/requirements,
CA’s AllFusion ERwin.
Between issues of the bridge, we invite you to visit our website frequently for current articles relevant to
Business Analysts, upcoming events, tool reviews and others. These can be found on our new BA Resources page
and we welcome suggestions or submissions for inclusion in the future. On our Certification page, you can find
up to date information on the program. The Certification program continues to be strong with approximately
60 people certified to date. The proficiency exams are now administered online to speed results and feedback to
candidates.
We look forward to seeing some of you at upcoming events and are always interested in learning about any
additional events that we should know about. The Business Analyst community is growing at a rapid pace and
we are excited to be a part of its growth. Please let us know of any information that would be interesting or
helpful for future issues of the bridge.
TINA JOSEPH
Certified Woman Owned
Small Business
BARBARA CARKENORD
the
Fall/Winter 2004
volume 1 l issue 2
table of contents
3
Why Does a Business Analyst Need
to Worry About Data?
5
Book Review
5
Ask the Experts
6
7
A Project Manager’s Role in Gathering Requirements
Page 5
Page 7
Data Modeling Essentials: Analysis, Design, and Innovation
by Graeme C. Simsion
Should I Gather Data Requirements for a Maintenance Project?
Did You Know?
Page 3
Data Models in MS Visio Professional
8
9
10
Business Analyst Certification Program
11
12
Lost in Translation
13
14
B2T Training Core Courses
Data Brain Teaser
Update
International Institute of Business Analysts
Tool Review
AllFusion ERwin Data Modeler
B2T Training Additional Course Offerings
B2T Training • 11795 Northfall Lane, Suite 601 • Alpharetta, GA 30004 • 865-675-2125
B2T Training is a woman-owned small business based in Atlanta, GA. Our training focuses on proven skills
and techniques to define and scope the business problem, gather requirements, document the requirements,
model the requirements, and follow through with the development of business requirements test plans to
ensure the project has met its defined objectives.
Our training is offered nationally and on a limited international basis. Most of our classes are taught onsite
and are tailored to the unique environments of each organization. Public classes are also available in various
cities around the US.
Vice President, Sales and Marketing
Tina Joseph
Vice President, Training
Barbara A. Carkenord
Director of Business Development
Angie Perris
©2004 B2T Training. All rights reserved.
the bridge l Fall/Winter 2004 2
Why Does a
Business Analyst
Need to Worry
About Data?
I
BY B A R B A R A A . C A R K E N O R D
V P, T R A I N I N G , B 2 T T R A I N I N G
t’s no accident when the right
information is available. Gathering
and documenting business data
requirements is a critical success factor in
all application development projects
because data is needed to perform every
business process. An excellent Business
Analyst knows the importance of these
data requirements and knows how to elicit
them from their Subject Matter Experts
(SME).
Computer systems initially were called
Data Processing because they process data.
They have been called Information
Systems because they process information.
The most amazing aspect of technology
today is the immense amount of
information that can be stored in tiny
chips and on thin metal disks. This
information or data provides the raw
materials for all of the sophisticated
software and hardware systems that are
used constantly in our organizations. Can
you imagine looking up your customer’s
address in a filing cabinet?
But with all of the sophistication of
information systems and database
management systems, many of our
applications are less than perfect. Users
have developed “work-arounds” and
invented codes that allow them to keep
track of information that the system was
not designed to manage. How can all of
our sophisticated technology still have so
3 Fall/Winter 2004 l the bridge
many flaws? One reason is that we didn’t
think about data requirements early
enough in the development project.
Data is the most important part of an
application system. A good, strong,
accurate data structure allows developers to
design any processing, reporting, or
statistical analysis ever needed. The most
elegant, high-tech system in the world will
be shelved if it does not provide access to
the correct business data.
Every business process uses data, every
business rule depends on data. Failing to
identify data requirements puts your project
at a huge risk. (See chart below for examples.)
Using a Logical Data Model to
document data requirements
A logical data model is a picture of all the
pieces of information necessary to run the
business. The logical data model is built
using an Entity Relationship Diagram
(ERD) – a standard modeling technique
used by data modelers around the world.
Entity relationship diagramming is a
structured technique used by business
analysts and technical developers as a
communication tool. It provides a
complete picture of the business data
requirements. (See diagram next page)
The components of a logical data model
include Entities, Relationships, and
Attributes. Each entity represents a set of
persons, things, or concepts about which the
business needs information. Each relationship
represents an association between two entities
– they represent data related business rules.
Each attribute is a characteristic or piece of
information that further describes an entity.
A name and textual definition describe each
Business Process
Business Data
Record customer order
Customer number, name, shipping address, phone
Order number, date
Product order quantity, price, weight
Bill customer
Customer number, contact name, billing address
Invoice number, amount, date
Business Rule
Business Data
Orders totaling over $500
are shipped for free
Order total dollar amount
Customer shipping address
Preferred customers are
given a discount
Customer type, discount percentage
Order number, total dollar amount before discount,
discounted dollar amount
of these components. These names and
definitions provide ongoing documentation
of the business rules and data requirements
of the business area. These three core
requirements components can capture and
clearly represent the most complex data that
your organization uses.
business requirements. Database designers
start their design with a complete picture of
the business requirements and can then
determine the best implementation approach.
A logical data model also facilitates data
re-use and sharing. Data is stable over time;
therefore, the model remains stable over
go much smoother and faster. A model is
easier and cheaper to modify; mistakes,
missed data, and misinterpretations are less
costly when corrected in a model than in an
implemented system. It also decreases user
requests for changes. When changes are
necessary, the logical model can be used for
impact analysis.
Logical Data Model built using an Entity Relationship Diagram
Who uses the logical data model?
Why build a logical data model?
The most important reason to build a
logical data model is to confirm the users’
and analysts’ understanding of the business
data requirements to assure that the
software developed satisfies the business
need. Logical data modeling provides the
analyst with a structured tool and technique
to conduct analysis. Most SMEs can
articulate problems and possible solutions,
unfortunately their problems and solutions
are often based on current system constraints,
not true business needs. Asking business
people to detail every piece of data
(attribute), requires them to understand
and articulate every aspect of their business.
This approach allows the business to drive
the system design, not the other way
around. It also stimulates more detailed
discussion and thoughts. By identifying and
detailing data in a model, further
requirements and problem areas arise and
are dealt with long before software design.
A logical data model is a foundation for
designing a database that supports the
time. As additional project teams scope out
their project areas, they can re-use the model
components that are shared by the business.
This leads to physical data sharing and less
storage of redundant data. It also helps the
organization recognize that information is
an organization –wide resource, not the
property of one department or another.
Data sharing makes the organization more
cohesive and increases the quality of service
to outside customers and suppliers.
Having business data requirements well
documented allows quick impact analysis
when a business change request comes
along. Analysts with access to a logical data
model can review the model and offer
suggestions for implementing changes
along with quickly being able to ascertain
the complexity of the change.
In summary, building and maintaining a
logical data model decreases system
development and maintenance time and
cost. Identifying all business requirements at
the beginning of a project makes the design,
coding, testing, and implementation phases
The SMEs own the logical data model. It
represents all the information needs of the
business area. They describe their data
requirements to the business analyst and
review the requirements created. They use
the model to confirm that the Business
Analyst understands the business needs.
Business Analysts elicit data requirements
by reviewing existing data sources and by
asking key questions during interviews and
facilitated sessions. The analyst documents
the data requirements using entities,
relationships, and attributes creating a
model of the data. The analyst also uses
the data requirements to detail process
requirements. Every business process uses
data so cross-referencing process to data
provides a thorough verification. The
Business Analyst gets signoff on the data
requirements from the SMEs and works
with the database designer to transition this
business data into a database design.
The database designer builds a physical
data structure to support the business needs.
The designer reviews the logical data model,
along with the processes that access the data
to determine the best implementation
approach. Giving the database designer a
complete picture of the business needs
allows him or her to understand the overall
application and create a system architecture
that is well organized and flexible. A strong,
coherent data structure will be useful to the
organization for many years, maybe decades.
What happens if you don’t document
business data requirements?
When users are not asked to focus on data
as a critical part of a system design, they
Continued on page 10
the bridge l Fall/Winter 2004 4
book review
Data Modeling Essentials: Analysis, Design, and Innovation
by Graeme C. Simsion
R E V I E W E D F O R B 2 T T R A I N I N G BY BA R BA R A A . C A R K E N O R D
ata Modeling Essentials is a fresh look
at an old topic. Since data modeling
was developed in the 1970’s numerous
authors have
written books
that described
the process of
documenting
data requirements in a
model and
refining it
using data
This book is available
normalization
at b2ttraining.com.
rules. Often
D
these books were very technical and lacking
in real world examples.
Data Modeling Essentials is much more
accessible and refreshing in its tone and
attitude. Simsion’s explanations are very
clear and his examples easy to follow.
Simsion presents normalization rules with
simplicity and clarity. The reasons behind
each concept are efficiently described while
giving the reader confidence in the
recommendations. Simsion also provides
excellent suggestions for naming
conventions, presentation formats and for
eliciting these requirements from Subject
Matter Experts. This book is useful for
both beginners and experienced data
modelers who want a new innovative
approach to the important task of
documenting data requirements. A revised
third edition with expanded examples will
be available late October 2004. ■
Barbara A. Carkenord is the Vice President
of Training at B2T Training. She has
worked in the requirements gathering and
documentation field for over 20 years and has
conducted hundreds of seminars for Business
Analysts. Comments are welcome at
[email protected].
ask the experts
Should I Gather Data Requirements for a Maintenance Project?
ost of the projects that we work on
are not brand new software
development projects, but rather changes
to existing software or interfaces. On these
maintenance projects, the Project Manager
and Business Analyst must make decisions
about the type of requirements needed and
the time to be spent in requirements
gathering. One of the questions that must
be answered during project initiation is:
Should I gather and document data
requirements?
Initially the answer seems obvious. If
the requested change is asking for us to
track a new piece of information then we
need data requirements; otherwise no. But
be careful jumping to the obvious
conclusion. Remember that data is used
everywhere in an application, so any
change may impact data.
Ideally data requirements were
documented for the original project so that
the Business Analyst can refer back to them
and assess the impact of a change. But if the
data requirements were not documented
initially, here are some suggestions for what
to document and when.
M
5 Fall/Winter 2004 l the bridge
• If the user has requested a new report,
document all of the business data required
to generate the report. Remember, not the
data to be displayed on the report, the
data needed to generate it. Many fields on
reports are calculated fields. You need to
capture the core data elements that are
needed to perform the calculation. Once
you have documented all of these data
requirements, meet with your database
administrator to find out if all of these
data elements are currently stored in a
database. It is helpful to document their
physical name and storage location for
future reference. This is referred to as “gap
analysis”. If any data elements are missing,
a database change will be required.
• If the user has requested a new screen,
document all of the data required on the
screen and possibly behind the screen to
support the data entry or inquiry
requested. Again, once the data
requirements are documented, meet with
your database administrator to verify that
these fields are available (and are
formatted in the same way).
• If the user has requested a format
change on an existing screen or report,
you probably don’t need to document data
requirements, just the change in the way
the data is presented.
• If the user has requested a new business
process that must be automated,
document all of the data requirements for
the new process along with the process
description and associated business rules.
A new business process almost always
means new data requirements.
• If the user request involves changes to
business rules, be sure to analyze the data
used by each business rule and make sure
the data elements needed are available.
In the humble opinion of this “data bigot”
there are very few projects where data requirements
can be omitted. A good analyst always thinks
about data as well as process and business rules
when planning their analysis work. ■
Send your questions to Ask the Experts at
[email protected].
A Project Manager’s Role in
Gathering Requirements
BY A L I I BA RG U E N , P M P,
BLUEPRINT PM, LLC
A
s a project manager, I want to ensure
that my data requirements gathering is
well-planned and that the plan contains all
of the tasks I need to deliver a successful
project. How do I do that? How do I
ensure that my Business Analyst has the
power they need to get their job done?
Let’s review some key points for
accomplishing just that.
1. Involve the Business Analyst in the
project kickoff. The first task once a
project is defined is a kick-off meeting to
get the entire team on board. This is a
great opportunity to introduce your
Business Analyst and make it known that
the BA role is a critical success factor for
your project. Your communication plan
should include a list of the project
participants and contacts phone numbers
and email addresses to help with
communication between project team
members and the BA. This is also a good
time to let the business area participants
know what is expected of them as far as
time and schedule.
2. Does your Business Analyst know
your SME? It is great to have a
repeatable process for gathering data.
Data modeling is my personal favorite
because I like to see a picture of my data.
But some business area experts are
overwhelmed by models. Make sure your
BA and SME are speaking the same
language. Use of technical terms must be
minimized. For example, a term like
DDL may be too technical for your
SME. Ease them into data modeling by
running frequent review meetings that
go over small pieces of the model at a
time. If your model gets too big, break it
down into subject areas that are more
manageable to work with and view. If
they prefer textual documentation,
consider textual documentation instead
of diagrams for this project. Your
business area expert will feel that you
care about how they work and think and
will be more involved and interested in
the success of the project.
3. Include detailed tasks for the Business
Analyst in the project plan. Too many
times I have seen project plans that have
high-level analysis tasks such as “Gather
Requirements”. Whenever possible,
detail the individual analysis tasks,
meetings, and interviews. This is one of
the times where I break the “don’t list a
task that is under 40 hours” rule. People
are more likely to keep to the plan if
their detailed assignments are listed on
the plan. Putting down dates for
requirements gathering interviews is an
effective way to keep on track.
4. Schedule frequent walk-throughs of
the data requirements with the
SME(s). Do not wait until the end of
the Analysis phase to review what your
Business Analyst has produced. Walk
through the documented information,
making sure you map data to process to
discover any gaps.
5. Give recognition to the Business
Analyst and the SME. Acknowledging
that these two roles are essential to the
project and contribute to its success is an
effective way to keep participants
involved and motivated. The last thing
most people want to do is to give up
their precious time and energy for an
effort for which they are not rewarded or
recognized. Some ways I have found to
keep the energy up:
a.Send ‘kudo’ emails when good progress
is made – at any time in the project!
b.Give out some kind of certificate,
plaque, trophy, etc. at the end of a
successful project.
While these tips do not just apply to
data requirements gathering, but also to all
aspects of business analysis, I have found
that combining these approaches help
make a more cohesive team and drive the
project toward success. Good luck! ■
B2T Business Analyst Resources
www.b2ttraining.com
Conferences and Events
Recommended Books
Articles
Tool Reviews
Updates on the IIBA
Various Downloads Available
• Brochure for the Business Analyst Training Program
• previous issues of the bridge
• B2T Training Requirements Package Templates
the bridge l Fall/Winter 2004 6
did you know?
Database Models in MS Office Visio Professional 2003
1) In Visio create a New file, choose Database Model Diagram.
a) The Logical Diagram tab
allows you to select how the tool
should manage deletions. Since a
model can contain several
diagrams, the user must decide if
items are to be removed from just
the current diagram or from the
entire model. It also gives options
for showing relationships and
syncing logical and physical names.
▼
▼
▼
4) Another set of options are available from the Database menu under
Options – Modeling. These database modeling preferences apply
to users who will be handing the Visio file to their database
designers who will use the model to create the database itself.
▼
id you know that MS Office Visio Professional 2003 allows the
creation of a database model? This file type within Visio allows
the user to draw and detail a data model using a standard Entity
Relationship Diagram. There are many options so the format can be
used by Business Analysts documenting business data requirements or
by database designers using physical data structures. This article will
show you how to set up a database model in Visio and add entities
and attributes. The next issue of the bridge will show you how to add
and manipulate relationships.
D
2) The stencil contains the logical data
modeling components: entity and
relationship along with a few additional
shapes.
a) From the Database menu select
Options
▼
3) Before drawing your logical data diagram
there are a few options that you may want to set up:
▼
b) On the General tab choose Relational
and Conceptual names (Names visible
on diagram.)
▼
c) On the Table tab choose the
components that you want to display
d) On the Relationship tab choose
the crow’s feet and display the verb
phrases.
7 Fall/Winter 2004 l the bridge
b) The Logical Misc tab allows
you to specify whether you want
Visio to “migrate” or “propagate”
the foreign keys (B2T students:
do you remember which way the
foreign key migrates?!) It also lets
you set up name conflict
resolution handling (What if you
accidentally type in the same
entity name twice?) and prefixes and suffixes for database
generation.
5) Now you are ready to start documenting your data requirements!
Drag and drop an entity onto your diagram to begin your
modeling. As soon as you release the entity onto your diagram a
window pops up at the bottom of the screen. This is where you
define the properties of the entity. Each word on the bottom right
represents a category of properties. Single click on any one of these
to see the data entry screen for it. ▼
a) Definition –
allows you to name
your entity,
document the
corresponding table
name, owner, and
source database.
▼
c) Primary ID – to document the unique identifier(s) of the entity
d) Indexes, Triggers, Checks, Extended – properties for database
design
e) Notes – text box for any notes that you want to store.
6) Continue to add entities. Anytime you select an entity the
properties window is available for you to make changes.
▼
See the next issue of the
bridge for detailed
instructions about working
with relationships in the
Visio database model. ■
b) Columns – you add the attributes that describe this
entity along with their data type. You can also document
uniqueness (PK) and whether each attribute/column is
required or not.
certification
Business Analyst Certification Program
New Certified Business
Analysts
2T Training offers a program for
Business Analysts certifying that the
individual has the skills necessary to perform
analysis and complete a Business
Requirements Document for application
development. The program consists of
completing three proficiency area tests and a
final exam case study that requires completion
of a B2T Requirements Package. The final
exam takes 20 – 40 hours to complete. In
We are pleased to highlight an
additional 30 individuals who have
earned the title of Certified Business
Analyst since the last issue of the
bridge. The program began in late
2002, and we are excited that so
many Business Analysts are enrolled
and working toward certification. To
date, we have almost 1,000 people in
the program and over 100 of these
are expected to complete all the
requirements by the end of 2004.
B
addition, the candidate must have completed
two years work experience and receive two
recommendations from peers or co-workers
validating their experience and knowledge.
All of our exams and verification
information are reviewed by a Certified
Instructor/Business Analyst. Certified
Business Analyst may use the B2T Training
certification as proof of their proven
capabilities. ■
Essential Skills for the
Business Analyst
4 day class
Detailing Business
Data Requirements*
3 day class
Detailing Process and
Business Rule
Requirements
4 day class
Pass class exam
Pass class exam
Pass class exam
Pass Final
Certification
Exam
Submit application
for certication
• 2 written
recommendations
• Verify work exp.
(2 years min.)
*You may substitute Logical Data Modeling
Receive BA Certification
Cheryl Akers
Sangita Bone
Laurie Brown
Giovanni Flores
Chris Frankhouser
Connie Hildebrandt
Nancy Hoyt
Sheila Jenkins
Patrick Kearns
Finny Lee
Carolyn MacDonald
Larinda Mongan
Jeanne Morton
Devika Murthy
Beci Orrell
Sanjay Patel
Kathleen Person
Toney Poulis
Cheryl Ramiz
Joseph Rizzi
Lori Schneider
Lucyna Schroeder
Willie Sinnwell
Gayle Stith
Chris Stovall
Diane Strunk
Georgie VanWinkle
Diana Watt
Elaine Wernlund
Audrey Yanofsky
the bridge l Fall/Winter 2004 8
data brain teaser
ACROSS
4 IBM’s relational database
6 Rules that require resolution of many-to-many
relationships
9 A blank form for storing detailed data requirements
10 Allowable value for a maximum cardinality in a
relationship
11 Identify tasks for a project
12 Data elements
17 A common error when defining an attribute that
represents more than one fact
21 Graphical representation of data
25 A type of entity formed by removing repeating
attributes
26 Grammatical form for an entity name
27 An attribute with more than one value
28 Exchange of information between external agent and
project
29 The minimum allowable value for a cardinality in a
relationship
30 Database term for a unique identifier
31 Business data is _____________ vs. physical
32 Entity type created from a many to many relationship
35 An occurrence of an entity
37 Graphical representation of a business rule
38 Transforms data
39 Business data which becomes a table in the database
9 Fall/Winter 2004 l the bridge
DOWN
1 The combination of two or more attributes to
uniquely identify an entity
2 The name of the android on Star Trek, The Next
Generation
3 A data element which allows navigation from one
table to another
5 Your favorite company for business analyst training
7 Business rule between two entities
8 Database term for attribute
11 DBAs denormalize databases to improve ___________.
13 Person responsible for taking notes in Facilitated
Session
14 Electronic option for gathering requirements
15 When a relationship has a minimum cardinality of
one it is _______________
16 A proposed screen layout design
18 Section of the requirements package that contains
project terminology
19 Another term for a data relationship
20 A database design is _________________ vs. logical
22 Parent of a subtype entity
23 An attribute which is not mandatory Is _____________.
24 Database structure representing an entity
33 Business area experts
34 Allowable value for an attribute
36 Define the parameters of the project
Answers on page 12
update
International Institute of Business Analysis
ince the first annual meeting in March
2004, the International Institute of
Business Analysis, IIBA, a non-profit
professional organization for Business
Analysis professionals has been actively
working on
their goals.
In addition
to the
activity of
recruiting new members, the main focus
has been on the work being done by two
committees, Accreditation and Certification
Committee and the Business Analysis Body
of Knowledge (BOK) Committee.
A major decision was made by the
Accreditation committee to use ANSI
standard guidelines as a way to build the
accreditation and certification process. The
goal is to have the IIBA certification
program certified by a well-recognized and
respected independent organization, like
ANSI. PMI is also currently working
toward the same accreditation. The
committee has primary responsibilities to
define the scope of the BA role which will
map to the Knowledge Areas defined by the
BOK committee and that will also map to
the certification exam that will be
developed in the next 2 years.
From the BOK committee, a Glossary
S
of Terms is being developed to bring
together the membership’s key terms and to
eliminate confusion in discussions about
the Knowledge Area details.
Similar to the PMBOK (The Project
Management Body of Knowledge), the
BOK committee has decided to name each
important knowledge and practice area as a
Knowledge Area. The group has been busy
drafting the first iteration of Knowledge
Area definitions.
Both committees plan to use an iterative
process where each group
D E F I N I T I O N O F A B U S I N E S S A N A LYST
will draft, discuss and
Business Analysts are responsible for identifying the
approve key deliverables
business needs of their clients and stakeholders, to
and post them on the
determine solutions to business problems.
IIBA website for review
The Business Analyst is responsible for requirements
and feedback by the
development and requirements management.
membership, and make
Specifically, the Business Analyst elicits, analyzes,
updates to the draft
validates and documents business, organizational and/or
deliverables as needed.
operational requirements. Solutions are not
The IIBA wants to ensure
predetermined by the Business Analyst, but are driven
that whatever is defined
solely by the requirements of the business. Solutions
represents what an average
often include a systems development component, but
business analyst would be
may also consist of process improvement or
expected to know and to
organizational change.
demonstrate on his or her
The Business Analyst is a key facilitator within an
job. The BOK committee
organization, acting as a bridge between the client,
expects to post the first
stakeholders and the solution team.
outline draft of the Body
Business analysis is distinct from financial analysis,
of Knowledge areas
project management, quality assurance, organizational
sometime this fall. We
development, testing, training and documentation
development. However, depending on an organization,
hope that many of you
an individual Business Analyst may perform some or all
will consider joining the
of these related functions.
IIBA, volunteer on a
committee, and provide
As approved by IIBA Executive Committee
feedback. Stay tuned. ■
Continued from page 4
talk about processes and activities. They may
forget to tell designers about all data
requirements. Traditionally designers have
created databases based on screen and report
layouts, searching out data elements as they
go. These data elements are not well
organized or structured properly. Designing
a model based on physical workflow could
result in a model that does not fully
represent the business requirements. The
result is often a database that is missing
critical data and must be changed
immediately after implementation.
The database design task is a much
longer activity and the database may be
poorly structured without well documented
business data requirements. When business
data requirements have not been thoroughly
fleshed out, database designs are unstable
throughout the development process. During
coding, testing, and even implementation,
developers are finding additional data
elements, requiring the DBAs to be re-active
instead of pro-active. Resulting databases may
be poorly structured, looking like a patchwork
quilt, instead of being well planned and easy
to maintain. Errors in the database design
will cause the entire system to be unstable.
What about package selection and
implementation?
Gathering and documenting data
requirements is just as critical whether you
are writing software or purchasing it. A
complete set of data requirements should be
included in the vendor RFP requiring
potential vendors to respond to each data
element needed. After a package is selected,
the data requirements must be matched to
the software’s data and a gap analysis
performed before the package is installed.
So, when software is implemented with
the correct data elements, it is not an
accident or a coincidence. A focus on
gathering and documenting business data
requirements is a critical success factor in all
application development projects. An
excellent Business Analyst understands the
importance of these data requirements and
helps other team members to focus on
them. ■
the bridge l Fall/Winter 2004 10
Lost in Translation
BY A N G I E P E R R I S, P M P
“NASA lost its $125-million Mars Climate Orbiter because
“spacecraft engineers failed to convert from English to metric
measurements when exchanging vital data before the craft was launched,
space agency officials said Thursday.
A navigation team at the Jet Propulsion Laboratory used the metric system of
millimeters and meters in its calculations, while Lockheed Martin Astronautics in
Denver, which designed and built the spacecraft, provided crucial acceleration
data in the English system of inches, feet and pounds.
As a result, JPL engineers mistook acceleration readings measured in English
units of pound-seconds for a metric measure of force called newton-seconds.
In a sense, the spacecraft was lost in translation. … ”
Source: Mars Probe Lost Due to Simple Math Error; [Home Edition], ROBERT LEE HOTZ. Los
Angeles Times. Los Angeles, Calif.: Oct 1, 1999.
rucial information is often lost in
translation when detailed business data
requirements are not captured. One proven
way to represent these important details is
to create a data model. As with the Mars
Probe, if a data model had been developed
that correctly defined the acceleration data,
the mistake between meters and feet may
not have occurred. Organizations that
dominate the market place today have
learned the right information at the right
time could mean the difference between
profitability or financial loss, life or death,
trust or distrust; success or failure; the right
data is a means to distinguish themselves
from their competitors. This article will
discuss why detailed data requirements are
a critical aspect of your business
requirements gathering and will provide
you some hints you can follow to get
started building a business data model on
your next project.
C
How is business data modeling done
today?
On all too many projects, not at all!
Unfortunately while some folks are patting
themselves on the back for a job well done
soon after the software system has gone
into production, the initial customer issues
begin to surface. Often during this brief
honeymoon period, customers are very
forgiving of some missed data requirements
– but then anger, panic and frustration set
in and the climate quickly changes into
more like Fear Factor as they learn that the
11 Fall/Winter 2004 l the bridge
data requirements that were never defined,
do not exist in the database, and that the
information they need now will not be
collected and will not be accessible for a
long time to come because modifying
the database as an afterthought is not a
simple task.
Unfortunately, some organizations do
not value the collection of data
requirements during business requirements
gathering and do not expect a business
analyst to know how to model business
data. They believe that programmers and
DBAs can figure it out during the technical
design and build phases (even though the
subject matter experts are typically not
involved then to provide validation). When
only processes are considered, certain
business rules and critical data items may
be forgotten until user acceptance testing
or worse yet, until after implementation.
Missed business requirements results in
greater business risk: e.g. missing data
required for critical reports or results that
are incorrect or inconsistent; the data is
unstable; a poorly designed database; or
higher costs. A person in a “business
analyst” role should proactively practice
modeling and analyzing business data along
with their processes to avoid this problem.
Having that information available means
that the business analyst has carefully
collected, analyzed and modeled the data
the end user needs in a way that can be
understood by the programmers and the
database designers.
What is a data
model?
You can think of your data
model as your blueprint for
your physical database. Its
structure is simple and its words
are in business language so that the subject
matter experts facilitated by the Business
Analyst can understand and validate their
business information. But also the structure
and data details are sufficient for the
technical database designer to build the
database correctly to support the business
requirements. A data model includes
entities, attributes, relationships and all their
properties. There are several ways to
represent a data model, but the two most
common ways are diagrams or tables. The
Entity Relationship Diagram is the most
widely used way to represent the physical
database and is a recommended method for
the logical or business representation as well.
As an alternative for those uncomfortable
with diagramming or using an
unsophisticated modeling tool, a structured
text table format method can be used to
document all data model components.
Hints to get started
Hint 1 – Take a formal course in data
modeling.
Hint 2 – Buy a book on data modeling
Hint 3– Bring in an experienced data
modeling consultant
Hint 4 - Try more than one
presentation technique
Hint 5 - Timebox your modeling
activities to keep the meeting on track
Hint 6 - Recognize there is not one
correct data model
Hint 7 – Use post-it notes, a flip
chart and a whiteboard for a more
interactive session
Conclusion
Although data modeling may seem
overwhelming at first, start thinking about
your data today, even if that is just making
lists of entities and attributes with your
stakeholders. That is a step in the right
direction. ■
tool review
AllFusion ERwin Data Modeler
complex language and could focus on
designing more normalized coherent
databases. ERwin can generate DDL for
over 30 commercial database packages
A’s AllFusion ERwin is one of the
giving your organization the flexibility to
oldest and most popular data modeling
change platforms more quickly.
tools in the world. Built in 1992 by
The quality of the diagram with its
LogicWorks, Inc. and named for Entity
underlying properties attracted the
Relationship for Windows, ERwin initially
attention of data analysts who wanted a
provided a graphical Entity Relationship
similar tool to document business or logical
Diagram that generated database DDL
data requirements. ERwin 2.0 added a
(data definition language). Suddenly
logical diagram and an automated
database designers were free from coding a
translation from logical to
A Physical (database design) Diagram
physical. This feature allows
business analysts to document
business data in a model and
then pass the model to the
database designer for
transition to design and
implementation. The tool also
provides utilities for
comparing models between
project teams or sub-teams.
Later versions have added
entity and attribute naming
standardization and increasing
flexible user defined
A Logical (business data requirement) Diagram
properties.
Every data component on
the diagram has a Properties
Window that the modeler can
use to document
characteristics about the
component.
In addition, ERwin Data
Modeler interfaces with the
AllFusion Process Modeler
which allows analysts to
diagram processes and link
Entity Property Window
C
Attribute Property Window
Relationship Property Window
them to the data elements that the process
uses. You can download an evaluation copy
of AllFusion ERwin at www.cai.com. ■
Answers to
Crossword
puzzle on
page 9
the bridge l Fall/Winter 2004 12
certified core courses
Essential Skills for the Business Analyst
4 Days
This course covers the critical skills for the Business Analyst. Students will learn
to define what is, and what is not included in the project, how to ask the right
questions, when and how to hold interviews and facilitated sessions, how to
write excellent requirements, how to verify that requirements are testable, how
to conduct a requirements review, and have an overview of various application
development methodologies. Additionally, students will be introduced to various
documentation techniques and plan an approach for documentation.
3 Days
Detailing Business Data Requirements
The Data portion of the business requirements is a critical component to defining
complete requirements. Every process uses data and almost all business rules
are enforced by data. Missing a critical piece of data or incorrectly defining a
data element contributes to the majority of maintenance problems and results in
systems that do not reflect the business needs. This course teaches students an
in-depth approach to identify and define all necessary data components using
both textual templates and an entity relationship diagram to create a data model.
4 Days
Detailing Process and Business Rule Requirements
▼
This course continues the development of the requirements package by defining
the processes and business rules for the project. Students will learn to identify
and define the processes from a business and functional perspective. Various
techniques are taught including decomposition diagrams, templates, workflow
models, and Use Case diagrams and descriptions. Additionally, this course
teaches techniques to ensure that requirements have not been missed.
More detailed outlines are available on our website, www.b2ttraining.com
13 Fall/Winter 2004 l the bridge
additional course offerings
Requirements Testing for the Business Analyst
3 Days
This course provides an excellent foundation for Business Analysts who are
involved in software quality assurance (SQA). The course will improve the
Business Analyst's development of requirements so that they can be used to
build quality test cases. It will also enable the Business Analyst to create specific
test cases from the requirements. The course includes a workshop case study
that provides a cohesive learning experience.
This course provides Business Analysts the knowledge to:
• Understand the basic SQA terms and definitions as defined by international
standards
• Understand the link between requirements and testing
• Understand the testing life cycle
• Correct/update requirements for use in development of tests
• Define and create test documentation using IEEE/ISO formats
• Understand common testing techniques
• Review and assist with the development of project test plans
• Design and create usability tests
• Understand the difference between manual and automated testing
Overview of Business Analysis
4 Hour Seminar
This seminar presents the Business Analyst role to managers and others who
lead and work with Business Analysts. In order for the Business Analysts to be
successful, both the IT and business community must embrace the business
analysis process. The seminar can be used as a working session to discuss how
your organization will implement the business analysis process and approaches
for documenting the requirements.
Both large and small organizations are realizing the benefits of using Business
Analysts on all of their application development projects. A Business Analyst acts
as a liaison between business people who have a business problem and
technology people who know how to create automated solutions. Improving the
communication between your business areas and your IT team significantly
increases the quality of the systems developed.
▼
A Business Analyst's main responsibility is to gather, detail, and document
requirements in a format that is useful to their business area experts and the
technical developers. Analysis is a very important and time-consuming phase of
every project. This seminar provides strategies for how management can support
the business analysis process.
For more information on these courses visit www.b2ttraining.com
the bridge l Fall/Winter 2004 14
2005 public class schedule
Essential Skills for the Business Analyst - $1,980/per student
• Jan 31 – Feb 3, 2005 Houston, TX
• Feb 21 – Feb 24, 2005 Louisville, KY
• Mar 7 – Mar 10, 2005 Boston, MA
• Apr 18 – Apr 21, 2005 Chicago, IL
• May 16 – May 19, 2005 Seattle, WA
• Jun 6 – Jun 9, 2005 Atlanta, GA
• Oct 24 – Oct 27, 2005 Atlanta, GA
Detailing Business Data Requirements - $1,485/per student
• Feb 7 – Feb 9, 2005 Atlanta, GA
• Apr 11 – Apr 13, 2005 Houston, TX
• Apr 18 – Apr 20, 2005 Louisville, KY
• Jun 13 – Jun 15, 2005 Chicago, IL
• Jul 11 – Jul 13, 2005 Seattle, WA
• Sep 19 – Sep 21, 2005 Atlanta, GA
• Oct 3 – Oct 5, 2005 Boston, MA
Please check our
website for additional
public class offerings
and to check availability
and register –
www.b2ttraining.com/
Training-Courses
On-site classes are also
available.
Call 865-675-2125
or email us at
[email protected]
Detailing Process and Business Rule Requirements - $1,980/per student
• Apr 4 – Apr 7, 2005 Atlanta, GA
• May 17 – May 20, 2005 Louisville, KY
• Jun 6 – Jun 9, 2005 Houston, TX
• Aug 1 – Aug 4, 2005 Chicago, IL
• Sep 26 – Sep 29, 2005 Seattle, WA
• Nov 14 – Nov 17, 2005 Atlanta, GA
• Dec 5 – Dec 8, 2005 Boston, MA
Requirements Testing for the Business Analyst - $1,485 per student
• Jan 24 – Jan 26, 2005 Louisville, KY
B2T Training
11795 Northfall Lane, Suite 601
Alpharetta, GA 30004
Prsrt Std
U.S. Postage
PAID
Permit #309
Knoxville, TN