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

  • Kanban Reports Process management is a midway to success. The second midway is process monitoring and drawing conclusions. In Kanban, there are indicators, which enable process monitoring. They […]
  • Kanban Board In the earlier entry on kanban.  I wrote about its assumptions. Today, I would like to describe a fundamental element of kanban: a board. This board presents: Who works on what […]
  • Requirement Prioritization Techniques Today, it is time to describe the requirement prioritization techniques. We can transmit them using a number of techniques. Those are as follows: Ranking This technique consists in […]
  • Reviews of Models in Enterprise Architect Software development is a process in which the reviews of the status of work are a daily or almost everyday situation. Verification of analytical and design works as well as architectural […]
  • User Stories vs. Use Cases We are currently in a “strange situation”. There are user stores and usage case scenarios, of which the latter can be divided into formal and informal use cases as well as summaries of […]

Leave a Comment

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

Scroll to Top