Chapter 2
System and Context Boundaries
Introduction
• The purpose of defining the system and context boundaries in
requirements engineering is to identify the part of the
environment that influences the requirements for the system
to be developed.
2.1 System Context
• The parts of the real-world which will potentially influence the
requirements of the system can be identified.
• To be able to specify the requirements or a system correctly
and completely, it is necessary to identify the relationships
between individual material and immaterial aspects as
precisely as possible.
• The part of reality that is relevant for the
requirements of system is called the system context.
2.1 System Context
• Example: UNITEN Academic Management System
• System context:
• Academic issues cover students intake, subject registration
and all other academic-related issues, including graduation.
• Finance issues such as fees calculation and fees exemption.
• University ranking
• Not a system context:
• Human resource management (employees benefits and
salary)
2.1 System Context
• Definition 2-1: System Context
The system context is the part of the system
environment that is relevant for the definition
as well as the understanding of the
requirements of a system to be developed.
2.1 System Context
• The following possible aspects of reality influence the context of a
system:
People (stakeholders or group of stakeholders)
Example: Will Students Affairs Department will also be involved?
Systems in operations (other technical systems or hardware)
Example: Will there be any scanning of QR code?
Processes (technical or physical processes, business process)
Example: Will students’ accommodation registration procedures involved?
** Examples are based on the system context given before
2.1 System Context
• The following possible aspects of reality influence the context
of a system:
Events (technical or physical)
Example: Convocation/ graduation event
Documents (laws, standards, documentation)
Example: Malaysia Quality Assurance guidelines/ Ministry
of Higher Education rules
** Examples are based on the system context given before
2.1 System Context
• Consequence of erroneous or incomplete context
consideration
Leads to the system operating on the basis of incomplete or
erroneous requirements, which is often the reason for
system failure during operation.
Example: Unable to consider the pre-requisite subjects cause
the student to register the subject that is not supposed to
register. e.g: Taking Programming 2 before Programming 1.
2.1 System Context
• The better the context of a requirement is understood,
the lower the likelihood of incorrect interpretation of the
requirement.
• Therefore, a purpose-driven documentation of the
system context or information about the system context
is of particular importance.
2.2 Defining System and Context Boundaries
• It is within the responsibility of the requirements engineer to define the system
context properly.
• In order to do so, it is necessary to separate the system context from the system
to be developed as well as from the parts of reality that are irrelevant for the
system.
Example:
• System context
• Academic issues cover students intake, subject registration and all other
academic-related issues, including graduation.
• Finance issues such as fees calculation and fees exemption.
• University ranking
• System to be developed:
• All in system context, EXCEPT university ranking
UNITEN
Academic
Management
System
Academic
(Subjects
registration,
Finance, ….)
Human
resource
management
(employees
benefits and
salary)
2.2 Defining System and Context Boundaries
• Defining the system
boundary: When defining
the system boundary,
decision has to be made:
Which aspects pertain to
the system to be developed
and which aspects belong
in the system context?
2.2 Defining System and Context Boundaries
• Defining the context boundary:
When defining the context boundary,
the question to be answered is:
which aspects pertain to the system
context (have a relation to the
system to be developed) and which
aspects are part of the irrelevant
environment?
• Irrelevant environment:
• Human resource management
(employees benefits and salary)
2.2 Defining System and Context Boundaries
• The system context comprises all
aspects that are relevant with regard to
the requirements for the system to be
developed. These aspects cannot be
altered or modified by the system
development process.
• Example: A list of MPU subjects to be
taken by students set by MQA (Malaysia
Quality Assurance) cannot be simply
reduced just because a new system does
not want to cater for the MPU subjects.
2.2.1 Defining the System Boundary
• The system boundary separates the object of concern (i.e system)
from its environment.
• When the system boundary is defined , the scope of the development
as well as the aspects that are not part of the system are determined.
Definition 2.2: System Boundary
The system boundary separates the system to be developed from its
environment; i.e; it separates the part of the reality that can be modified
or altered by the development process from aspects of the environment
that cannot be changed or modified by the development process.
2.2.1 Defining the System Boundary
• Example of part of the reality that can be modified or altered
by the development process:
• Display a graphical timetable instead of list of registered subjects
• Submit a request via system instead of filling up the hardcopy
form.
2.2.1 Defining the System Boundary
• All aspects that are within the system boundary can thus be altered during
system development.
• For instance, an existing XXXX that consists of hardware and software
components and is supposed to be replaced by the new system can be within
system boundary.
• Aspects within the system context can be:
• Business processes (refer to previous slide, submit request)
• Technical processes (refer to previous slide, graphic timetable)
• People and roles
• Organizational structures
• Components of the IT infrastructure
2.2.1 Defining the System Boundary
• The system context consists of other systems, group of stakeholders
that in some way use the interfaces of the system to be developed, and
additional requirements sources and their interrelations.
• System context
• (other system) Academic issues cover students intake, subject registration
and all other academic-related issues, including graduation.
• (other system) Finance issues such as fees calculation and fees exemption.
• (group of stakeholders) Registrar, Finance, Students Affair
• (additional requirements sources) MQA rules, Immigration rules
2.2.1 Defining the System Boundary
sources
• Sources and sinks as the starting point
Sources and sinks can be used to identify the
interfaces the system has with its environment.
Sources provide inputs for the system.
sinks
Sinks receives outputs from the system.
interface
2.2.1 Defining the System Boundary
• Interfaces : Interaction between system and
environment
Sources and sinks interact with the system to be developed
via system interfaces.
Using these interfaces, the system provides its functionality
to the environment, monitors the environment, influences
parameters of the environment, and controls operations of
the environment.
2.2.1 Defining the System Boundary
• Interfaces : Interaction between system and
environment
Depending on the type of the respective source or
sink, the system needs different interface types (e.g:
human-machine interface, hardware interface, or
software interface).
2.2.1 Defining the System Boundary
• Gray zone between system and system context
System boundary is not precisely defined until the end
of the requirements engineering process.
Before that, some or several interfaces as well as
desired functions and qualities of the system to be
developed are only partially known or not known at all.
2.2.1 Defining the System Boundary
• Gray zone between system and system context
Gray zone- initially unclear separation of the system and its
context
At the beginning of the requirements engineering process, it
may not be clear whether the system should implement a
certain function or whether there is another system in the
system context providing such a function that should be used.
Example: Do we have a system to capture SCORUN points?
2.2.1 Defining the System Boundary
• Adjusting the gray zone
Label (1) Figure 2-3: The system boundary shift within
gray zone
Label (2) Figure 2-3: The gray zone shift during
requirements engineering process
2.2.1 Defining the System Boundary
Shifting happens because it is not clear in the system context
whether certain activities of a business process should be
implemented or supported by the system to be developed or not.
Example: Shall the system displays student’s SCORUN points in detail?
Shifting also happens because it is not clear which aspects belong
to the system and can thus be changed or modified. Aspects belong
to the system context cannot be changed or modified.
Example: Shall the system allows for SCORUN points transcript to be
generated together with academic transcript?
The system
boundary
The gray shift within
zone shift gray zone
during
requirements
engineering
process
2.2.2 Defining the Context Boundary
• The context boundary distinguishes between context
aspects (those aspects of the environment that need to be
taken into account during requirements engineering) and
those aspects that are irrelevant for the system.
Definition 2-3: Context Boundary
The context boundary separates the relevant part of the
environment of a system to be developed from irrelevant
part.
2.2.2 Defining the Context Boundary
• Concretion and shift of the context boundary
Label (1) Figure 2-4: System context is reduced.
A law directive that was considered to be relevant for the system to be
developed no longer impacts the system or is no longer considered
relevant.
Label (2) Figure 2-4: System context is extended.
A new law directive is identified that influences the system.
Example: Malaysia Board Of Technologists (MBOT) sets for maximum
transfer credits for Cyber Security program to be not more than 36 credits.
System context is
reduced.
System
context is
extended.
2.2.1 Defining the Context Boundary
• Gray zone between system context and irrelevant
environment
Gray zone comprises identified aspects of the environment for which
it is unclear whether they have a relation to the system or not.
Gray zone between system context and the irrelevant environment-
not necessary to resolve the gray zone entirely
Gray zone between system and the system context- must be
resolved during the requirements engineering process
2.3 Documenting the System Context
• To document system and context boundary
• 1. Structured approach
Context diagram
• Object Oriented Approach
Use case diagram
Class diagram
Use Case Data Flow
Diagram Diagram
Summary
• When the system boundaries are defined, the scope
of the system is determined.
• The scope comprises those aspects that can be
changed and designed during system development.
Summary
Resolved
during RE
Context
boundary- No
need to
specify
precisely at
the end of RE
References
oRequirements Engineering Fundamentals: A Study Guide for
the Certified Professional for Requirements Engineering Exam -
Foundation Level - IREB compliant
oImages from:
[Link]
orial/
[Link]
[Link]
