Sistēmas robežas un dekompozīcija

of system environment, relevant for defining, understanding, and implementing the systems requirements
K. Pohl. Requirements Engineering: Fundamentals, Principles and Techniques, 2010

Planned System

System Context

Irrelevant environment (the one outside the systems context)

prerequisite for definition of correct systems requirements.

Source of the requirements

Justification of the requirements

stakeholders)
Systems in operation (technical systems, software, hardware)
Processes (technical or physical processes, business processes)
Events (technical or physical)
Documents (e.g., laws, standards, system documentation)

You may consider also:
Non technical systems such as administrative systems
Physical laws

covered by the planned system and which aspects are part of this system’s environment

Context boundary identifies the part of the environment that has a connection to the system to be developed

the system will clarify the availability issues of the information
Indirectly
The personal data protection law will clarify which personal data can be exposed, which cannot.

information
Which context aspect should be documents
What should be the documentation format
Relationship types to interrelate context information to requirements
Responsibilities for context documentation
Systematically consider changes in the context and adjust requirements accordingly

e.g.:
Requirements sources
Context objects
Properties and relationships between context objects
In Pohl’s book the following facets are suggested for structuring the context information
Subject facet
Usage facet
IT system facet
Development facet

covered by the planned system and which aspects are part of this system’s environment

Context boundary identifies the part of the environment that has a connection to the system to be developed

Techniques, Springer 2010

Sustem Boundary

The systems bundary separates the system to be developed from the system context. The system boundary separates the parts that belong to the system and can hence be changed during the development process from the parts of the system that cannot be changed during the development process

Context boundary

The context bundary separates the relevant part of systems environment from the irrelevant part. … it separates the the system context from the irrelevant environment which contains all those aspects that do not need to be considered during systems development

only towards the end of the requirements process
Interfaces of the system lay on this boundary
before the final decisions not all desired functions and qualities of the planned system are known
Grey zone shows where possibly the systems boundary (and what interfaces) can be
The grey zone itself can change during the requirements process

Planned System

System Context

Irrelevant environment (the one outside the systems context)

changing legal regulations)
Thus context boundary has grey zone, which shows where context boundary coud be
Context boundary grey zone comprises the identified aspects of the environment for which, at a particular time, it is unclear, whether these aspects have a relation to the planned system or not
The context boundary grey zone can change during the requirements process

Planned System

System Context

Irrelevant environment (the one outside the systems context)

Techniques, Springer, 2010 concerning system boundary

Determine explicitly which aspects belong to the system
Determine which aspects are outside the system boundary
When defining systems boundary involve all relevant stakeholders
Try to reach agreement about the systems boundary. If cannot decide – put the item in the grey zone
Check periodically, whether the system boundary is still valid. Pay attention to needed extensions or reductions of the boundary. If the systems boundary need to be adjusted, verify whether the adjustment impacts already defined requirements.

affected by an organisation, strategy or project
http://www.stakeholdermap.com/stakeholder-definition.html

Techniques, Springer, 2010 concerning system context boundary

Use appropriate structuring scheme to separate step by step systems context from irrelevant environment
If unsure of relevance – put the item into grey zone
If an aspect (object) is considered as irrelevant – document it as irrelevant one – to have an opportunity to re-check it later
If new (e.g. functional) requirements are discovered, check whether formerly irrelevant aspects are still irrelevant (if the aspect is relevant – it shall affect at least one goal or scenario)
Iterate these steps as the system and context boundaries influence the definition of goals and scenarios.

and thinks in the system environment
Data flows from the sinks to the sources
Usually – the systems context is shown by context level DFDs

Use Case Diagrams (UCD)

Actors (e.g. people and other systems) in the system environment
Actor use relations
Usually the systems context is shown by systems Use Case Diagrams while business Use case Diagrams also can be used

Standard,
available at
https://www.ireb.org/content/downloads/14-handbook-cpre-advanced-level-requirements-modeling/ireb_cpre_handbook_requirements-modeling_advanced-level-v1.3.pdf

var veikt dekompozīciju?