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.