Articles and White Papers

By Phil Vincent, PMP, CBAP

“You start coding, and I’ll find out what the users want.”

It’s an old joke, but today’s business analysts are often confronted with a more modern version: “You start writing requirements, and we’ll figure out the project scope later.” Then we wonder why we have scope creep.

All too often, a project’s business requirements analysis begins when the project scope has, apparently, already been defined. But as business system analysis proceeds, stakeholders discover that they have very different pictures of the project scope, of what’s in and what’s out, and of what the new system is supposed to do.

Project Scope Tools for the Business Analyst

The responsibility for defining the project scope is often assumed by the project manager. He is likely to employ a tool — like a Work Breakdown Structure (WBS) — to define the deliverables, such as requirements specifications, design plans, source code modules and training delivery. The problem with a WBS is that it doesn’t provide a clear enough picture of the functional requirements, and as we all know, “the devil is in the details.” Project managers must focus on the broad picture, and should rely on a business analyst to focus on the requirements scope: Who will use the system? What do they need it to do? What information is needed to do it?

Today’s business analysts are equipped with two important tools for defining the project scope requirements: context diagrams and use case models. The first thing a business analyst should do when assigned to a project is to confirm that these two models exist, and have been approved and accepted by the stakeholders. If they don’t exist, or haven’t been approved, the business analyst should tackle these before starting detailed business system analysis.

Context diagrams have been around since the 1970s, since the days of structured business analysis and design, to describe the information exchanges between users and the potential business system. A context diagram allows the business analyst to clearly show the boundary of the system, the users (both human and other systems), and the high-level data provided by the system and to the system. A context diagram is only a high-level view, but when supported by detailed data definitions, it is an excellent tool for communicating part of the project scope to stakeholders.

Use case models were introduced in the early 1990s to describe what services a system will provide, and to whom. Use case diagrams show the major units of functionality to be provided by the system, and the human and system users (“actors,” in use case terminology) that will benefit from those services, or participate in providing those services. Diagrams are supported by detailed use case specifications, in the form of scenarios, describing how the system will be used. From these scenario descriptions, very detailed requirements, like business rules and calculations, can be derived.

Although context diagrams and use case models are highly effective business analysis tools for defining the project scope, many business analysts don’t use them because they seem to be too high-level. Also, defining project scope is difficult because it requires stakeholders to make commitments.

So a critical step in any project is to identify the stakeholders with the authority to approve the project scope of the functional requirements, and to obtain their approval using communication and business analysis tools such as a context diagram and use case model.

Okay, now that the project scope is defined and agreed upon, you can get started on the detailed requirements.

About the Author

Phil Vincent, PMP^® CBAP^®, Certified ScrumMaster and Certified Rational Solution Designer, is a Senior Consultant and Trainer for Corporate Education Group. Phil offers a wealth of experience and a passion for teaching, coaching and mentoring and is an expert in all aspects of the software development lifecycle, especially business analysis and project management.