why does a business analyst need to worry about data?
DESCRIPTION
TRANSCRIPT
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
the CONNECTING BUSINESS REQUIREMENTS TO TECHNOLOGY
Fall/Winter 2004
Why Does a BusinessAnalyst Needto WorryAbout Data?
Why Does a BusinessAnalyst Needto WorryAbout Data?
letter from the editors
For our second issue of the bridge, we decided to highlight the importance of Data Requirements as part of
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 BARBARA CARKENORD
Certified Woman OwnedSmall Business
t a b l e o f c o n t e n t sWhy Does a Business Analyst Need to Worry About Data?
Book ReviewData Modeling Essentials: Analysis, Design, and Innovationby Graeme C. Simsion
Ask the ExpertsShould I Gather Data Requirements for a Maintenance Project?
A Project Manager’s Role in Gathering Requirements
Did You Know?Data Models in MS Visio Professional
Business Analyst Certification Program
Data Brain Teaser
UpdateInternational Institute of Business Analysts
Lost in Translation
Tool ReviewAllFusion ERwin Data Modeler
B2T Training Core Courses
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 skillsand 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 toensure the project has met its defined objectives.
Our training is offered nationally and on a limited international basis. Most of our classes are taught onsiteand are tailored to the unique environments of each organization. Public classes are also available in variouscities around the US.
Vice President, Sales and MarketingTina Joseph
©2004 B2T Training. All rights reserved.
the
Fall/Winter 2004
3
5
5
6
7
8
9
10
11
12
13
14
the bridge l Fall/Winter 2004 2
Vice President, TrainingBarbara A. Carkenord
Director of Business DevelopmentAngie Perris
volume 1 l issue 2
Page 3
Page 5
Page 7
It’s no accident when the rightinformation is available. Gatheringand documenting business data
requirements is a critical success factor inall application development projectsbecause data is needed to perform everybusiness process. An excellent BusinessAnalyst knows the importance of thesedata requirements and knows how to elicitthem from their Subject Matter Experts(SME).
Computer systems initially were calledData Processing because they process data.They have been called InformationSystems because they process information.The most amazing aspect of technologytoday is the immense amount ofinformation that can be stored in tinychips and on thin metal disks. Thisinformation or data provides the rawmaterials for all of the sophisticatedsoftware and hardware systems that areused constantly in our organizations. Canyou imagine looking up your customer’saddress in a filing cabinet?
But with all of the sophistication ofinformation systems and databasemanagement systems, many of ourapplications are less than perfect. Usershave developed “work-arounds” andinvented codes that allow them to keeptrack of information that the system wasnot designed to manage. How can all ofour sophisticated technology still have so
many flaws? One reason is that we didn’tthink about data requirements earlyenough in the development project.
Data is the most important part of anapplication system. A good, strong,accurate data structure allows developers todesign any processing, reporting, orstatistical analysis ever needed. The mostelegant, high-tech system in the world willbe shelved if it does not provide access tothe correct business data.
Every business process uses data, everybusiness rule depends on data. Failing toidentify data requirements puts your projectat 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 thepieces of information necessary to run the
business. The logical data model is builtusing an Entity Relationship Diagram(ERD) – a standard modeling techniqueused by data modelers around the world.Entity relationship diagramming is astructured technique used by businessanalysts and technical developers as acommunication tool. It provides acomplete picture of the business datarequirements. (See diagram next page)
The components of a logical data modelinclude Entities, Relationships, andAttributes. Each entity represents a set ofpersons, things, or concepts about which thebusiness needs information. Each relationshiprepresents an association between two entities– they represent data related business rules.Each attribute is a characteristic or piece ofinformation that further describes an entity.A name and textual definition describe each
3 Fall/Winter 2004 l the bridge
Business Process Business Data
Record customer order Customer number, name, shipping address, phoneOrder number, dateProduct order quantity, price, weight
Bill customer Customer number, contact name, billing addressInvoice number, amount, date
Business Rule Business Data
Orders totaling over $500 Order total dollar amountare shipped for free Customer shipping address
Preferred customers are Customer type, discount percentagegiven a discount Order number, total dollar amount before discount,
discounted dollar amount
Why Does a Business Analyst Need to Worry About Data?
B Y 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
of these components. These names anddefinitions provide ongoing documentationof the business rules and data requirementsof the business area. These three corerequirements components can capture andclearly represent the most complex data thatyour organization uses.
Why build a logical data model?
The most important reason to build alogical data model is to confirm the users’and analysts’ understanding of the businessdata requirements to assure that thesoftware developed satisfies the businessneed. Logical data modeling provides theanalyst with a structured tool and techniqueto conduct analysis. Most SMEs canarticulate problems and possible solutions,unfortunately their problems and solutionsare often based on current system constraints,not true business needs. Asking businesspeople to detail every piece of data(attribute), requires them to understandand articulate every aspect of their business.This approach allows the business to drivethe system design, not the other wayaround. It also stimulates more detaileddiscussion and thoughts. By identifying anddetailing data in a model, furtherrequirements and problem areas arise andare dealt with long before software design.
A logical data model is a foundation fordesigning a database that supports the
business requirements. Database designersstart their design with a complete picture ofthe business requirements and can thendetermine the best implementation approach.
A logical data model also facilitates datare-use and sharing. Data is stable over time;therefore, the model remains stable over
time. As additional project teams scope outtheir project areas, they can re-use the modelcomponents that are shared by the business.This leads to physical data sharing and lessstorage of redundant data. It also helps theorganization recognize that information isan organization –wide resource, not theproperty of one department or another.Data sharing makes the organization morecohesive and increases the quality of serviceto outside customers and suppliers.
Having business data requirements welldocumented allows quick impact analysiswhen a business change request comesalong. Analysts with access to a logical datamodel can review the model and offersuggestions for implementing changesalong with quickly being able to ascertainthe complexity of the change.
In summary, building and maintaining alogical data model decreases systemdevelopment and maintenance time andcost. Identifying all business requirements atthe beginning of a project makes the design,coding, testing, and implementation phases
go much smoother and faster. A model iseasier and cheaper to modify; mistakes,missed data, and misinterpretations are lesscostly when corrected in a model than in animplemented system. It also decreases userrequests for changes. When changes arenecessary, the logical model can be used forimpact analysis.
Who uses the logical data model?
The SMEs own the logical data model. Itrepresents all the information needs of thebusiness area. They describe their datarequirements to the business analyst andreview the requirements created. They usethe model to confirm that the BusinessAnalyst understands the business needs.
Business Analysts elicit data requirementsby reviewing existing data sources and byasking key questions during interviews andfacilitated sessions. The analyst documentsthe data requirements using entities,relationships, and attributes creating amodel of the data. The analyst also uses the data requirements to detail processrequirements. Every business process usesdata so cross-referencing process to dataprovides a thorough verification. TheBusiness Analyst gets signoff on the datarequirements from the SMEs and workswith the database designer to transition thisbusiness data into a database design.
The database designer builds a physicaldata structure to support the business needs.The designer reviews the logical data model,along with the processes that access the datato determine the best implementationapproach. Giving the database designer acomplete picture of the business needsallows him or her to understand the overallapplication and create a system architecturethat is well organized and flexible. A strong,coherent data structure will be useful to theorganization for many years, maybe decades.
What happens if you don’t document
business data requirements?
When users are not asked to focus on dataas a critical part of a system design, they
the bridge l Fall/Winter 2004 4
Logical Data Model built using an Entity Relationship Diagram
Continued on page 10
5 Fall/Winter 2004 l the bridge
Most of the projects that we work onare not brand new software
development projects, but rather changesto existing software or interfaces. On thesemaintenance projects, the Project Managerand Business Analyst must make decisionsabout the type of requirements needed andthe time to be spent in requirementsgathering. One of the questions that mustbe answered during project initiation is:Should I gather and document datarequirements?
Initially the answer seems obvious. Ifthe requested change is asking for us totrack a new piece of information then weneed data requirements; otherwise no. Butbe careful jumping to the obviousconclusion. Remember that data is usedeverywhere in an application, so anychange may impact data.
Ideally data requirements weredocumented for the original project so thatthe Business Analyst can refer back to themand assess the impact of a change. But if thedata requirements were not documentedinitially, here are some suggestions for whatto document and when.
• If the user has requested a new report,document all of the business data requiredto generate the report. Remember, not thedata to be displayed on the report, thedata needed to generate it. Many fields onreports are calculated fields. You need tocapture the core data elements that areneeded to perform the calculation. Onceyou have documented all of these datarequirements, meet with your databaseadministrator to find out if all of thesedata elements are currently stored in adatabase. It is helpful to document theirphysical name and storage location forfuture reference. This is referred to as “gapanalysis”. 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 thescreen and possibly behind the screen tosupport the data entry or inquiryrequested. Again, once the datarequirements are documented, meet withyour database administrator to verify thatthese fields are available (and areformatted in the same way).
• If the user has requested a formatchange on an existing screen or report,you probably don’t need to document datarequirements, just the change in the waythe data is presented.
• If the user has requested a new businessprocess that must be automated,document all of the data requirements forthe new process along with the processdescription and associated business rules.A new business process almost alwaysmeans new data requirements.
• If the user request involves changes tobusiness rules, be sure to analyze the dataused by each business rule and make surethe data elements needed are available.
In the humble opinion of this “data bigot”there are very few projects where data requirementscan be omitted. A good analyst always thinksabout data as well as process and business ruleswhen planning their analysis work. �
Send your questions to Ask the Experts [email protected].
Data Modeling Essentials is a fresh lookat an old topic. Since data modeling
was developed in the 1970’s numerousauthors havewritten booksthat describedthe process ofdocumentingdata require-ments in amodel andrefining it using datanormalizationrules. Often
these books were very technical and lackingin real world examples.
Data Modeling Essentials is much moreaccessible and refreshing in its tone andattitude. Simsion’s explanations are veryclear and his examples easy to follow.Simsion presents normalization rules withsimplicity and clarity. The reasons behindeach concept are efficiently described whilegiving the reader confidence in therecommendations. Simsion also providesexcellent suggestions for namingconventions, presentation formats and foreliciting these requirements from SubjectMatter Experts. This book is useful for
both beginners and experienced datamodelers who want a new innovativeapproach to the important task ofdocumenting data requirements. A revisedthird edition with expanded examples willbe available late October 2004. �
Barbara A. Carkenord is the Vice Presidentof Training at B2T Training. She has worked in the requirements gathering anddocumentation field for over 20 years and hasconducted hundreds of seminars for BusinessAnalysts. Comments are welcome [email protected].
book reviewData Modeling Essentials: Analysis, Design, and Innovationby Graeme C. SimsionREVIEWED FOR B2T TRAINING BY BARBARA A. CARKENORD
This book is availableat b2ttraining.com.
ask the experts Should I Gather Data Requirements for a Maintenance Project?
As a project manager, I want to ensurethat my data requirements gathering is
well-planned and that the plan contains allof the tasks I need to deliver a successfulproject. How do I do that? How do Iensure that my Business Analyst has thepower they need to get their job done?Let’s review some key points foraccomplishing just that.
1. Involve the Business Analyst in theproject kickoff. The first task once aproject is defined is a kick-off meeting toget the entire team on board. This is agreat opportunity to introduce yourBusiness Analyst and make it known thatthe BA role is a critical success factor foryour project. Your communication planshould include a list of the projectparticipants and contacts phone numbersand email addresses to help withcommunication between project teammembers and the BA. This is also a goodtime to let the business area participantsknow what is expected of them as far astime and schedule.
2. Does your Business Analyst knowyour SME? It is great to have arepeatable process for gathering data.Data modeling is my personal favoritebecause I like to see a picture of my data.But some business area experts are
overwhelmed by models. Make sure yourBA and SME are speaking the samelanguage. Use of technical terms must beminimized. For example, a term likeDDL may be too technical for yourSME. Ease them into data modeling byrunning frequent review meetings thatgo over small pieces of the model at atime. If your model gets too big, break itdown into subject areas that are moremanageable to work with and view. Ifthey prefer textual documentation,consider textual documentation insteadof diagrams for this project. Yourbusiness area expert will feel that youcare about how they work and think andwill be more involved and interested inthe success of the project.
3. Include detailed tasks for the BusinessAnalyst in the project plan. Too manytimes I have seen project plans that havehigh-level analysis tasks such as “GatherRequirements”. Whenever possible,detail the individual analysis tasks,meetings, and interviews. This is one ofthe times where I break the “don’t list atask that is under 40 hours” rule. Peopleare more likely to keep to the plan iftheir detailed assignments are listed onthe plan. Putting down dates forrequirements gathering interviews is aneffective way to keep on track.
4. Schedule frequent walk-throughs ofthe data requirements with theSME(s). Do not wait until the end ofthe Analysis phase to review what yourBusiness Analyst has produced. Walkthrough the documented information,making sure you map data to process todiscover any gaps.
5. Give recognition to the BusinessAnalyst and the SME. Acknowledgingthat these two roles are essential to theproject and contribute to its success is aneffective way to keep participantsinvolved and motivated. The last thingmost people want to do is to give uptheir precious time and energy for aneffort for which they are not rewarded orrecognized. Some ways I have found tokeep 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 todata requirements gathering, but also to allaspects of business analysis, I have foundthat combining these approaches helpmake a more cohesive team and drive theproject toward success. Good luck! �
A Project Manager’s Role in Gathering RequirementsBY ALI IBARGUEN, PMP, BLUEPRINT PM, LLC
the bridge l Fall/Winter 2004 6
B2T Business Analyst Resources www.b2ttraining.com
Conferences and Events
Recommended Books
Articles
Tool Reviews
Updates on the IIBAVarious Downloads Available
• Brochure for the Business Analyst Training Program• previous issues of the bridge
• B2T Training Requirements Package Templates
Did you know that MS Office Visio Professional 2003 allows thecreation of a database model? This file type within Visio allows
the user to draw and detail a data model using a standard EntityRelationship Diagram. There are many options so the format can beused by Business Analysts documenting business data requirements orby database designers using physical data structures. This article willshow you how to set up a database model in Visio and add entitiesand attributes. The next issue of the bridge will show you how to addand manipulate relationships.
1) In Visio create a New file, choose Database Model Diagram.
2) The stencil contains the logical data modeling components: entity and relationship along with a few additional shapes.
3) Before drawing your logical data diagram there are a few options that you may want to set up:
a) From the Database menu select Options
b) On the General tab choose Relationaland 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.
4) Another set of options are available from the Database menu underOptions – Modeling. These database modeling preferences applyto users who will be handing the Visio file to their databasedesigners who will use the model to create the database itself.
a) The Logical Diagram tab allows you to select how the toolshould manage deletions. Since amodel can contain severaldiagrams, the user must decide ifitems are to be removed from justthe current diagram or from theentire model. It also gives optionsfor showing relationships andsyncing logical and physical names.
b) The Logical Misc tab allows you to specify whether you wantVisio to “migrate” or “propagate”the foreign keys (B2T students:do you remember which way theforeign key migrates?!) It also letsyou set up name conflictresolution handling (What if youaccidentally type in the sameentity name twice?) and prefixes and suffixes for databasegeneration.
5) Now you are ready to start documenting your data requirements!Drag and drop an entity onto your diagram to begin yourmodeling. As soon as you release the entity onto your diagram awindow pops up at the bottom of the screen. This is where youdefine the properties of the entity. Each word on the bottom rightrepresents a category of properties. Single click on any one of theseto see the data entry screen for it.
did you know? Database Models in MS Office Visio Professional 2003
7 Fall/Winter 2004 l the bridge
�
�
�
��
��
�
B2T Training offers a program forBusiness Analysts certifying that the
individual has the skills necessary to performanalysis and complete a BusinessRequirements Document for applicationdevelopment. The program consists ofcompleting three proficiency area tests and afinal exam case study that requires completionof a B2T Requirements Package. The finalexam takes 20 – 40 hours to complete. In
addition, the candidate must have completedtwo years work experience and receive tworecommendations from peers or co-workersvalidating their experience and knowledge.
All of our exams and verificationinformation are reviewed by a CertifiedInstructor/Business Analyst. CertifiedBusiness Analyst may use the B2T Trainingcertification as proof of their provencapabilities. �
certification Business Analyst Certification Program
a) Definition – allows you to nameyour entity,document thecorresponding tablename, owner, andsource database.
b) Columns – you add the attributes that describe thisentity along with their data type. You can also documentuniqueness (PK) and whether each attribute/column isrequired or not.
c) Primary ID – to document the unique identifier(s) of the entity d) Indexes, Triggers, Checks, Extended – properties for database
designe) Notes – text box for any notes that you want to store.
6) Continue to add entities. Anytime you select an entity theproperties window is available for you to make changes.
See the next issue of thebridge for detailedinstructions about workingwith relationships in theVisio database model. �
the bridge l Fall/Winter 2004 8
Essential Skills for the
Business Analyst
4 day class
Pass class exam
Detailing Business
Data Requirements*
3 day class
Pass class exam
Detailing Process and
Business Rule
Requirements
4 day class
Pass class exam
Pass FinalCertification
ExamReceive BA Certification
Submit applicationfor certication
• 2 written recommendations
• Verify work exp. (2 years min.)
*You may substitute Logical Data Modeling
New Certified Business
Analysts
We are pleased to highlight anadditional 30 individuals who haveearned the title of Certified BusinessAnalyst since the last issue of thebridge. The program began in late2002, and we are excited that somany Business Analysts are enrolledand working toward certification. Todate, we have almost 1,000 people inthe program and over 100 of theseare expected to complete all therequirements by the end of 2004.
Cheryl AkersSangita BoneLaurie BrownGiovanni FloresChris FrankhouserConnie HildebrandtNancy HoytSheila JenkinsPatrick KearnsFinny LeeCarolyn MacDonaldLarinda MonganJeanne MortonDevika MurthyBeci Orrell
Sanjay PatelKathleen PersonToney PoulisCheryl RamizJoseph RizziLori SchneiderLucyna SchroederWillie SinnwellGayle StithChris StovallDiane StrunkGeorgie VanWinkleDiana WattElaine WernlundAudrey Yanofsky
�
�
9 Fall/Winter 2004 l the bridge
data brain teaser
ACROSS
4 IBM’s relational database6 Rules that require resolution of many-to-many
relationships9 A blank form for storing detailed data requirements10 Allowable value for a maximum cardinality in a
relationship11 Identify tasks for a project12 Data elements17 A common error when defining an attribute that
represents more than one fact21 Graphical representation of data25 A type of entity formed by removing repeating
attributes26 Grammatical form for an entity name27 An attribute with more than one value28 Exchange of information between external agent and
project29 The minimum allowable value for a cardinality in a
relationship30 Database term for a unique identifier31 Business data is _____________ vs. physical32 Entity type created from a many to many relationship35 An occurrence of an entity37 Graphical representation of a business rule38 Transforms data39 Business data which becomes a table in the database
DOWN
1 The combination of two or more attributes touniquely identify an entity
2 The name of the android on Star Trek, The NextGeneration
3 A data element which allows navigation from onetable to another
5 Your favorite company for business analyst training7 Business rule between two entities8 Database term for attribute11 DBAs denormalize databases to improve ___________.13 Person responsible for taking notes in Facilitated
Session14 Electronic option for gathering requirements15 When a relationship has a minimum cardinality of
one it is _______________16 A proposed screen layout design18 Section of the requirements package that contains
project terminology19 Another term for a data relationship20 A database design is _________________ vs. logical22 Parent of a subtype entity23 An attribute which is not mandatory Is _____________.24 Database structure representing an entity33 Business area experts34 Allowable value for an attribute36 Define the parameters of the projectAnswers on page 12
Since the first annual meeting in March2004, the International Institute of
Business Analysis, IIBA, a non-profitprofessional organization for BusinessAnalysis professionals has been actively
working ontheir goals.In additionto theactivity of
recruiting new members, the main focushas been on the work being done by twocommittees, Accreditation and CertificationCommittee and the Business Analysis Bodyof Knowledge (BOK) Committee.
A major decision was made by theAccreditation committee to use ANSIstandard guidelines as a way to build theaccreditation and certification process. Thegoal is to have the IIBA certificationprogram certified by a well-recognized andrespected independent organization, likeANSI. PMI is also currently workingtoward the same accreditation. Thecommittee has primary responsibilities todefine the scope of the BA role which willmap to the Knowledge Areas defined by theBOK committee and that will also map tothe certification exam that will bedeveloped in the next 2 years.
From the BOK committee, a Glossary
of Terms is being developed to bringtogether the membership’s key terms and toeliminate confusion in discussions aboutthe Knowledge Area details.
Similar to the PMBOK (The ProjectManagement Body of Knowledge), the
BOK committee has decided to name eachimportant knowledge and practice area as aKnowledge Area. The group has been busydrafting the first iteration of KnowledgeArea definitions.
Both committees plan to use an iterativeprocess where each groupwill draft, discuss andapprove key deliverablesand post them on theIIBA website for reviewand feedback by themembership, and makeupdates to the draftdeliverables as needed.The IIBA wants to ensurethat whatever is definedrepresents what an averagebusiness analyst would beexpected to know and todemonstrate on his or herjob. The BOK committeeexpects to post the firstoutline draft of the Bodyof Knowledge areassometime this fall. Wehope that many of youwill consider joining theIIBA, volunteer on acommittee, and providefeedback. Stay tuned. �
update International Institute of Business Analysis
DEFINITION OF A BUSINESS ANALYST
Business Analysts are responsible for identifying the
business needs of their clients and stakeholders, to
determine solutions to business problems.
The Business Analyst is responsible for requirements
development and requirements management.
Specifically, the Business Analyst elicits, analyzes,
validates and documents business, organizational and/or
operational requirements. Solutions are not
predetermined by the Business Analyst, but are driven
solely by the requirements of the business. Solutions
often include a systems development component, but
may also consist of process improvement or
organizational change.
The Business Analyst is a key facilitator within an
organization, acting as a bridge between the client,
stakeholders and the solution team.
Business analysis is distinct from financial analysis,
project management, quality assurance, organizational
development, testing, training and documentation
development. However, depending on an organization,
an individual Business Analyst may perform some or all
of these related functions.
As approved by IIBA Executive Committee
the bridge l Fall/Winter 2004 10
talk about processes and activities. They mayforget to tell designers about all datarequirements. Traditionally designers havecreated databases based on screen and reportlayouts, searching out data elements as theygo. These data elements are not wellorganized or structured properly. Designinga model based on physical workflow couldresult in a model that does not fullyrepresent the business requirements. Theresult is often a database that is missingcritical data and must be changedimmediately after implementation.
The database design task is a muchlonger activity and the database may bepoorly structured without well documentedbusiness data requirements. When business
data requirements have not been thoroughlyfleshed out, database designs are unstablethroughout the development process. Duringcoding, testing, and even implementation,developers are finding additional dataelements, requiring the DBAs to be re-activeinstead of pro-active. Resulting databases maybe poorly structured, looking like a patchworkquilt, instead of being well planned and easyto maintain. Errors in the database designwill cause the entire system to be unstable.
What about package selection and
implementation?
Gathering and documenting datarequirements is just as critical whether youare writing software or purchasing it. A
complete set of data requirements should beincluded in the vendor RFP requiringpotential vendors to respond to each dataelement needed. After a package is selected,the data requirements must be matched tothe software’s data and a gap analysisperformed before the package is installed.
So, when software is implemented withthe correct data elements, it is not anaccident or a coincidence. A focus ongathering and documenting business datarequirements is a critical success factor in allapplication development projects. Anexcellent Business Analyst understands theimportance of these data requirements andhelps other team members to focus onthem. �
Continued from page 4
11 Fall/Winter 2004 l the bridge
Crucial information is often lost intranslation when detailed business data
requirements are not captured. One provenway to represent these important details isto create a data model. As with the MarsProbe, if a data model had been developedthat correctly defined the acceleration data,the mistake between meters and feet maynot have occurred. Organizations thatdominate the market place today havelearned the right information at the righttime could mean the difference betweenprofitability or financial loss, life or death,trust or distrust; success or failure; the rightdata is a means to distinguish themselvesfrom their competitors. This article willdiscuss why detailed data requirements area critical aspect of your businessrequirements gathering and will provideyou some hints you can follow to getstarted building a business data model onyour next project.
How is business data modeling done
today?
On all too many projects, not at all!Unfortunately while some folks are pattingthemselves on the back for a job well donesoon after the software system has goneinto production, the initial customer issuesbegin to surface. Often during this briefhoneymoon period, customers are veryforgiving of some missed data requirements– but then anger, panic and frustration setin and the climate quickly changes intomore like Fear Factor as they learn that the
data requirements that were never defined,do not exist in the database, and that theinformation they need now will not becollected and will not be accessible for along time to come because modifying the database as an afterthought is not asimple task.
Unfortunately, some organizations donot value the collection of datarequirements during business requirementsgathering and do not expect a businessanalyst to know how to model businessdata. They believe that programmers andDBAs can figure it out during the technicaldesign and build phases (even though thesubject matter experts are typically notinvolved then to provide validation). Whenonly processes are considered, certainbusiness rules and critical data items maybe forgotten until user acceptance testingor worse yet, until after implementation.Missed business requirements results ingreater business risk: e.g. missing datarequired for critical reports or results thatare incorrect or inconsistent; the data isunstable; a poorly designed database; orhigher costs. A person in a “businessanalyst” role should proactively practicemodeling and analyzing business data alongwith their processes to avoid this problem.Having that information available meansthat the business analyst has carefullycollected, analyzed and modeled the datathe end user needs in a way that can beunderstood by the programmers and thedatabase designers.
What is a data
model?
You can think of your datamodel as your blueprint for
your physical database. Itsstructure is simple and its words
are in business language so that the subjectmatter experts facilitated by the BusinessAnalyst can understand and validate theirbusiness information. But also the structureand data details are sufficient for thetechnical database designer to build thedatabase correctly to support the businessrequirements. A data model includesentities, attributes, relationships and all theirproperties. There are several ways torepresent a data model, but the two mostcommon ways are diagrams or tables. TheEntity Relationship Diagram is the mostwidely used way to represent the physicaldatabase and is a recommended method forthe logical or business representation as well.As an alternative for those uncomfortablewith diagramming or using anunsophisticated modeling tool, a structuredtext table format method can be used todocument all data model components.
Hints to get started
Hint 1 – Take a formal course in datamodeling. Hint 2 – Buy a book on data modelingHint 3– Bring in an experienced datamodeling consultantHint 4 - Try more than onepresentation technique Hint 5 - Timebox your modelingactivities to keep the meeting on trackHint 6 - Recognize there is not onecorrect data modelHint 7 – Use post-it notes, a flipchart and a whiteboard for a moreinteractive session
Conclusion
Although data modeling may seemoverwhelming at first, start thinking aboutyour data today, even if that is just makinglists of entities and attributes with yourstakeholders. That is a step in the rightdirection. �
Lost in TranslationBY ANGIE PERRIS, PMP
“NASA lost its $125-million Mars Climate Orbiter because “spacecraft engineers failed to convert from English to metricmeasurements 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 ofmillimeters and meters in its calculations, while Lockheed Martin Astronautics inDenver, which designed and built the spacecraft, provided crucial accelerationdata in the English system of inches, feet and pounds.
As a result, JPL engineers mistook acceleration readings measured in Englishunits 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. LosAngeles Times. Los Angeles, Calif.: Oct 1, 1999.
the bridge l Fall/Winter 2004 12
CA’s AllFusion ERwin is one of theoldest and most popular data modeling
tools in the world. Built in 1992 byLogicWorks, Inc. and named for EntityRelationship for Windows, ERwin initiallyprovided a graphical Entity RelationshipDiagram that generated database DDL(data definition language). Suddenlydatabase designers were free from coding a
complex language and could focus ondesigning more normalized coherentdatabases. ERwin can generate DDL forover 30 commercial database packagesgiving your organization the flexibility tochange platforms more quickly.
The quality of the diagram with itsunderlying properties attracted theattention of data analysts who wanted asimilar tool to document business or logicaldata requirements. ERwin 2.0 added alogical diagram and an automated
translation from logical tophysical. This feature allowsbusiness analysts to documentbusiness data in a model andthen pass the model to thedatabase designer fortransition to design andimplementation. The tool alsoprovides utilities forcomparing models betweenproject teams or sub-teams.Later versions have addedentity and attribute namingstandardization and increasingflexible user definedproperties.
Every data component onthe diagram has a PropertiesWindow that the modeler canuse to documentcharacteristics about thecomponent.
In addition, ERwin DataModeler interfaces with theAllFusion Process Modelerwhich allows analysts todiagram processes and link
them to the data elements that the processuses. You can download an evaluation copyof AllFusion ERwin at www.cai.com. �
tool reviewAllFusion ERwin Data Modeler
A Physical (database design) Diagram
Entity Property Window
Attribute Property Window
Relationship Property Window
A Logical (business data requirement) Diagram
Answers toCrosswordpuzzle onpage 9
certified core courses
Essential Skills for the Business AnalystThis course covers the critical skills for the Business Analyst. Students will learnto define what is, and what is not included in the project, how to ask the rightquestions, when and how to hold interviews and facilitated sessions, how towrite excellent requirements, how to verify that requirements are testable, howto conduct a requirements review, and have an overview of various applicationdevelopment methodologies. Additionally, students will be introduced to variousdocumentation techniques and plan an approach for documentation.
Detailing Business Data RequirementsThe Data portion of the business requirements is a critical component to definingcomplete requirements. Every process uses data and almost all business rulesare enforced by data. Missing a critical piece of data or incorrectly defining adata element contributes to the majority of maintenance problems and results insystems that do not reflect the business needs. This course teaches students anin-depth approach to identify and define all necessary data components usingboth textual templates and an entity relationship diagram to create a data model.
Detailing Process and Business Rule RequirementsThis course continues the development of the requirements package by definingthe processes and business rules for the project. Students will learn to identifyand define the processes from a business and functional perspective. Varioustechniques are taught including decomposition diagrams, templates, workflowmodels, and Use Case diagrams and descriptions. Additionally, this courseteaches 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
4 Days
3 Days
4 Days
�
additional course offerings
Requirements Testing for the Business AnalystThis course provides an excellent foundation for Business Analysts who areinvolved in software quality assurance (SQA). The course will improve theBusiness Analyst's development of requirements so that they can be used tobuild quality test cases. It will also enable the Business Analyst to create specifictest cases from the requirements. The course includes a workshop case studythat 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 AnalysisThis seminar presents the Business Analyst role to managers and others wholead and work with Business Analysts. In order for the Business Analysts to besuccessful, both the IT and business community must embrace the businessanalysis process. The seminar can be used as a working session to discuss howyour organization will implement the business analysis process and approachesfor documenting the requirements.
Both large and small organizations are realizing the benefits of using BusinessAnalysts on all of their application development projects. A Business Analyst actsas a liaison between business people who have a business problem andtechnology people who know how to create automated solutions. Improving thecommunication between your business areas and your IT team significantlyincreases the quality of the systems developed.
A Business Analyst's main responsibility is to gather, detail, and documentrequirements in a format that is useful to their business area experts and thetechnical developers. Analysis is a very important and time-consuming phase ofevery project. This seminar provides strategies for how management can supportthe business analysis process.
For more information on these courses visit www.b2ttraining.com
the bridge l Fall/Winter 2004 14
4 Hour Seminar
3 Days
�
2005 public class scheduleEssential 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
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 601Alpharetta, GA 30004
Prsrt StdU.S. Postage
PAID
Permit #309Knoxville, TN
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