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 bcarkenord@b2ttraining.com.
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 sales@b2ttraining.com.
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 sales@B2Ttraining.com
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