Scope models describes the essence of one or more boundaries and place components inside or outside those boundaries.
Scope models are usually used to define the boundaries of control, change, a solution, or a need.
These models may show components that include:
• In-scope: this is when the model recognizes a boundary as seen from inside for example, functional decomposition.
• Out-of-scope: the model recognizes a boundary as seen from outside for example a context diagram.
• Both: the model recognizes a boundary as seen from both sides for example a venn diagram or a use case model.
Scope models provide the foundation for understanding the boundaries of:
• Scope of Control: this is what is being examined, the roles and responsibilities, and what is internal and external to the organization.
• Scope of Need: these are the stakeholder needs, value to be delivered, functional areas and organizational units to be investigated.
• Scope of Solution: these are the requirements that are being met, value being delivered, and the effect of change.
• Scope of Change: these are the actions to be taken, stakeholders involved,
and events to cause or prevent.
Scope models are usually represented as a blend of diagrams, matrices, and textual descriptions. If the scope is implemented in phases, the scope model should be described for each iteration.
Scope modelling has some components, which include:
1 Objectives : scope models are usually used to shed light on the following:
- Range of control.
- Importance of the elements.
- Where the effort will be applied.
The business analyst decides on the types of models to be used and selects boundaries and components based on the stakeholders needs.
2 Scope of change and context: Usually, the business analysts are worried that the elements will be changed as part of a change, as well as external elements that are important to the change.
For elements inside the scope of change, the business analyst is involved in discovering the ways those components are changed.
For components outside the scope of change but important to the change, the business analyst is involved in discovering the relationship between the change, the current and proposed solutions, and the context.
The business analyst usually determines the following:
- business processes to be defined or altered.
- business functions to be added, changed, enhanced, or re-assigned.
- new capabilities to be built or existing capabilities to be changed.
- external and internal events to be answered.
- use cases and situations to be facilitated.
- technologies to be altered or replaced.
- informational assets to be obtained, produced, or processed.
- stakeholders and organizational roles affected by the change.
- external and internal agents and entities affected by the change.
- organizations and organizational units (departments, teams, groups) affected by the change.
- systems, elementes, tools, and physical assets needed or affected by the change.
3 Level of Detail : The reason for analysis describes the suitable level of abstraction which the scope components are described.
The components of the final scope model can be described by listing
them, by defining to a specific level of their decomposition hierarchy, or by
collecting them into logically bound sets.
For example, a subject of change can be described as a list of specific business processes, as a high-level business process that encloses all of them, or as a generic business function.
Similarly, stakeholders included in the scope can be described by listing specific titles or by mentioning their common organizational role.
4 Relationships : discovering relationships between possible scope components helps to ensure the integrity of the scope model by finding other components impacted by the change.
Numerous diagramming techniques are also available for exploring relationships of specific types, including:
• Parent-Child or Composition-Subset: this connects elements of the same type through hierarchical decomposition. Relationships of this type appear in organization charts, class or entity-relationship diagram, subprocesses in a business process model and composite states on a state diagram.
• Function-Responsibility: this connects a function with the solution component that is responsible for its implementation. Relationships of this type appear on business process models and on collaboration, sequence, and use case diagrams.
• Supplier-Consumer: this connects components through the transmission of information between them. Components can be processes, systems, solution element and organizational units, for both internal and external entities.
Relationships of this type appear in data flow diagrams, business process models, and in collaboration, sequence, and robustness diagrams.
• Cause-Effect: this connects components by logical occurence in order to identify chains of connected elements that are impacted by the change. Relationships of this type appear in fishbone/Ishikawa diagrams and other cause-effect diagrams.
• Emergent: in most complex systems, several components can be related to
produce results that cannot be understood based on the components alone.
5 Assumptions: At a time of scope modelling, the logic of the model heavily depends heavily on presumptions such as the description of needs, connection of outcomes, effect of changes, applicability, and practicality of the solution.
The ensuing scope model should include explicit statements of pertinent assumptions and their implications.
6 Scope modelling results: the results of scope modelling can be displayed as:
• textual descriptions of components, including the basis for making in-scope or out-of-scope decisions.
• diagrams showing relationships of scope components.
• matrices representing dependencies between scope elements.
Scope modelling has its strengths and limitations, which include:
Strengths
A scope model facilitates agreement as a premise for:
- describing contractual commitments.
- approximating the project effort.
- rationalize in-scope/out-of-scope decisions in requirements analysis.
- estimating the validity and effect of solutions.
Limitations
• An open, high-level model can lack the right level of granularity, that is required to ensure clear scope identification.
• Once a scope is defined, changing it may be difficult due to political reasons and contractual commitments.
• Standard scope models cannot address common complex boundaries, such as a boundary that is completely dependent on the stakeholder position.