This post focuses on how to define application scope as it is a critical part of any  application development process as it sets the scene for all further activities. A badly scoped application can result in much rework and expense later on in the project.

The scope of the application needs to be as clear as posisble and I have found that an excellent technique for defining the scope is the Context Diagram. An example context diagram for the mySwimLog application is shown below:

My first introduction to context diagrams was in 1987 when I learned about Structured Systems Analysis and Design from the books of Tom Demarco and Ed Yourden. Since then I have not found a better technique for determining and representing the scope of a system or application. It also amazes me that the Context Diagram is not a standard diagram in most modern software development processes. Anyway, enough philosophy lets look at the components of a typical Context Diagram.

At the center of the diagram we have the application we are interested in. in this case we use a rounded rectangle to represent it, but any shape is fine The other applications or users of the applications are represented by rectangles.The interactions between the users/applications/systems and our central application are represented by arrows.

The context diagram can be produced in a meeting, workshop and is usually refined over the course of a few meetings. The key is to identify all other systems that the application interacts with and the interfaces between them.

One other useful technique that can be used when developing the context diagram is CAI. This stands for Consider All Interactions. I got this idea from the work of Edward De Bono who has developed many thinking practical techniques. The idea here is to make sure to consider all interactions between the application and its users and any other systems. So the question to ask yourself when developing the context diagram for your application is: “Have I considered all interactions my application has?”

In our case we are interested in a context diagram of our application or system. In older days the approach was to discuss logical components of a system - so for example you would not call a screen a screen or a report a report. The basis for this was the idea that you first focus on the what and then you can look at options for the how later. However in practice for most projects and in my experience this just wastes time. If a screen is what is required then call it a screen, there is no point in calling it a user interface componet or even worse a “data flow to the users!” -  and yes someone did mention this in a workshop once. I think it was a joke, but you never know