How Should a Business Analyst Define “Project Scope?”

Boston University Corporate Education Center - International Institute of Business Analysis (IIBA) Charter Endorsed Education Provider (EEP) Boston University Corporate Education Center is a Charter EEP of the IIBA. Let the Boston University Corporate Education Center business analyst training experts help you succeed. Contact us today, by calling 1-800-BUTRAIN or browse Boston University Corporate Education Center's business analysis courses now.

"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’' 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.

Figure 1: Example Context Diagram

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.

Figure 2: Example Use Case Diagram

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.

Discover How Boston University Corporate Education Center’s In-House Business Analysis Training Consultants Can Save You Time and Money
Learn how to quickly and effectively improve business systems analysis in your corporation today. Contact us today, or call a Boston University Corporate Education Center Training Consultant now at 1-800-BU-TRAIN (288-7246).