QN1: What criteria can be used to draw boundaries between Projects?
The boundaries of a project are measurable and auditable characteristics that define what belongs to the project and what doesn’t belong to it. Project boundaries are closely linked to project objectives, they create a holistic perception of project work, and they define the content of the project in terms of expected results. A clear boundary statement helps direct the things that are applicable to those areas within the project scope. The followings are the criteria used to draw boundaries between projects.
CONTEXT DIAGRAM
The context diagram depicts the project scope at a high level of abstraction. This diagram deliberately reveals nothing about the system internals; no information about functionality, architecture, or look-and-feel. Nor does it explicitly identify which features or functionality are in scope and which are not. The functional behavior of the system is merely implied by the labeled flows that connect the system to the external entities. Even the flows are labeled at a high level of abstraction, just to keep the diagram’s complexity manageable. The business analyst can decompose these data flows into individual data elements in the project’s data dictionary or data model. Corresponding data inputs and outputs imply the types of operations the system will perform, but these aren’t shown explicitly in the context diagram.
USE CASE DIAGRAM
Use cases are a powerful technique for exploring user requirements. The Unified Modeling Language (UML) includes a use case diagram notation. Figure 2 shows a partial use case diagram for our cafeteria ordering system. The rectangular box represents the system boundary, analogous to the circle in a context diagram. The stick figures outside the box represent actors, entities that reside outside the system’s context but interact with the system in some way. The actors correspond approximately (exactly, in this example) to the external entities shown in rectangles on the context diagram.
