You have a SharedClearVision(95) for a system.
The scope of a system will grow in an uncontrollable manner if you do not know its boundaries.
The late 1950s was probably the golden era of the so called “B” films, and one of the films that is near and dear to all B film connoisseurs is the 1958 science fiction film, “The Blob”. In this movie that launched Steve McQueen in his Hollywood acting career, a group of teenagers discover an alien creature from outer space that has no form or shape, and grows
teenagers attempt to warn a doomed town of the danger it faces, but no one believes a bunch of kids until its too late.
Few other films have been used as extensively as a metaphor for the dangers of uncontrolled or unmanaged growth. “The Blob” has been used to describe everything from civic problems such as urban sprawl, to poor software architecture [Bro1998].
Different people have different points of view regarding where a system’s boundary is. Some stakeholders such as business owners are often more interested in how the business runs, than in the software. Developers are often more interested in the software than in the business. For the stakeholders the system is the business and the environment is the world in which the business operates, with customers, suppliers and competitors on the outside of the system. Resources such as the sales staff and customer service clerks are inside or part of the business. On the other hand, the developers may regard the sales staff and customer clerks as users and therefore outside of the system.
Poorly defined boundaries lead to scope creep. Many of the stakeholders have “pet problems” they want solve and hope that a new system will resolve for them. Sales and marketing staff often load features onto a system in the hopes of capturing customer interest.
Developers love to enhance or add features to even well-defined systems. Poorly defined or undefined boundaries exacerbate these problems. Without a clear definition of where the system boundary is to guide them, then everyone will try to add feature they deem even slightly necessary. But these extra features often go beyond the useful mandate of the system usually don’t add any value to the system. If anything, they make the system more complicated and less useful.
Imprecise and conflicting objectives early in the project often make it difficult to determine the boundary of a system. Early in the project there may be insufficient information to identify what belongs to the system and what is part of its environment because the system is large, or its purpose is not clearly defined.
People have the perception that defining a boundary is unnecessary. Programmers often feel that analysis activities only get in the way of the real work (coding), and don’t provide them with any real value. This perception is especially true in the startup world, where companies live on a shoestring budget, and their very livelihood is heavily dependent on the time it takes them to get their product to market. But this approach can quickly result in unnecessary and missing features, inadequate products, and excessive costs.
Establish a visible boundary between the system and its environment by enumerating who and what interacts with the system
The VisibleBoundary(101) limits and supports the SharedClearVision(95) by:
1. specifying what external systems and personnel the system must collaborate with, and by
2. specifying what resources the system has available to it to accomplish its purpose.
In the early stages of development, the visible boundary may be fuzzy because the vision for the system may not be clear. Start by putting a stake in the ground and document the system boundary based on the information you have available to you. As you develop your use cases and learn more about the system, you can refine and sharpen the system boundary i.e.
SpiralDevelopment(66).
Examples
Wings Over the World
A context diagram is a useful tool for documenting the visible boundary between a system and its environment. It is a simple diagram consisting of a circle and boxes on a sheet of paper, with lines and arrows extending between the circle and boxes. But that simple diagram contains a lot of information. The circle represents the system. The boxes, or terminators as they are called, represent anything that is outside of the system. The lines running between the boxes and system represent the flow of data between the system and its terminators. In short, it shows what the system interacts with within the environment.
Both the context diagram and its UML equivalent the deployment diagram are simple, effective tools for identifying potential actors and use cases, because they help us focus on the things that interact with a system while ignoring the services that those things require.
In addition to simplicity, the benefit of using these kinds of diagrams is that they are based on information that is readily available early in the development cycle. With use cases, you must find actors and the services they need. On the other hand, with context or deployment diagrams, you only need to find the physical things that the system will talk to. You do not need to know what services they will require or deliver to the system.