Please enable JavaScript.
Coggle requires JavaScript to display documents.
CHAPTER 2: FRAMEWORK & CONTEXT - Coggle Diagram
CHAPTER 2:
FRAMEWORK & CONTEXT
MOTIVATION, VISION, OVERVIEW
ESTABLISHING A VISION IN CONTEXT
The context strongly
influences the definition and refinement
of requirements
Adequate consideration of the context is thus
essential
for requirements engineering and system development
The context contains, among others, the sources for the
requirements
The context is often
not fully known and understood
Each system is embedded in aspecific
context
FRAMEWORK FOR RE
:
CONTEXT
CONTEXT OBJECTS
Context object are
material or immaterial objects
belonging to the context
EXAMPLE
MATERIAL OBJECT(can be touched)
Hardware
Documents
People
IMMATERIAL OBJECT(Cannot be touched)
Business processes
Software components
Organizations
CONTEXT OF A SOFTWARE-INTENSIVE SYSTEM
A (software-intensive) system is always embedded in a particular context
A requirement is
always defined for a particular context
The
context
heavily
influences the requirements
the system has to fulfill
SYSTEM CONTEXT
is the part of the context in which the system to be developed is
operating/embedded
Material or immaterial objects belonging to the system context are called
system context objects
EXAMPLE
MATERIAL OBJECTS(can be touched)
Books
Book shelf
Work Station
IMMATERIAL OBJECT(cannot be touched)
User authorization service
Meta-search engine accessing several library systems
Library database
SYSTEM CONTEXT BOUNDARY
Defines which material and immaterial objects belong to the system context. It thereby separates system context objects from context objects
INVOLVEMENT IN RE ACTIVITIES
Each context object can potentially be involved in any requirements engineering activities:
Elicitation, documentation and negotiation
Validation and management
THREE FACETS OF SYSTEM OBJECTS
IT SYSTEM FACET
Comprises all system facet objects of the technical and operational environment in which the system is going to be deployment in / which influence or constraint the deployment of the system and/or the user of technology by the system such as sensors, actuators or other systems
Includes system context objects which contribute to the definition of the operational environment and/or the technology used or which influence or constraint relevant quality attributes (such as average availability time, security)
EXAMPLE:
Communication networks
Peripheral devices
Hard/software platforms
DEVELOPMENT OF A UNIVERSITY LIBRARY SYSTEM
Server
Library workstations
Printer
SUBJECT FACET
Comprises system context objects about which
information is represented in the system
/ which influence/ constrain the representation of information represented in the system
Includes system context
objects and events, properties and relationship
about which information is represented in the system and the
quality of the representation
such as accuracy and actuality
EXAMPLE:
Reference models of the subject domain
Textbooks and laws
Lawyers and data privacy officers
People about which data is stored (eg; customers, suppliers)
Consumer goods
DEVELOPMENT OF A UNIVERSITY LIBRARY SYSTEM
Student
Bookshelf
Book
Magazine
E-book
USAGE FACET
Comprises
all system context objects (people and/or systems)
which directly or indirectly
interact with the system
or which
influence or benefit from the usage
of the system
Includes system context objects contributing to the definition of the desired usage and the usage quality attributes such as expected usage load or average response times
EXAMPLE
Workflows or business processes
User groups
Usage goals and tasks
DEVELOPMENT OF A UNIVERSITY LIBRARY SYSTEM
Meta-search engine accessing several library systems
Check-out process and return process for library items
Student user group
REQUIREMENT & CONTEXT INFORMATION
A requirement is
always defined for a particular
context
A change in the context typically requires adaptation of requirements
Documenting context information (context object, their properties and relationship) is a prerequisite for supportting the analysis of the impact of a context change on requirements
DEVELOPMENT CONTEXT
Is the part of the context in which the system is being developed
Material or immaterial objects belonging to the development context are
called development context objects
DEVELOPMENT CONTEXT BOUNDARY
defines which material and immaterial objects belong to the development context. It thereby separates development context objects from context objects.
REQUIREMENTS ENGINEERING CONTEXT
defines which material and immaterial objects belong to the requirements engineering context.
BENEFIT FOR STRUCTURING RE CONTEXT
Fosters the identification of important requirement sources from all relevant RE context facets
Supports to identify representatives from relevant RE context facet for validation
The structure facilitates to focus on one important context aspect at a time
DIFFERENT ROLES OF CONTEXT OBJECTS
A RE context object can be involved in more than one RE activity
ACTIVE
Being interviewed
Validating
Documenting
PASSIVE
A standard which predefined some requirements
A document which is analysed
