Scoping Diagram

A Requirement is a condition or capability that must be met by a system or component to satisfy a contract, standard, specification, or other form of request.

 A Scoping Diagram is used to draw a picture of the primary requirements and users/interacting systems.

Scoping Diagrams are used to help communicate the scope of a Product or Product Family. Scoping diagrams can take a number of forms depending on the type of Product being developed (user facing/system facing etc.) as well as the experience of the team and stakeholders. Two primary forms are “Integration Modeling” and “Use Case Modeling”. Both serve the same purpose and can even be mixed and matched. In either case we do not recommend formal separation between layers of requirements, formal traceability management or extensive documentation. The best way to ensure that the right Product is built is to build some of it, not write about it.

In some user facing systems User Experience (UX) Driven Design can take the place of Integration modelling.

Integration Modeling involves creating a diagram showing the main Integration Scenarios and who interacts with them, whereas Use Case modeling serves the same purpose with different (and more limited) symbology. Scoping Diagrams are used to form a graphical representation of the scope of a Product’s functionality. The diagram is used to illustrate the types of users, system boundary, primary functionality and other systems that interact with the Product of interest. Scoping Diagrams are derived from Features and Integration Scenarios and so each element (such as a Use Case symbol or Integration Scenario symbol) will be traceable to at least one of these.

In this article we’ll build a diagram using Use Case symbology but the same technique is applicable for Integration Modeling as shown in the above diagram.

We recommend maintaining a light touch on the Scoping Diagram, especially when using Use Case symbology, preferably identifying the use cases by name and limiting the amount of elaboration to a brief description only.

Instead of elaborating Use Cases textually in a document we recommend instead leaving them at graphical level (the Scoping Diagram). We then create a set of User Stories (with customers and users) that trace to the Scoping Use Cases or Integration Scenarios, this ensures that User Stories relate to the system scope and provides teams with smaller requirements chunks to develop (supporting continuous flow or agile/iterative workflows).

Paths through a system that cover a diverse set of stories (even across Scoping Use Cases) are better described using Integration Scenarios than Use Cases.

Developing a Scoping Use Case Model

Scoping Diagrams that use a simplified version of traditional Use Case Modeling focus on identification of top-level use cases (as Integration Scenarios, collections of stories or epics) and user/system/actor interactions. An “actor” is defined as an external stakeholder that the system interacts with, and used to represent types of users and integrating systems.

  1. Start by drawing a big box (on a whiteboard/table or a drawing tool) to represent the system.
  2. Identify types of users (or systems) that will require some interaction with the system (place these on the left of the system boundary by convention)
  3. Identify other systems that the system will interact with (place these on the right by convention)

We recommend color coding human actors vs. system actors if using UML.

  1. Then identify what top level scoping requirements each interacting user/system needs (by asking: “what does this actor need?”)
  2. These Use Cases are typically drawn as ovals and given a simple name that represents the requirement in the form of a verb-noun pair such as “Manage Invoices” or “Run Sales Analytics” although we do not recommend slavishly following this convention, clarity is more important than standardization
  3. We then draw lines from actors to Use Cases/Integration Scenarios that indicate who starts the communication, and what systems the requirement needs to interact with.
We’ve only named two of the Use Cases/Integration Scenarios here but in reality they should all be named. It’s often useful to describe the Use Cases/Integration Scenarios in terms of a sentence or two to help explain its purpose but we don’t recommend more than a couple of sentences. As mentioned above further elaboration should be in the form of User Stories.
If you’re using Integration Modeling symbology then the diagram can be further elaborated to indicate key integration flows, critical stories or GUI Storyboards and other UX elements.