|
Questions? Call 1.800.288.7246 | |
 |
|
 |
Home
Business Analyst
Knowledge Base
How Should a Business Analyst Define “Project Scope?”By Phil Vincent
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 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
|
|
||||||||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||||||||||
