Chapter 3
Defining Requirements—Business, Data and Quality
Abstract
Defining requirements creates the foundation of a successful business intelligence (BI) solution by documenting what will be built. The categories of requirements are: business, data and data quality, functional, regulatory and compliance, and technical. After extensive interviews with the business group, the development team uses these requirements to design, develop, and deploy BI systems. This is the most people-oriented process in BI development. It is where IT works most closely with business people and puts technology on the back burner. It can be a little tricky, because politics between groups may influence behavior, attitudes, and discussions in subtle ways. It may be a requirement to reverse engineer data shadow systems. Issues with people and politics may be out of the comfort zone of many in IT, resulting in land mines that can sink a BI project. Most BI failures are not related to technology shortcomings but rather to a failure of meeting expectations or of requirement surprises toward the end of the BI project. The result is projects that fall short of business needs, are late, and are over budget. You can justly blame poorly defined requirements for all these problems.
Keywords
Business requirements; Compliance requirements; Data requirements; Data shadow systems; Functional requirements; Regulatory requirements; Technical requirements• Purpose
• Goals
• Deliverables
• Roles
• Workflow
• Interviewing business people
• Documentation techniques
The Purpose of Defining Requirements
While groups might feel that they can take shortcuts and skip the justification process, almost no one is going to suggest skipping the process of defining requirements. They might, however, try to cut corners, which will hobble the project with murky requirements that put it on the path to failure.
It sounds pretty simple—defining requirements creates the foundation of a successful business intelligence (BI) solution by documenting what you are planning to build. The development team then uses these requirements to design, develop, and deploy BI systems. Traditionally, a business analyst (or someone in that role) handles this phase, which takes place early in the project and includes a lot of document writing.
Here is where it can get complicated, however. This is the most people-oriented process in BI development. It is where IT works most closely with business people and puts technology on the back burner. It can be a little tricky because politics between groups may influence behavior, attitudes, and discussions in subtle ways. Issues with people and politics may be out of the comfort zone of many in IT, resulting in land mines that can sink a BI project.
Most BI failures are not related to technology shortcomings but rather to a failure of meeting expectations or of requirement surprises toward the end of the BI project. (Oh, you wanted the dashboard to include customer lifetime value? Sorry, no one told us that.) The result is projects that fall short of business needs, are late, and are over budget. You can justly blame poorly defined requirements for all these problems.
It is also important that the business people know enough to know what to ask for with the new project. They cannot ask for something if they have not had any training or orientation that would show them that it is possible.
The most common mistakes in defining requirements are that they:
• Are not detailed enough to clarify what is needed and set expectations
• Restrict their focus to just business requirements
• Are not refined and changed as the project changes
• Do not involve business power users or BI designers and developers
• Re-create the existing system with its warts and inefficiencies
Making these mistakes can prevent you from delivering what the business needs within the agreed-upon time frame and cost. You would not think of building a house without a blueprint, so you should not proceed without a signed set of documented requirements. The documented requirements are used to guide the project, manage scope, and provide the input to the BI development team just as blueprints are used for building your house.
This chapter presents an approach and the best practices to define requirements and avoid these all-too-common mistakes.
Goals
The primary goal is to define the set of requirements that will be used to design, build, and implement BI solutions within an agreed-upon project timeline and budget. From a business perspective, it gets agreement on the business needs and their priorities, while from a technology perspective, it establishes what needs to be built in the three pillars of BI: data model, data integration, and analytical processes.
The secondary goal is for the BI team to establish the working relationships with its sponsors, stakeholders, and others that support the BI project. This phase is often the first opportunity for everyone in the project to work together:
• Business people who will ultimately be the information consumers
• Business and technology people who are subject matter experts (SMEs) in the analytical requirements, data source systems and data shadow systems
• IT staff members who support the applications and infrastructure for the BI solution
Initially, it is usually easy to identify the people involved, especially if the BI team has already been working in the organization. When more project details are uncovered, however, it can be necessary to engage additional people in the project.
This phase is the bridge between defining the project scope and designing the data model, data integration, and BI processes. Defining requirements often encounters the “Goldilocks syndrome” of being too hot or too cold, but never “just right.”
When too hot, the requirements process suffers from analysis paralysis, takes too long, and appears too bureaucratic. Although a waterfall-style software development life cycle (explained in Chapter 18) has many benefits, this project approach can be accompanied by an inordinate amount of documents that need to be filled out completely as to whether they are applicable to the BI project and its scope. This approach puts the emphasis on completing a checklist of documents rather than getting the right content to build a BI solution on time and within budget.
When too cold, the requirements are too high level, creating ambiguity both with the business and the people building the BI solution. The primary danger is that the business expectations do not match what gets built. In addition, BI developers will need to interpret high-level requirements, which takes additional time and can introduce errors. Most BI project failures are not caused by technology but rather a failure to meet business expectations. This is often caused by high-level requirements that lack the necessary detail to reduce ambiguity.
Deliverables
The primary deliverable is a set of requirements that business sponsors, stakeholders, and IT management have agreed upon. A supporting deliverable will be a revised project plan including budget and resource commitments based on these requirements.
The BI requirements documentation should include the following:
• Project description: Brief explanation of the project goals and objectives.
• Project functionality: Overview of key deliverables.
• Project assumptions: Outline of dependencies or prerequisites.
• Authors and contributors: List of people working on or assisting in documentation.
• List of inputs for requirements, such as:
• Interviewee lists
• List of databases and files examined
• Data source systems documentation
• List of reporting systems, reports, and data shadow systems examined
• Requirements: (see below)
• Requirement priorities: Subjective priority of requirements based on sponsor and users’ preferences.
• Issues and concerns: Resources, budget, schedule, scope, etc.
• Change management: Need to track changes (additions, modifications, and deletions) from requirements and when they occurred.
• Sign-offs: List of who and when requirements and changes approved.
The requirements need to be in sufficient detail to move on to following steps of designing the data model, data integration processes, and BI applications. A complete set of requirements would include the following subjects:
• Business requirements
• High-level business requirements
• Business processes supported
• Business rules and metrics
• BI functional requirements
• Use cases
• Process workflow and user interaction
• Analytical styles and functionality
• Data requirements
• Data sources
• Data conformance, consistency, and currency
• Data integration
• Data quality
• Regulatory and compliance requirements
• Country
• Industry
• Privacy and security
• Technical requirements
• Infrastructure standards
• Technology directions
The scope of the BI project will dictate which of the above subjects need to be included. The most extensive scope, requiring all of the above, would be for a first-time BI, data warehouse (DW), or master data management (MDM) initiative. A BI project that is expanding existing analytics on data already in the DW would be able to simply expand existing requirements documentation. The BI, DW, or MDM program should establish a library of documentation available for review, feedback, and leveraging follow-up projects.
The BI team will initially gather business requirements and then delve deeper into the details to define the associated data and functional requirements. This approach is referred to as stepwise refinement or functional decomposition, as shown in Figure 3.1.
Traditionally, the BI team follows a top-down process, gathering high-level requirements and then refining or decomposing them into more levels of detail. Sometimes, however, there is a need to work bottom-up by reverse engineering existing reporting systems or data shadow systems and then aggregating these details into higher-level requirements. Choose this approach when existing reporting systems are not documented but need to be replaced.
The best practice for defining requirements is a combination of bottom-up and top-down:
• Gather new requirements bottom-up to ensure that needed features in the existing systems become part of the new solution and are not lost.
• Determine existing requirements top-down to ensure that all business stakeholders have their say and you get to validate and fine tune the requirements through feedback loops.
Roles
It is important to spell out who does what, so no one is surprised. This project phase requires a lot of interaction between the BI team and people from other business and IT groups. This may be a time when the BI team feels out of their comfort zone because many of the activities involve people and politics rather than technology. Chapter 17 provides more details about the various roles on the project team.
BI Team Participants
A business analyst (or business systems analyst) takes the lead on defining requirements for the BI team. Depending on the scope and the business management level involved, the lead business analyst may need to be a very seasoned professional.
The key skills of the business analyst include:
• Ability to communicate with both business and IT people, including senior level management if necessary
• Knowledge of the overall business model and specific business processes in order to understand where the use of BI fits
• Being data savvy in order to explore data sources and metrics in detail
Traditionally, the business analyst role was the primary role filled by the BI team in defining requirements. Sometimes the business analyst was the only person involved from the BI team. With this approach, a set of business requirements was handed off to the BI team, which would then design the BI solution. A more effective approach for defining requirements significantly expands those requirements over the traditional approach both in terms of depth (more details) and in breadth (business, functional, and data requirements). With this new approach in mind, more members of the BI team get involved. In addition to the business analyst, these roles include:
• Data architect
• Data modeler
• ETL designer
• BI designer
These additional BI roles are not likely to participate in the initial interviews to gather business requirements but get involved as more detailed data and BI functional requirements are defined.
Business Participants
Although it seems obvious to say this, you have to talk to business people to get their requirements. It may be tempting to rely on BI developers or business analysts as proxies for business people, but this is a dangerous shortcut.
The business participants should be sponsors, stakeholders, or users of the proposed BI solution. These are the people who have a vested interest in getting their requirements fulfilled. The initial discussions may generate a huge wish list of everything the business ever wanted in a BI solution. In that case, figure out the priorities along with project planning that balances functionality, time, and cost before signing off on the BI project’s requirements. Even in the initial wish list, it is a good practice to have the business classify requests as must-haves and nice-to-haves to get them used to the idea of trade-offs in this process. (You will ask them to prioritize requirements in the final requirements document, as explained in Prioritizing Requirements, later in this chapter.)
The order of interviews will likely follow the stepwise refinement approach, where business management provides their business requirements and then you get more details from their staff and other business people who are directly involved in business analysis. The business roles often included are business analysis, financial analysis, and business management. Although not an official title, business “power users” are key participants.
When interviewing an executive, invite the person on her staff who she relies on for analysis. Although you will likely be meeting with that “go-to” person in follow-up meetings anyway as more detailed are defined, it is good to have him in the initial meeting so he can step in as needed to clarify the executive’s business requirements.
Other IT Participants
Besides business people, there are other stakeholders from the IT group who should be interviewed to assist in gathering more detailed data and functional requirements. The IT roles that may be included are subject matter experts (SMEs) for the following areas:
• Data source systems
• Applications used in applicable business processes
• Existing reporting systems
• Infrastructure and services
Defining Requirements Workflow
To build the BI solution, the BI team needs to gather the business, functional and data requirements from business and IT in sufficient detail. The process is depicted in Figure 3.2.
The process starts with defining business requirements, followed by defining data, functional, regulatory/compliance, and technical requirements. If there are existing undocumented reporting applications or data shadow systems, you need to reverse engineer them. You can do these three tasks in parallel if you have enough resources, but be sure to coordinate and share findings.
Business Requirements
The initial task in this process is to obtain business requirements from the business sponsors, stakeholders, and BI users. Gathering requirements is done primarily though interviewing, which is discussed in the following section.
Business requirements typically are associated with particular business processes and business groups. This association identifies who and what will be affected by the BI solution. This potentially expands the stakeholders who need to be included in discussions and the interconnections other systems may have with the BI solution. Ensure that requirements address the change-management issues affecting these business processes and groups.
Business requirements may depend on new or revised business processes, along with new transactional systems or modifications to them. If these changes are occurring, then the BI project scope is more than just the BI solution; it may be highly dependent on the success of the new business processes or enterprise applications implementation.
While defining business requirements, it is crucial to define the business metrics—also referred to as performance metrics, measure or key performance indicators (KPI)—that will be required in the BI solution. Business is driven by these metrics, and they are the cornerstone of analytics. Too often, the details of these business metrics, particularly what data is needed and how it needs to be transformed, is either discovered very late in the BI development process or not at all. This is a very real risk. If it is missed entirely, then business people will be very frustrated that they cannot perform the analysis they need with the new BI solution.
Defining metrics often gets into details that the initial business interviewees do not know. You will need to get the details from the business power users who have been calculating the metrics manually or by reverse engineering existing reporting or data shadow systems.
Data (and Data Quality) Requirements
Business requirements need to be detailed enough to identify the data sources or systems of record (SOR), such as applications, databases, or files needed to build the BI solution. (The SOR is, by definition, the authoritative data source.) Defining data requirements means drilling into the data sources to identify detailed data content, such as columns within tables or fields within files, and the transformations that are needed for consistency, conformance, or to calculate the business metrics.
In the early days of data warehousing, IT generally extracted all the data that was available in SORs in case it would be needed in the future. Nowadays, most enterprises have too much data in their SORs to just dump it in the DW, so the BI team needs to be more judicious in selecting what is really needed for analytics. There has been a trend to focus too narrowly when extracting data from SORs, resulting in BI projects continually revising their extracts as each new data requirement arises. The best practice is to extract the data needed by current requirements but also to include related data.
The other area too often overlooked is examining the source systems’ data quality in relation to what is being requested for analytics. If there are gaps caused by data quality issues or the data content does not even exist, then the impact on requirements needs to be addressed. These gaps may require:
• Identifying new sources
• Defining data cleansing processes
• Defining MDM processes
• Creating new data capture applications (outside the scope of the BI project)
• Dropping the data requirement until it can be fulfilled
The reason why this analysis is skipped is because people feel that the source systems own their data quality issues and the BI team is just bringing in the data as is. Although the BI team cannot be blamed for the data quality issues, it can be blamed for not identifying and addressing the problems while defining data requirements. Quite a few BI projects have been waylaid by source–system data quality issues identified very late in the project, and there is no excuse for this.
Do not assume anything about the state of the data. The areas where data quality and inconsistency problems lurk include:
• Data quality within SOR may be “masked” by corrections made within existing reports or spreadsheets created from this data. The people using these reports or spreadsheets might not even be aware of these “adjustments.”
• Data does not age well. Although data quality may be fine now, there is always the chance that you will have problems or inconsistencies with the historical data. Over time, fields are sometimes used for different content or have different business rules applied to them.
• Data quality may be fine within each SOR application, but may be very inconsistent across applications. Many companies have problems with inconsistent master data in product, customer, and other dimensions that will not be apparent until the data is loaded into the enterprise DW. Data inconsistency needs to be identified as part of the data requirements process.
The BI team needs to perform data profiling or source systems analysis to determine the current state of data quality and its consistency within and across source systems. Traditionally, this type of analysis, if it was done at all, involved manually querying databases and examining files to determine their structure and content. This process was labor intensive and only sampled a portion of the data due to the time it took. Currently, there are various categories of tools that automate data profiling and are quite exhaustive in examining content both within and across source systems. We will discuss this in more detail in Chapter 12.
Based on the data profiling results, perform a gap analysis to determine the current state of data quality within and across source systems regarding the data requirements. With the gap analysis, determine what corrective action, if any, can be done to plug the gaps.
Review the gap analysis and potential corrective actions with the business, asking them to determine if and how the gaps affect their requirements. The business options are to continue with the data quality as is, change their data requirements, or take some corrective action. If they are interested in taking corrective action, then they need to assign a value to that action to determine if it is a must-have. When the BI team revises the project plan and budget after defining the requirements, you want to identify the cost of these corrective actions and get final business sign-off.
Functional Requirements
There is a tendency for functional requirements to be very generic, such as providing the ability to “drill down into data details,” “access multiple sources,” and “perform role-based security.” These types of generic functions should be evaluation criteria for BI products rather than BI functional requirements. Without more details, how does the BI development know what to build?
This is a symptom of oversimplifying BI as if it is nothing more than accessing data. BI is a lot more complicated than that—it supports business processes and decision making by giving a business person the ability to analyze data. Functional requirements are a description of that analytical process.
BI functional requirements need to include the following:
• BI use cases
• Analytical process workflow and user interaction
• Analytical styles needed
BI use cases document the why, where, and how of business people using the BI applications while performing their jobs. High-level examples of this include sales pipelines, supply chain management, emergency room wait time, and product profitability analysis. Of course, use cases should get more detailed than these examples and provide information such as who the users are, what data is needed, and what metrics need to be examined.
The next portion of the functional requirements is describing the analytical process workflow and user interactions. Once you identify the business processes involved, it becomes clear that analyzing data and metrics is rarely a one-time occurrence. Rather, it is a succession of analyses that are often interconnected. Documenting the workflow and dependencies enables you to design a more productive BI environment for the people using it. Two common techniques, described in more detail in Chapter 14 are:
• Business process modeling
• Storyboarding
Although process modeling has been the traditional approach, storyboarding is becoming the best practice; it is easier for nontechnical folks to understand, enabling better interaction and feedback. Storyboarding is a very effective tool at documenting the process the business person goes through when planning to use BI.
Regulatory/Compliance Requirements
An enterprise’s adherence to laws, regulations, guidelines, and specifications is going to vary depending on a range of variables including the countries that are involved, the industry, the individual business, and the type of data. The complete checklist for all compliance and regulatory requirements is beyond the scope of this book, but some common examples include:
• Sarbanes-Oxley Act of 2002—retention of financial data for seven years.
• USA Patriot Act—access to data by U.S. law enforcement and national security agencies.
• Health Insurance Portability and Accountability Act (HIPAA)—rules such as encryption for the security and privacy of health data.
• Markets in Financial Instruments Directive (MiFID)—a European law dictating transparency requirements for investment firms.
• Basel Committee on Banking Supervision—international standards for handling risk in the banking industry.
• Payment Card Industry (PCI)—data protection and security standards for credit, debit, and other payment cards.
When you are gathering requirements, be aware that people you are working with either may not know all the relevant and required compliance and regulatory rules or may assume that you already know them.
Make note of security and privacy requirements when working within a supply chain or when the enterprise shares data with suppliers and partners. There can be issues with compliance, information exchange, and country boundaries. For example, a call center in one country may need to comply with different rules as to what employee data can be shown in a dashboard.
Technical Requirements
You may need to follow technical requirements, standards, or guidelines that you are not even aware of. These requirements could be issued by the CIO, an IT group with responsibility for infrastructure or architecture, or the business group you are working with. There may be no discretionary leeway for these, so be sure to ask about them up front.
Technical requirements can include:
• New technology directions, such as whether work is done in the cloud or on the premises
• Policies on where the data centers are located
• What vendor hardware and software can be used
• If BI appliances are required
• If Web services are required
• Rules on who can access the databases (some enterprises only allow one group to access the database, so you will have to work with them)
Reverse Engineering (When Necessary)
It is rare to create a BI solution with no existing reporting capability in place. The existing reporting system may be part of the operational application, it might have been a previous attempt at BI, or it might be a data shadow system (also called a spreadmart) created by business users. In most cases, if the analytical need is important enough, then the business has been doing something, no matter how imperfect, to get data and analyze it.
Almost no data shadow system is documented, and many older reporting systems might likewise have little or out-of-date documentation. With this in mind, there are two reasons why the BI team will need to reverse engineer some or all of the existing reporting or data shadow systems:
• First, for comparison—although business users may complain about their existing reports or data shadow system, they have been using them for analysis for some period of time, so these systems are now the benchmark for comparison. This comparison happens even when the BI team believes and has documented that the new BI solution is better in terms of data quality, consistency, currency, and completeness than the old. The only effective way to compare and contrast systems will require the older system be reverse engineered.
• Second, for better understanding—even when the old systems are being discarded and the business is providing “new” requirements, it is fairly common for many of the business rules and data used by the business in the old systems to be relevant. The problem is that often the business person providing the new requirements either forgot about those business rules and data or just assumed that the BI team would understand what those rules and data were. Reverse engineering fills in the inevitable gaps in detailed requirements, keeping the new BI solution from being derailed when business users start using it.
The bad news is that reverse engineering takes time and is not something IT folks are especially excited about doing. The good news is that the bulk of the work should be able to be done by the business power user who created or is maintaining the data shadow system. In addition, enlisting the power user brings that person into the BI virtual team, creating an advocate for the new BI solution and presenting the business with their “trusted advisor” in relation to this analysis. If the power user blesses the new solution, then business adoption is almost guaranteed.
Putting It All Together
You will need to collect business, data, functional, regulatory, technical, and, if applicable, existing reporting requirements from different business groups and people who may have different needs or at least different viewpoints regarding those needs. As the scope of the BI solution expands, so too does the diversity of business groups and requirements you gather.
It is crucial to consolidate and coordinate the varied requirements into a cohesive BI project requirements document. This is the only way to “see the forest from the trees” and determine which requirements truly drive value. The consolidation process identifies overlapping, redundant, outdated, and conflicting requirements. It also identifies gaps and missing elements based on dependencies that might not have been apparent before the consolidation.
Consolidate and cross-reference (or tag) the requirements along the following dimensions:
• Business value
• Business processes
• Business group
• Data sources
• Analytical functionality
Is the business driving projects within strategic business plans? If so, you will need to categorize requirements by this information in addition to the above criteria. This will be discussed in Chapter 18.
Prioritizing Requirements
Although business and technology participants should validate business, functional, and data requirements as soon as they are gathered and documented, make sure the consolidated requirements documentation is made available for final review and feedback. This process enables the team to validate consolidated requirements, clarify misunderstandings, correct mistakes, make revisions, and, if appropriate, add requirements. The method for collecting the feedback will depend on what the BI team established in their initial project plan.
With the consolidated requirements documentation validated, the next step is to meet to review and prioritize those requirements. The discussions should include the following:
• Who was interviewed
• List of business requirements by business process
• Brief description
• Commonality of requirement across business groups
• Feasibility
• List of data sources
• Commonality of requirement across business groups
• Brief description of data gaps and data quality issues
• Dependent corrective actions, if applicable
• Brief description of functional requirements
• Commonality of requirement across business groups
As we discuss in Chapter 18, the best practice is to develop BI within the context of a BI program with iterative and incremental BI projects gradually building out the long-term BI vision. Within this context, the business will understand that rather than trying to do everything at once, they need to set priorities.
Never accept that every requirement is a top priority. At a minimum, the business needs to classify the requirements in its initial reviews as:
• Must-have
• Should-have
• Nice-to-have
• Forget about it
This classification is solely from the business perspective. You also need to assess business and technical dependencies that may impact prioritization.
You should have developed an initial project plan and budget when the BI project was scoped and justified. The BI team will need to review the consolidated requirements prioritization to determine what can be done within the existing project plan and budget. If all the must-haves can be developed, then it is likely that the BI team will have the approval to proceed. If, however, not all of the must-haves can be developed within existing project constraints, then business sponsors’ choices are:
• Proceed with a set of must-haves that can be accomplished within the existing plan and budget. If there are alternative selections, then the business and BI team need to agree on the list of requirements that will be delivered.
• Reduce the scope of some of the must-have requirements so that they can be accomplished within the existing plan and budget. This might be possible, for example, by implementing with a reduced number of data sources for the initial project iteration.
• Increase the budget and lengthen the schedule based on a revised list of requirements for the BI project.
Regardless of what choices are made in the prioritization process, it is crucial to get a business sign-off on the requirements for the BI project. The BI team and it sponsors should consider this a contract between them.
Interviewing
The primary technique for gathering business and functional requirements is interviewing. This section will discuss how to:
• Prepare for the interviews
• Conduct the interviews
• Follow up after the interviews
Preparation for Interviews
The BI team members conducting the interviews need to prepare to make them productive and engaging. There are three preparation areas:
1. Background information on the enterprise and interviewees
2. Creating a list of subject areas and, ideally, specific questions to be covered in the interview
3. Inviting participants and providing the information from above
First, the background information check for requirement interviews is similar to what one would do for a job interview. The BI team needs to be somewhat knowledgeable about the following subjects as they apply to the proposed BI solution heading into the interviews:
• Enterprise’s business and customers
• Business and technology initiatives
• Business terminology and acronyms
• Business processes that proposed BI solution will be used to support
• Interviewees’ title, organization, and background
Performing due diligence on these areas is important. If the BI team is familiar with these subjects and interviewees, then this part of the preparation will be brief. Background information on the organization, its business, financial performance, its industry, its competitors, and its customers is available on its Web site and outside financial sites. Other information may be on its intranet: business and technology initiatives, business terminology and acronyms, business processes, and organizational information. In addition, do not overlook business-oriented social media sites as a great source of background on your interviewees.
Second, the BI team needs to determine what subject areas they will focus on during the interviews. If possible, it is useful to know what business processes and existing reporting or data shadow systems the interviewees use in order to better focus the discussion and make it more productive.
Some sample questions for business interviewees can include:
• What are your roles and responsibilities?
• In each area:
• What information do you need?
• How is that information gathered and analyzed?
• What reports or data shadow systems do you use?
• What information do you lack and how valuable is it to you?
• What new types of business analysis would be useful to you and how?
• Do you rely on others to perform this analysis? If so, who does it?
• If a specific report or information is no longer available, what is your backup plan?
When interviewing technology people, it is extremely important to have an understanding of a person’s background and what systems or processes they are involved in that relate to the BI project. BI people find these interviews easier than interviewing business people because they “speak the same language,” i.e., technical jargon, and they often know more about the systems in which these people are involved. The line of inquiry will be to examine the applications and databases that they work with that are relevant to the BI project.
Finally, even if interviewees have already been asked to attend requirements-gathering discussions, send a formal invitation to all potential attendees. This invitation should include:
• Meeting time, location, and list of potential attendees
• Brief overview of BI project
• Goals and expectations of meeting and participants
• List of subject areas to be discussed (if known)
• Sample of list of questions (if available)
• A list of decisions that need to be made
The interviewees’ time is valuable; allowing them to prepare for the meeting is well advised. Often the attendees do not really prepare for the interview sessions but, at a minimum, the invitation gives them a chance to at least glance at what the interview sessions are about. In addition, the invitation content is an excellent framework for the meeting agenda regardless of the attendees’ preparation.
Conducting the Interviews
Whether the interview is a one-on-one discussion or a group meeting, the agenda published in the meeting invitation should guide the meeting. It is important to take notes and, if possible, record the meeting (with permission). There are many conference, tablet, and smartphone applications for recording, but for greater productivity, I prefer a smartpen application that synchronizes the recording with bookmarks in my notes.
When interviewing business people, a common mistake is to ask an open-ended question such as, “What do you want in regard to reporting and analytics?” This inquiry generally results in a business person either being focused on current limitations in their existing reports or asking for every piece of data their enterprise has and maybe more. In either case, the BI team often feels like the business person does not know what they want or does not understand what BI can do for them. The problem is not with the interviewee, but rather with the interviewer who abdicated responsibility to direct the discussion. A better question would be something specific like, “What is the most valuable report that you currently run from your data shadow system or on your own spreadsheets?”
Ideally, the interviewers are prepared with subject areas to discuss and a list of questions. But the questions are just a starting point; the interviewee needs to delve into the areas that will yield the most information regarding the interviewee’s requirements. Interviewing is an invaluable skill and includes an element of detective work. The interviewer needs to be flexible and follow the line of inquiry to where it leads.
Reviewing Interview Content
Try to review your notes (and recording, if you have it) as soon as possible after the interview. Although it is tempting to schedule interview sessions back-to-back, there are several good reasons to leave yourself time in between them to review what was discussed. First, you need to be very attentive during each interview; a day-long series of meetings will tire even the most dedicated person. Second, there may be overlap between what interviewees discuss—this will all blur together if you have meetings back-to-back. Finally, the interview may raise questions or ideas that you are going to want to write down and digest before you lose those trains of thought.
If there was more than one interviewer or BI team member in the interviews, then you should hold debriefing meetings where all present review their interview notes. It is best to conduct the interview and then hold a debriefing meeting immediately afterward (before the next interview session).
When reviewing your notes, either individually or in a debriefing meeting, you need to perform the following:
• Complete partial notations. Often you will be scribbling something when one of the interviewees says something else that you need to capture. Try to complete these partial thoughts while you remember them.
• Identify areas where there is confusion or potential misunderstanding (if team members have different interpretations).
• Identify data sources, business processes, and business initiatives involved in BI.
• Identify stakeholders and business people who will be using the BI solution.
• Identify common, repetitive themes among interviewees.
• List business issues, concerns, or risks discussed.
• Determine (or agree upon) key findings or issues from the interview.
• Identify conflicting information or requirements among interviewees.
After the interviews, you should send a thank-you note and, if at all possible, attach a quick summary of the interview, listing topics discussed, agreed-upon action items, and outstanding issues. If you cannot do both at the same time, please do them as soon as possible. This is not meant to be the interview write-ups that you will review with the interviewees (below), but rather a quick acknowledgment of the interview. This is a similar practice that a job candidate would do after a job interview.
Interview Follow-ups
You will need to have follow-up discussions with interviewees to clarify items, resolve disparities, and to expand upon the topics discussed. These discussions need not be formal meetings, but may be handled more effectively with one-on-one or informal group conversations. The reason for this approach is that often the questions are very specific to particular people or topics.
In addition, schedule follow-up meetings with subject matter experts (SMEs) to discuss data sources, functionality, or existing reporting in more detail. This is the stepwise refinement process where you start with business requirements, and then develop more detailed requirements on data, functionality, and current reporting systems applicable to the BI project. These follow-up meetings help you define requirements in sufficient detail to guide the project.
It is a best practice to document the interview and include the following:
• Interviewees, titles, responsibilities
• Business objectives
• Business initiatives
• Business processes
• Data subjects and sources such as application and databases, if possible
• Issues, concerns, or risks
• Success factors
After documenting the interview, send a copy to the interviewees and conduct a follow-up meeting with them to validate the content. Revise the document as necessary, and then, most importantly, get the interviewees to sign off on the document. This serves two purposes: first, it ensures that the interviewees do indeed agree on the content, and second, it serves as explicit permission to publish the document for other stakeholders to review. If there are materials that are not meant to be shared, be sure to clear them up prior to publishing.
It is tempting to be less formal and skip the interview documentation step—resist those urges! BI projects too often fail to meet expectations and deliver what the business is asking for precisely because this step was not taken seriously, allowing misunderstandings to arise and kill the project.
Documenting Requirements
The process of collecting requirements involves a stepwise refinement, starting with business requirements and then delving into more details on data and functional requirements, followed by a review of the current state of reporting. You should document each of these processes during the requirements workflow, gathering feedback from applicable stakeholders and refining the document throughout the process. It is much easier and productive to create the documentation while you go rather than waiting until you have completed all the tasks. If you wait, it is guaranteed that you will forget things and risk shortchanging the process by getting behind schedule.
The key topics in the requirements documentation include:
• Business requirements
• Data requirements
• Current state reporting assessment
• Feasibility analysis
• Critical success criteria
In the “dark ages,” documentation meant an excessively long Microsoft Word document that few people read, and that was likely very verbose or poorly written. People spent way too much time on writing prose, editing it, and then finally giving up on it altogether. Once reviewed, the document went into a folder never to be seen again. This is bad practice!
The best practices today are to use collaborative tools to manage the content and as many visual tools or techniques as possible. Although visual techniques reduce writing, the primary benefits are improved communication and increased productivity.
There are many collaborative tools that can be used in documenting requirements. The simplest technique is to have a documentation tool with revision capabilities to track changes and enable the document owner to accept or reject changes from each reviewer. There are many sophisticated collaborative tools from general purpose to those geared to project management and requirements documentation; price tags range from free to expensive. You can also find collaborative tools that work in the cloud and on mobile devices; these may improve access and participation. If your firm has adopted a collaborative tool, then use it.
Using a collaborative tool is recommended for documentation, but do not rely on it for gathering requirements, especially business requirements, since nothing replaces interactive discussions between the stakeholders and you.
There are specific techniques or tools that you can use when gathering various requirements:
• Business requirements
• Storyboards
• BI mock-ups
• Prototyping BI objects
• Data requirements
• Data profiling
• Output from data modeling, ETL, and BI tools
• Functional requirements
• Storyboards
• BI mock-ups
• Prototyping
• Current state of reporting
• Sample reports or spreadsheets
• Sample data
If you choose the type of project methodology we discuss in Chapter 18, using storyboarding, mock-ups, or prototyping is an extremely effective method to gather, validate, and document functional requirements. These visual techniques are a much better way to communicate and establish joint expectations than writing dozens of pages of prose. Similarly, data profiling and output from BI tools is a great communication tool when working with the BI developers throughout the BI project.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.