2 | How Should a Business Analyst Define Project Scope?
300 Brickstone Square • Suite 201 • Andover, MA 01810 USA • 1.800.288.7246 • +1.978.649.8200 • info@corpedgroup.com
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, such as 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.
Figure 1: Example Context Diagram
