Software

Requirement
Engineering
Requirements modelling in data perspective
Model-based Requirements Documentation

During model-based documentation of requirements in requirements engineering, three

types of requirements are documented independently and used in conjunction:
• Goals describe intentions of stakeholders or groups of stakeholders.

• Use cases and scenarios document exemplary sequences of system usage. Scenarios
are grouped together in use cases.
• System requirements (generally referred to as requirements) describe detailed
functions and qualities that the system to be developed shall implement or possess.

2
 3

A model is an abstract representation of an existing

reality or a reality to be created

The Term Model

 Properties of Models
• Model has three important properties (advantages)
1. Mapping the reality – models can map certain aspects of the observed reality onto it modeling elements.

Models Division

Descriptive models Prescriptive models

Resulting model documents the Model serves as a prototype for

existing reality. a fictitious reality.

A model from Prospective point of view can be both descriptive as well as prescriptive

Descriptive with regard to the conception of the stakeholder who is constructing it

prescriptive with regard to the system to be developed
 Properties of Models

2. Reduction of reality
Models reduce the mapped reality. It is common to differentiate
between selection and compression.
During selection, only particular aspects that are part of the
universe of the system are modelled.
In contrast, aspects of the subject-matter of the system are
summarized during compression
 Properties of Models

3. Pragmatic Property (reality)

• A model is always constructed for a special purpose and within
a special context.
• The purpose of the model may affect the construction
• Ideally, a model contains only the information necessary for
the respective purpose
 Modeling Languages
• In order to construct conceptual models, specific modeling languages
are used.
• A modeling language is defined by its syntax and semantics:
• Syntax: The syntax of a modeling language defines the modeling
elements to be used and specifies the valid combinations thereof.
• Semantics: The semantics defines the meaning of the individual
modeling elements and serves therefore as a foundation for the
interpretation of the models of the respective modeling language.

7
 Requirements Models
• Conceptual models that document the requirements of a
system are called requirements models.
• The Unified Modeling Language (UML) is frequently used to
construct requirements models.

8
 Requirements models vs. design models

• So what is a difference between conventional and requirement models??

– Conventional models (DFD, ERD, automata etc.) are chosen during system development
– Where as requirement models are more elaborated and depict aspects of the underlying
problem.
 Advantages of Requirement Models
1. Increased understanding.
2. Support perspectives of documentation
 Goal Models.
• Goals are used to refine the vision of the system.
• Refining a goals, means goal decomposition.
• Goals can be documented using
– Natural language or
– Goal model.
• A common goal modeling technique is AND/OR trees
– which help in hierarchical decompositions.
• The direction of the goal decomposition is not represented
through branches but through the top-down structure of the
tree.
 Goal Documentation Using AND/OR Trees
• Using AND/OR trees, two types of decomposition relationships

• In case of AND-decomposition, every sub-goal must be fulfilled so that the super

goal( the root) is fulfilled.
• in OR-decomposition, it is sufficient if at least one sub-goal is fulfilled so that the
super-goal is met.
 Example*

• Decomposition of the goal “Comfortable navigation to

destination”
 Three Perspectives on the Requirements

• Data Perspective
• Functional Perspective
• Behavioral Perspective

15
Three Perspectives on the Requirements (Cont.)

Data Perspective
• In this perspective, the structures of input and output data
as well as static-structural aspects of the usage and
dependency relationships of the system in the system
context are documented.

16
Three Perspectives on the Requirements (Cont.)

Functional Perspective
• This perspective documents which information of the
system context is being manipulated by the system to be
developed and which data is being transmitted to the
system context by the system.

17
Three Perspectives on the Requirements (Cont.)

Behavioral Perspective
• Documenting the reaction of the system to events within the system
context
• Documenting the conditions that trigger a state change, or
• Documenting the effects that the system has on its environment.

18
Requirements Modeling in Data Perspective

• Several different modeling languages are well suited to modeling

structural aspects of requirements in the data perspective.
– entity-relationship models,
– extensions of the traditional entity-relationship model
– class diagrams of the UML
– Use case diagrams

19
 Entity-Relationships Diagrams

• Traditional ERD display the structure of an object of a universe of discourse

by means of entity types and relation types.
• A number of extensions for the entity-relationship model have been
suggested. These extensions mainly concern the generalization/specialization
relations, inheritance mechanisms, and roles of entities and extend the model
by a (min, max)-notation for cardinalities of relations.

20
Modeling Elements of Entity-Relationship Diagram

21
Modeling Elements of Entity-Relationship Diagram (Cont.)

Entity types
• Abstraction from concrete objects
• define a set of entities within the universe of discourse (that is, objects
with the same properties, such as people or items).
• For instance, the entity type “pilot” classifies all people within the
universe of discourse that have the characteristic of holding a piloting
license.

22
Modeling Elements of Entity-Relationship Diagram (Cont.)

Relation Type
• A relation type abstracts from a concrete characteristic of a relationship
and of entities that are in relation to one another.
• A relation type classifies the set of uniform relations between entity types
within the universe of discourse.

23
Modeling Elements of Entity-Relationship Diagram (Cont.)

Relation Type
• For example, the relation type “executes” can be defined between the two
entity types “pilot” and “flight” to represent concrete “executes”-relations
between concrete pilots and concrete flights.

• If a concrete “is_passenger” relation is defined between a concrete passenger

“John Locke”4 and a concrete flight with the flight number “OA 815” , then this
relation depicts that “John Locke” is a passenger of the flight with the flight
number “OA 815”. 24
Modeling Elements of Entity-Relationship Diagram (Cont.)

Properties of entity types and relationship types

• An attribute defines the properties of an entity type or a relation type.

• Possible attributes for the entity type “passenger” could be “family name”,
“given name”, “passport number”, and “reserved seat”.

25
Modeling Elements of Entity-Relationship Diagram (Cont.)

Cardinality
• The cardinality of a (binary) relation defines the number of relation instances that
an entity may participate in.

• If no cardinalities are annotated for a specific relation type, it is assumed that an

arbitrary number of entities (in other words, at least zero entities) may participate
in such a relation.

• Using cardinalities for relations therefore limits the number of instances that are
principally possible in an entity-relationship diagram. 26
Example of an Entity-Relation Diagram

27