Module 6

MODEL-BASED REQUIREMENTS
DOCUMENTATION
6.0 Introduction
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. Goals can potentially conflict
with one another.

• 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. In addition, system requirements provide
complete and precise information to serve as input for subsequent development steps.
6.0 Introduction
Requirement models are used in addition to natural language
requirements documentation and partly replace requirements that
would have been documented using natural language.
6.1 The Term Model

A model is an abstract representation of an existing

reality or a reality to be created.
6.1.1 Properties of Models
Every model possesses three important properties that are also the prevalent
advantages of models:
•Mapping of reality

•Reduction of reality
◦ Only particular aspects that are part of the universe of discourse of the system are
modeled.

•Pragmatic property
◦ A model contains only the information necessary for the respective purpose.
6.1.2 Modeling Languages
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.
6.1.2 Modeling Languages
• The Unified Modeling Language (UML) is frequently used to
construct requirements models.
• It consists of a set of partially complementary modeling
languages that are particularly used in requirements
engineering to model the requirements of a system from
different perspectives.
6.1.2 Modeling Languages
• A considerable difference between the conventional use of
conceptual models in system development and model usage
for requirements documentation is that conventional models
document solutions chosen during development.
• Requirements models, on the other hand, depict specific
aspects of the underlying problem.
6.1.4 Advantages of Requirements Models
• Research on human cognition has shown that information
can be perceived and memorized faster and better when
depicted graphically as opposed to making use of natural
language.
• Modeling language defines focus and support perspectives of
documentation.
6.1.5 Combined Use of Models and Natural
Language
• Using both natural language and requirements models in
combination allows the advantages of both documentation
techniques to be exploited while minimizing their disadvantages.
• For example, natural language requirements can be summarized
and their interrelations depicted using models. On the other
hand, natural language can help enrich requirements models
and modeling elements with additional information.
6.2 Goal Models
• Goals are a stakeholder's (e.g., a person's or an organization's) description of a
characteristic property of the system to be developed or the development
project.
• Goals are very well suited to refine the vision of the system.
• Refining a goal is known as goal decomposition.
• Goals can be documented using natural language or using goal models.
6.2 Goal Models
• A widely known and very common goal modeling technique is the use of
AND/OR trees.
• By means of AND/OR trees, hierarchical decompositions can be documented.
• The type of refinement relation is depicted by graphic representations of the
branches.
• The direction of the goal decomposition is not represented through branches
but through the top-down structure of the tree.
6.2.1 Goal Documentation Using AND/OR
Trees
• In case of AND-decomposition, every sub-goal must be fulfilled so
that the super-goal (the root) is fulfilled.
• In contrast, in OR-decomposition, it suffices if at least one sub-goal
is fulfilled so that the super-goal is met.
Modeling of goal decomposition using AND/OR trees
6.2.2 Example of AND/OR Trees
• The figure shows an AND/OR tree that documents the hierarchical &
composition of the goal "Comfortable navigation to destination".
 6.2.2 Example of AND/OR Trees

• As the goal model in the previous figure shows, the goal "comfortable navigation to
destination" is refined into the three sub-goals "dynamic route calculation with respect to traffic
congestion", "comfortable destination input", and comfortable route guidance" via AND-
decomposition.
• This depicts that all three sub-goals must be met to consider the super-goal fulfilled.
• The sub-goal "dynamic route calculation with respect to traffic congestion" in turn is refined by
the two sub-goals "manual input of traffic conditions" and "automatic update of traffic data".
• The type of decomposition relation depicts that only one of the two sub-goals must be met to
consider the super-goal met.
6.3 Use Cases
Use cases were first proposed as a method to document the
functionalities of a planned or existing system on the basis of single
model.
<<extend>>
The interaction steps defined in the use case "download traffic base
information" are included in the interaction steps of the use case use case
“navigate to destination” if a certain condition , such as “avoid
congestion”, is met.

The extending use case is dependent on the base use case.

<<include>>
the interaction steps defined in the use cases "input
destination" and "retrieve current position" are contained
in the use case "navigate to destination“

The base case is incomplete without the included use

case.
More on <<extend>> and <<include>>

Base case
<<include>>

Base case
Let’s draw a use case diagram
1. Go to:
https://online.visual-paradigm.com/diagrams/solutions/free-use-case-diagram-
tool/

2. Scroll down, click on Make a Use Case Diagram

3. Choose Build from Scratch or start from a template

6.3.2 Use Case Specifications
 ERD DFD

In your SRS, choose either

UML diagrams OR non-UML
such as ERD/ DFD)

UML State Diagram

Entity Relationship Diagram
An Entity Relationship (ER) Diagram is a type of diagram that
illustrates how “entities” such as people, objects or concepts
relate to each other within a system.
 Entity-
relationship
diagram

Example 1
UML Class Diagram
Class diagrams are the main building block in object-oriented
modeling. They are used to show the different objects in a
system, their attributes, their operations and the relationships
among them.
UML Class
Diagram The meaning:

https://www.visual-
paradigm.com/guide/uml-
unified-modeling-language/
uml-aggregation-vs-
composition/
UML Class Diagram

Example 1
 Association

Aggregation
part of
In this, the linked objects are independent of each other.

part of
Composition
the linked objects are dependent on each other.
 UML Class Diagram

Example 2
Cheque
Data Flow Diagram
• A data-flow diagram is a way of representing
a flow of data through a process or a system (usually an
information system).
• The DFD also provides information about the outputs and
inputs of each entity and the process itself.
 DFD

Example 1
 DFD

Example 2
UML Activity Diagram
•Well suited to model action sequences.
UML Activity
Diagram

Example 1
Activity Diagram Example - Process Order

UML Activity
Diagram

Example 2
Activity Diagram Example (with swimlane) –
Meeting a new client

UML Activity
Diagram

Example 3
UML State Chart Diagram
•A diagram that illustrates processes that are executed in the system
that change the state of objects.
•A state diagram shows the actual changes in state, not the processes
or commands that created those changes.
 UML State
Chart Diagram

Example 1
State Chart Diagram/ State Machine Diagram Example –
Bank ATM

UML State
Chart Diagram

Example 2
State Chart Diagram/ State Machine Diagram Example –
Bank Account

UML State
Chart Diagram

Example 3
References
• Requirements Engineering Fundamental by IREB

• https://creately.com/blog/diagrams/use-case-diagram-relationships/

• https://www.visual-paradigm.com/guide/uml-unified-modeling-language/uml-aggregation-vs-compositio
n/

• https://www.javatpoint.com/uml-association-vs-aggregation-vs-composition

• https://www.visual-paradigm.com/guide/uml-unified-modeling-language/what-is-activity-diagram/

• https://d1dlalugb0z2hd.cloudfront.net/solutions/statemachine/5_steps_to_draw_a_state_machine_diagra
m.pdf