Scoping is about understanding the "big picture" and understanding a project’s limits. My observation as a Business Analyst at Mediacurrent is that because project teams don't have unlimited time and money, it's important that all stakeholders understand clearly – and visually – where a project's boundaries are. Scoping ensures we, as your agency partner, know what needs to be included to deliver on the business goals and objectives within time and budget constraints.
A powerful visual aid for expressing scope at a high level is a Context Data Flow Diagram (DFD), which displays the following:
- Actors that will be impacted the project. They can be people or systems.
- People can include project stakeholders, an organization’s customers, personnel, and more.
- Systems are non-human actors, e.g. servers and software applications, that may require an interface to the proposed solution
- Data flows between actors and the proposed solution
A Context DFD is best used before the project begins, so all stakeholders and agency personnel have the same understanding of the project’s boundaries, the external actors that do and do not interact with the solution being built, and the data flows that exist between the external actors and the solution. This serves as a good starting point for detailed requirements elicitation and analysis.
Creating a Context DFD involves four steps:
- Identifying actors
- Identifying data flows
- Determining the project boundary
- Finalizing the scope diagram
Let’s illustrate these steps with an example Seminar Management System (SMS) that is being proposed:
The organization Acme Seminars has scheduled a new seminar and has advertised it in the SMS, which reaches out to prospective attendees via the web. A new attendee registers for the seminar through the SMS web interface. Part of the registration process is entering credit card information. The SMS sends the credit card information to the credit card company’s Approvals server, and gets a message back that the credit card was approved. The SMS notifies Acme’s Seminar Administrator by email of the new registration. The Seminar Administrator logs in to the SMS to view the application, and confirms the registration in the SMS, which then sends a confirmation email to the attendee. A day before the seminar, the SMS sends the Seminar Instructor a roster of the attendees. The Seminar Instructor takes attendance at the seminar. After the seminar is complete, the Seminar Instructor goes into the SMS and marks each attendee’s record as complete, if they were in attendance. The SMS sends an automatic email to each of those attendees with a certificate of completion. The Seminar Instructor also notifies her manager by email that she has completed teaching the seminar.
Step 1: Identify Actors
Have each project stakeholder identify any actors (human and nonhuman) involved with the project. If the stakeholder is unsure about any actor, capture it anyway; whether the actor makes it to the final version of the Context DFD can be determined later. Aggregate the list of stakeholders. In our SMS Project example, the project stakeholders likely will identify the following as potential actors that interact with the SMS:
- Attendee
- Credit card company’s Approvals server (a non-human actor)
- Seminar Administrator
- Seminar Instructor
- Seminar Instructor’s Manager
Step 2: Identify Data Flows
A data flow is a conduit in which data or information flows. It involves the usage by one or more actors, and is identified both by the data being carried and the (always) one direction in which it flows. Data flow arrows are named with a brief description of the type of information being carried. These brief descriptions should always be a noun or a noun phrase.
Using our example, we draw a rectangle for each of the actors and connect them with unidirectional arrows signifying the data flows. If data flows both ways between any two actors, create two separate arrows. We also consider the SMS itself as an actor.
Step 3: Determine the Project Boundary
Next, we lead the stakeholders in reaching consensus about what actors and data flows get included in the project and which don’t. Certainly, budget and schedule play a big role in this decision, but utility also plays a role. That is, consider whether it’s really useful for an actor or data flow to be part of the project.
Draw a circle around the actors and data flows that stakeholders agree should be part of the project. In our example, we draw a circle around everything except the completion notification to the Seminar Instructor’s manager, which doesn’t have much utility for the solution the stakeholders have in mind.
Step 4: Finalize the Scope Diagram
Consider any actor or data flow that is outside the circle as out of the scope of the project, and can be removed.
What remains inside the circle should be detailed in other requirements documents, but for the Context DFD, should be abstracted to a higher level. Again, the Context DFD is a big picture document that should communicate a project’s scope at a glance. In our example, we abstract the diagram out thusly:
Now the project’s high-level boundaries are clear for all to see. This diagram further serves as a starting point for more detailed requirements documents, including functional decompositions, entity relationships, a use case model, and much more.
If you’d like to learn more about this and other requirements management tools for your organization, please contact us. At Mediacurrent, we've invested in Data and Business Analytics personnel and processes to make digital transformation a reality for our clients. We’re happy to chat with you!