Scope models are usually used to define the limitations 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.

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 modelling has some components, which include:

1 Objectives : scope models are usually used to shed light on the following:
1. Range of control.
2. Importance of the elements.
3. 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:
1. business processes to be defined or altered.
2. business functions to be added, changed, enhanced, or re-assigned.
3. new capabilities to be built or existing capabilities to be changed.
4. external and internal events to be answered.
5. use cases and situations to be facilitated.
6. technologies to be altered or replaced.
7. informational assets to be obtained, produced, or processed.
8. stakeholders and organizational roles affected by the change.
9. external and internal agents and entities affected by the change.
 10. organizations and organizational units (departments, teams, groups) affected by the
change.
11. 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 (Organization Chart ): 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.

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:
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.