Preface

We all know that correct and complete business requirements form the foundation of a “good” system. We admit that without these, we would develop systems based on pure conjecture or unverified assumptions. Yet so many systems are designed and constructed even before the business requirements are completed. This I call utter insanity! Doing this is almost akin to building a house without a blueprint or without a solid foundation. The house may look good, with bells and whistles and beautiful features, but a house without a proper foundation will eventually crumble.

From my humble start as a programmer and a programming trainer in the early 1970s (using Assembler, Fortran, and COBOL), then progressing to actually writing code (which I absolutely enjoyed), designing systems, liaising between business areas and technology groups, and managing projects, I have always believed that there must be a better way to define business requirements. When I was a young programmer and a user told me what he needed a system to do, I used to say, “Hey, I can code that right now!” without regard for how working without formal requirements might affect the rest of the system or the rest of the organization. Now I recognize the necessity of asking challenging questions like these before simply diving in:

• What is missing?

• Why haven’t we established a firm foundation for this system? Is it because:

This quest for an approach that works led to XCellR8™. The training sessions I have delivered to different organizations over many years led me to believe that many analysts have no idea where to begin gathering business requirements. If you are among them, this book will guide you in the right direction.

XCellR8™ is a logical, methodical analysis approach that everyone can learn. This innovative and engaging method of gathering business requirements is for those who have wondered why business requirements are needed at all. Defining business requirements does not have to be a painful experience.

This book discusses the concepts of the XCellR8™ approach and their practical applications to help you in your work. I have incorporated some anecdotes—both positive and negative—from previous projects to emphasize critical points.

This book offers business analysts the foundation, principles, and steps they need to become excellent facilitators in a world where gathering information is as important as the design and development of a system itself.

The XCellR8™ approach is not a magic bullet that will solve all of your organization’s systems problems, nor will it develop your systems in the blink of an eye. But it will ensure you have everything needed to gather and document your business requirements in an accurate and efficient manner.

The tools described in this book may be familiar to you, but I think you will find that the approach is quite innovative. We know that some readers want instant answers, short-term gratification, and fail-safe tools. But when performing business requirements analysis, the most important factors are your ability to ask the right questions of your users, to document their responses properly, and to ask follow-up questions. This book will show you how.

Often, communication between the business and development groups is nonexistent, or at least ineffective. My intent in presenting the XCellR8™ approach is to help bridge the chasm between these two groups, whether perceived or real.

The Importance of Business Requirements

Why should we even bother to gather business requirements? Why don’t we just push forward and start development immediately? The importance of requirements should not be underestimated or ignored. Studies have shown¹ that incomplete requirements or a lack of requirements, unrealistic expectations, and changes in requirements or specifications all contribute to projects’ failure. Other studies² have shown that software errors are more expensive to repair the later they are detected in the development life cycle. User involvement in defining business requirements, a clear statement of goals, and realistic expectations all contribute to project success.

Gathering Business Requirements

Anyone who has attempted to elicit and document business requirements will tell you that it can be a frustrating and aggravating task for a variety of reasons. For example, users may be unavailable or uncertain about their needs. This book clearly explains the process of gathering requirements, helping you do so quickly, accurately, and thoroughly. It offers a repeatable, structured approach that will work in every industry, allowing you to elicit the business requirements for any kind of project, be it a data warehousing, process engineering, process mapping, or technical project. You don’t have to be an expert on the subject matter itself. You may be thinking: “What? I don’t need to know anything about the business, yet I will be able to elicit business requirements effectively?” Absolutely!

The XCellR8™ approach will help you track your progress and ensure that your analysis is comprehensive. The methods and techniques described in this book are based on best industry practices and conventions. XCellR8™ is a logical, systematic approach to gathering business requirements that practically guarantees completeness of the requirements.

This book will help you:

1. Develop questions. Initially, rather than getting bogged down in eliciting design requirements, focus on what the business must do, and apply the design requirements to the business needs later.

   To elicit business needs efficiently and effectively, know what questions you must ask to draw out the information you need. More important, determine your follow-up questions so that nothing falls through the cracks.

   Business analysts often say that they do not know what questions to ask the business group. Meanwhile, business groups often don’t know what information to give to business analysts.

   To produce a business requirements document that makes sense to everybody, business analysts must ask relevant questions—questions that draw out answers everyone can easily understand. Before creating the requirements document, ask these questions:

   What information must be included in the document?

   Where will you get this information?

   Who is the audience for the requirements document?

   What templates should you use to create it?

2. Facilitate a requirements session. Requirements session facilitators or analysts are not just meeting facilitators. They must think on their feet to analyze responses and recognize when follow-up questions need to be asked. They are expected to keep control of the people in the room and stay within the framework of the session. Requirements facilitators can easily morph into meeting facilitators, but meeting facilitators may not necessarily be effective requirements facilitators.

3. Validate business requirements. How do you know when the business requirements document is complete? How do you identify scope creep? How do you identify the functionalities that are ignored, missed, or completely forgotten? One way of validating business requirements is to walk the business group through the whole desired end-state to make sure that everyone agrees about what the final product should look like. The walk-through is a good and efficient way of discovering the gaps in the process or in functionality. Chapter 7 offers guidance on how to determine the completeness of business requirements. This is not just a checklist; rather, it’s a way of analyzing your work to determine if it’s truly complete.

4. Translate the business requirements into functional specifications. What should you do once you have elicited and documented the business requirements? If you follow a typical industry-accepted systems development life cycle, you develop the functional specifications from the business requirements by applying design considerations to the requirements. In today’s world, business requirements are most commonly translated into use cases, which are discussed in Chapter 9. The use-case approach ensures that the functional design can be traced back to the original requirements.

5. Write test scenarios. A test scenario is a set of test cases that run the new system from start to finish to ensure all the required functionalities are in place. How will you determine how many test scenarios you should run? How will you ensure that the test scenarios can be traced back to the original requirements? Test scenarios allow the business group to articulate various situations they encounter in performing their jobs on a daily basis. When test scenarios are identified, testers can establish the possible combinations of data (test cases/scripts) that could occur, and also highlight which ones may be dependent on the result of the previous scenario.

I hope the XCellR8™ approach will enhance your ability to gather business requirements, bridge the gap between business and development groups, and develop the best products for your customers.

Gerrie Caudle
Brampton, Ontario

NOTES

1. For example, a joint study by TechRepublic, Inc., and its parent Gartner Group, Inc., found that 40 percent of IT projects fail, costing the average IT organization approximately $1 million each year. The same study claims that roughly 40 percent of all IT projects fail to meet business requirements.

2. These studies were reported in E.B. Daly, “Management of Software Development,” IEEE Transactions on Software Engineering 3, no. 3 (May 1977): 229-42; B.W. Boehm, “Software Engineering,” IEEE Transactions on Computers 25, no. 12 (December 1976): 1226-41; and M. Fagan, Design and Code Inspections and Process Control in the Development of Programs, Technical Report TR 21.572, IBM Corporation (December 1974). Results were compiled in Alan M. Davis, Software Requirements Revision Objects, Functions, and States (Upper Saddle River, NJ: Prentice Hall, 1993), 25.