High-Level Business Processes

The context-level data flow diagram is an outstanding technique and provides numerous benefits to the team. It does miss one important component that should be added: high-level business processes. A process is an activity performed by a business that transforms information (data). (A more detailed discussion of processes is included in Chapter 4.) Processes may be named and described at various levels of detail. During scoping, high-level processes should be named and listed with the context-level data flow diagram. Only identify the top five to seven processes that are included in the area of study, and name each in such a way that it completely describes the work done in this area of the business.

Scoping the Analysis Area Using a Use Case Diagram

Another scoping technique is the use case diagram. Again, this diagram was invented to support software development, but a BA can use it at the business level. This technique is similar to context-level data flow diagramming in that it defines a business area and outside parties (called actors instead of external agents). When using this technique for scoping, a few high-level use cases are identified. Putting too much complexity into the scope diagram defeats the purpose of having quick agreement on the area of study (see Chapter 6 for more on use case diagramming). Figure 3.5 shows an example of a use case diagram used to scope an analysis project.

Figure 3.5: Use Case Diagram

The scope of the analysis area must be documented in some form, even if just on a flip chart. This is necessary because during analysis and requirements elicitation, the BA, PM, and business stakeholders will often start discussing requirements that are outside the project scope. Business people will talk about their work that is both inside and outside of scope because they don’t think of their work in the context of any one particular project. The BA uses the scope diagram to remind himself or herself and the SME to stay on topic. This will keep everyone on the team focused on the agreed-upon scope. The documented scope should be formally reviewed and approved before the BA begins detailed requirements work. This is a very useful deliverable for business analysis planning (see Chapter 7).

Project Initiation Summary Revisit Scope Frequently

Hang your scope diagram (context-level data flow diagram or use case diagram) on a wall in your office. Carry of a copy of it in your project notebook when you go to interviews and meetings with stakeholders. Periodically ask yourself and everyone on the team: “Are we getting outside of the scope of this project?” Keeping the project on track and within scope is something that PMs are very good at. BAs also need to learn this discipline. It is more difficult for analysts because they are naturally curious and want to make sure that every single requirement has been captured, but eliciting, analyzing, and documenting requirements that are outside of the true project scope are a waste of time. Don’t get bogged down. If this is one of your weaknesses, force yourself to step away from project details at least once each day to ask yourself: “Am I spending time on the right things?”