System Requirements – the Context and Boundary of the System

The main tasks of requirements engineering is acquisition and documentation of system requirements. To do this, identify those parts of the real world that will affect system requirements.

The part of the reality that affects the definition of system requirements is called the system context.

Incorrect or incomplete definition of the system context during requirements engineering leads to incomplete or incorrectly defined requirements.

Definition: System context

The system context is a part of the system environment that is important for defining and understanding the requirements for the system being created.

Selected aspects of reality that can influence the definition of the system context are, for example:

  • People (stakeholders and stakeholder groups)
  • Cooperating systems (other software or hardware)
  • Processes (technological or business processes)
  • Events (technical or physical)
  • Documents (legal standards, standards, system documentation)

The correct definition of the system context requires separating the system context from the system itself and the part of reality that is irrelevant to the system being created. Defining the boundaries of the system consists in deciding which aspects will be implemented in the system and which belong only to its context.

Defining the boundaries of the system’s context consists in deciding which aspects relate to the context of the system being created (they have an impact on the software being created), and which are part of an environment that is irrelevant to the software being created.

Definition: System boundary

The system boundary separates the created system from its environment, for example it separates a part of reality that can be modified during the manufacturing process from environmental aspects that cannot be changed in this process. Typically, the system boundary is not clearly defined until the requirements engineering process is completed. Due to the fact that at the beginning of the requirements engineering process, the functions of the created system are not fully defined, this limit may change over time.

For example, at the beginning of the requirements engineering process, it may not be determined whether a given functionality will be implemented in the system, or for example it will use other external software. When defining the system boundary, consider what interfaces the created system will communicate with its environment.

Consider who (what) will provide information to the system and who (what) will receive information from the system.

Potential suppliers and recipients of information to / from the system will be:

  • Stakeholders (or groups of stakeholders)
  • Existing systems

Through interfaces, the system will provide functionality to its environment, monitor the environment in which it operates, affect the parameters of this environment and control operations performed in this environment.

Definition: The system context boundary

The system context boundary separates important parts of the system’s environment from non-essential parts, e.g. parts that will not affect the system being created, and therefore do not have to be taken into account during the requirements engineering process.

Typically, the system context boundary (like the system boundary) is not explicitly defined at the beginning of the requirements engineering process and changes during this process.

When documenting the system context (in particular, the boundaries of the system and its environment), you can use:

  • Use case diagrams
  • Data flow diagrams
  • Class diagrams

After defining the context and boundaries of the system, it is time to discuss how to obtain the requirements. I will describe this in the next text.

More from my site

  • Categorization of Requirements According to the Kano Model Defining the requirements that will increase the satisfaction of stakeholders from the system being created is crucial for the process of acquiring requirements. Implementation of too many […]
  • Requirements Management – Best Practices Ian Sommerville and Pete Sawyer in "Requirements Engineering: A Good Practice Guide" described, over 15 years ago, the method of assessing and improving requirements engineering […]
  • Requirements Documentation Requirements specification is a systematic representation of a set of requirements for a system or component that meets specific criteria. Requirements are like contract. All […]
  • Business Requirements vs System Requirements There is a lot of talk about the need to identify project goals, organization goals and the need to identify business and system requirements. All in order to better understand the […]
  • Requirements Documentation Based on Use Cases Use cases are used to document the functionality of the system and are based on two commonly used concepts: Use case diagramsSpecifications of use cases Objects Use case: The use […]

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top