REQUIREMENTS ENGINEERING
LECTURE 2014/2015
Dr. Jörg Dörr
Conceptual Modelling
© Fraunhofer IESE
AGENDA
 Standards & Templates
 Natural Language Requirements
 Specification with Conceptual Models
 Suitable Models for different Aspects
2
© Fraunhofer IESE
Requirements Specification
SPECIFICATION WITH
CONCEPTUAL MODELS
3
© Fraunhofer IESE
Requirements Analysis as Part of Specification
 Requirements Analysis is performed in order to analyze certain quality
characteristics of requirements
 Is Requirements Analysis then synonym to requirements V&V?
 No! Analysis is concerned with an incomplete set of requirements, not
discussed by the stakeholder. Requirements Analysis can be a very early
activity.
 Requirements validation should have a complete, agreed upon set of
requirements as input. Therefore, it is also regarded as part of the
specification.
4
© Fraunhofer IESE
Means for Requirements Analysis
 Analysis Checklists
 Conceptual Modeling
5
© Fraunhofer IESE
Requirements Analysis Checklists – Typical Questions
(1)
 Is the requirement adequate with the business goal of the project?
 Does the requirement conflict with some domain constraint, policies or
regulation?
 Does the requirement include premature design or implementation
information?
 Is the requirement necessary?
 Does the requirement require non-standard hardware or must software be
used?
 Is the requirement ambiguous, could different persons read it in different
ways?
 What are the different interpretations for the requirement?
 Is the requirement realistic given the technology that will used to implement
the system?
6
© Fraunhofer IESE
Requirements Analysis Checklists – Typical Questions
(2)
 Does the description of a requirement describe a single requirement or could it
be broken into several different requirements?
 Has each requirement been assigned a priority?
 Are the system boundaries well defined?
 Have the portability, reliability, usability and maintainability requirements for
the system been respected?
 Did you develop a behavioral or structural model for the system?
 Is the Data Dictionary implemented and correctly updated?
 Is the requirement testable by the test engineers?
7
© Fraunhofer IESE
Conceptual Modeling
 Conceptual Modeling is performed by the requirements engineer (analyst) to
understand the problem domain and the requirements.
 Various models can be created to find out whether a problem domain or the
requirements are understood well, i.e., whether the understanding of the
requirements engineer is complete, consistent, and correct:
 Goals
 Data
 Interaction
 Structure
…
 Note: The models created during conceputal modeling are not necessarily
part of the requirements specification. But they can be part of the
requirements specification.
8
© Fraunhofer IESE
Conceptual Models
 For the different models, also various notations can be used, e.g.,
 i-star (i*)
 E/R Diagrams
 UML
 SysML
 Business Process Modelling Notations
…
9
© Fraunhofer IESE
Goal Modeling – Definitions
 Goal Models are often the first models used as they are on a high abstraction
level.
 Definition goal:
 “A goal is a desirable state lying in the future, which is not reached
automatically but by specific actions.”
 Goals and their dependencies are often described in conceptual models that
are based on modelling languages.
 Definition goal model: “A goal model is a conceptual model. Its goals and
decompositions are documented in sub-goals and as necessary further
dependencies between (sub)-goals.“
10
© Fraunhofer IESE
Goal Modeling: Why should one do goal modeling?
 Goals can be one of the very early starting points (besides current problems)
for requirements elicitation
 Goals are a fundamental concept to understand why new software or systems
or changes to these systems are needed
 Goal modeling can be the anchor (rationale) for the following requirements 
traceability from high level to lower level
11
© Fraunhofer IESE
Classification of Goals
Subject that has a goal
 Organizations or organizational units
 Individual Persons or Roles
Object affected by the goal
 Quality goals
 Functional goals
12
© Fraunhofer IESE
Representation of Goals
Various notations exist for goal modeling
 i-star (i*)
 GRL
 SIG (Softgoal interdependency graphs)
 And / OR – Trees
 Just text
 …
13
© Fraunhofer IESE
i*-Framework
I*-Framework
 I*-Framework is a graphical modelling language that is used for analysing and
documentation
 It can be used in an early phase of system modelling for detecting and
understanding problems
 It consists of two different models:
 Strategic Dependency Model (SDM): The Strategic Dependency Model is
used to describe the dependency relationships among various actors.
 Strategic Rationale Model (SRM): The Strategic Rationale Model is used to
provide rationales for single dependencies in the SDM.
14
© Fraunhofer IESE
Objects in i*
Objects in i*
Actor
Actor Boundary
Resource
Softgoal
An actor is a person or a system that is in
contact with the system. (Agents, Roles,
Positions)
A resource is a result required or supplied by
the actor for completing the goal
A soft-goal describes the wish of an actor to
complete a function regarding the quality
Goal
A goal is the documented intention of an actor
Task
A task consists of a number of steps which an
actor has to execute for completing a task
15
© Fraunhofer IESE
Connections in i*
Dependencies in i*
Depender
Dependee
D
D
The soft-goal dependency describes an actors
(Depender) completion of a soft-goal depends on
another actor (Dependee).
Soft-goal Dependency
D
D
Goal Dependency
D
D
The task dependency describes that an actor
(Depender) depends on a task and that task depends
on another actor (Dependee)
D
The resource dependency describes an actors
(Depender) depending on a resource for goal
completion and the resource is supplied by another
actor (Dependee)
Task Dependency
D
The goal dependency describes an actors
(Depender) completion of a goal depends on another
actor (Dependee)
Resource Dependency
16
© Fraunhofer IESE
Connections in i*
Links
Means-end-Link
Task-Decomposition-Link
+/-
Contribution-Link
+ pos. affected
The means-ends-link expresses what soft-goals, tasks
and/or resources are needed to complete a goal. A meansends-link documents the reason why an actor is able to
complete a specific goal, execute a specific task or use a
specific resource.
The task-decomposition-link describes more detailed a
task though goals, soft-goals, resources and/or more
specified tasks. A task-decomposition-link documents the
essential elements of a task to complete sub-goals or softgoals an the needed resources.
The contribution-link describes a positive or a negative
affect on soft-goals through tasks or other soft-goals. A
contribution-link describes in what extend a task or another
soft-goal contributes the soft-goal. But it does not explain the
precisely range of support.
- neg. affected
17
© Fraunhofer IESE
Example SDM
Example taken from Master Software Engineering for
Embedded Systems, TU Kaiserslautern, Textbook E-M.2
18
© Fraunhofer IESE
Example SRM
Example taken from Master Software Engineering for
Embedded Systems, TU Kaiserslautern, Textbook E-M.2
19
© Fraunhofer IESE
And / OR Decompositions (Trees)
And-decomposition of a goal, i.e., the coarse-grain goal G0 is refined into several
fine-grain goals G1 … Gn that all have to be fulfilled to achieve goal G0.
Or-decomposition of a goal. Again, a coarse-grain goal G0 is refined into several
fine-grain goals G1 … Gn. To fulfill G0, one (or more) of G1 … Gn have to be
achieved.
20
© Fraunhofer IESE
Example
Example taken from Master Software Engineering for
Embedded Systems, TU Kaiserslautern, Textbook E-M.2
21
© Fraunhofer IESE
Usage of UML for Conceptual Modeling (1)
 Various Diagrams of the UML can be used for Requirements Analyis, e.g.:
 Activity Diagrams for business processes / workflows
 Class and Object Diagrams for modeling data
 User Interface Navigation Maps, Collaboration Diagrams, and Sequence
Diagrams for Interaction between different systems and stakeholders and
systems
23
© Fraunhofer IESE
Usage of UML for Conceptual Modeling (2)
 Use Case Diagrams for getting an overview on the system functionality
 State Diagrams for modeling intended system states and their transformation
or the (business) object lifecycles
 …
24
© Fraunhofer IESE
UML Class Diagram to show Object Relationships
25
© Fraunhofer IESE
Figures taken from: Dr. Darius Silingas, Prof. Rimantas Butleris
„UML-Intensive Framework for Modeling Software
Requirements“
UML Diagram for Object Lifecycle
26
© Fraunhofer IESE
Figures taken from: Dr. Darius Silingas, Prof. Rimantas Butleris
„UML-Intensive Framework for Modeling Software
Requirements“
UML Use Case Model for Functional Overview
27
© Fraunhofer IESE
Figures taken from: Dr. Darius Silingas, Prof. Rimantas Butleris
„UML-Intensive Framework for Modeling Software
Requirements“
UML Activity Diagram to refine a Use Case
28
© Fraunhofer IESE
Figures taken from: Dr. Darius Silingas, Prof. Rimantas Butleris
„UML-Intensive Framework for Modeling Software
Requirements“
UML Information Flow Diagram for System Context
29
© Fraunhofer IESE
Figures taken from: Dr. Darius Silingas, Prof. Rimantas Butleris
„UML-Intensive Framework for Modeling Software
Requirements“
Conceptual Models in Different RE-Approaches
Holtzblatt
[Beyer & Holtzblatt, 98]
Armour [Armour & Miller, 01]
Use Case Diagram
Domain Object Modell
Initial what-is System Use Case
•
•
•
•
•
•
Work Model
Focus Area
User Environment Design (UED)
Storyboard
Use Case
Object Model
Initial what will be System Use Case
Constantine
Base System Use Case
[Constantine & Lockwood, 99]
Internal Use Case
•
•
•
•
•
•
Elaborated System Use Case
Transaction Information Model
Transaction Trees
Analysis Object Model
Task model
Domain model
Content model
Context Navigation Map
Essential Use Case
Use Case Maps
Many different models and tasks, but
basic design decisions are in common
30
© Fraunhofer IESE
Conceptual Models Summary
 Conceptual models help clarifying certain aspects of a system in more detail
than just natural language
 Support requirements analysis
 For different aspects of a system, different notations can be used
31
© Fraunhofer IESE
Requirements Specification
SUITABLE MODELS FOR
DIFFERENT ASPECTS
32
© Fraunhofer IESE
TORE as a Model for Reference Objects and Decision
Points
Requirements Decisions
Goal &
Task
Level
Domain
Level
Interaction
Level
System
Level
Supported
Stakeholders
Stakeholder‘s
Goals
Stakeholder‘s
Tasks
As-is Activities
To-be Activities
System
Responsibilities
Domain Data
System Functions
Interactions
Interaction-Data
UI-Structure
GUI
Navigation/
Supported Functions
Application Core
Dialog
UI-Data
Screen-Structure
Internal Actions
Architecture
Internal Data
33
© Fraunhofer IESE
TORE: Task Level
TORE
Requirements Decisions
Goal &
Task Level
Supported
Stakeholders
Stakeholder‘s
Goals
Stakeholder‘s
Tasks
As-is Activities
To-be Activities
System
Responsibilities
Domain Data
System Functions
Interactions
Interaction-Data
UI-Structure
Domain
Level
 Decisions:
 What roles have to be supported?
Interaction
Level
System
Level
GUI
Navigation/
Supported Functions
Application Core
 What are the goals of the users?
Dialog
UI-Data
Screen-Structure
Internal Actions
Architecture
Internal Data
 What tasks do these roles perform as part of their work?
 Notations:
 Personas
 Role descriptions
 Goal Modeling Notations (i*)
 Task description template
 Natural language
34
© Fraunhofer IESE
How to Describe the Users (1)?
 A user role is an abstract summary of needs, interests, expectations, behavior,
and responsibilities that are characteristic for a set of future system users
[according to Constantine/Lockwood99].
 A user profile describes the knowledge and the skills of typical users.
 Can be elicited by
 asking the users
 asking surrogate users (marketing, sales, hotline, trainer)
 examining documents in the business process
35
© Fraunhofer IESE
How to Describe the Users (2)?
 Role Description
 Responsibilities
 Success criteria
 Tasks
 Communication partners
 Degree of innovation
 User Profile:
 Knowledge/experience/skills
 regarding tasks
 regarding software system
36
© Fraunhofer IESE
Example: Counter Employee in University Library (1)
 Role Description
 Responsibility: taking care of readers, issuing books
 Success criteria: reader satisfaction, book inventory up to date
 Tasks: advice, issue, return, registration, cancellation
 Communication partners: readers, librarians
 Degree of innovation: low
37
© Fraunhofer IESE
Example: Counter Employee in University Library (2)
 User Profile
 Prior knowledge of library tasks:
 Books: must be sufficient for advice
 Library workflows: often low, since student assistant
 Prior knowledge of software:
 Often low, since usually humanities student
38
© Fraunhofer IESE
Further Possibility: Description of “Personas”
 Personas describe stereotypical users
 Personas are very concrete
Example of a persona in the area of medical suction units
Name:
Prof. Dr. med. Ziak
Profile
Core Characteristics:
Age: 50
• Dominance, influence
Work environment: Own ENT office, in-patient beds in hospital,
thinking about opening second office. Not too big, simple,
sparsely furnished examination room. Occasionally goes to
university hospital to perform surgery. Prefers to take along
mobile equipment.
Product knowledge: Only what is essential. Has attended
continuing education events.
Patients: Many singers and actors. Choking stimulus in case of
contact with Mediastrobe. Prefers private patients.
• Professional, cool,
and competent
• Bargain hunter
Most frequent activities (with the product): Vocal cord
diagnosis, examination of the larynx, with video archiving.
Core Goals:
Most important activities: Early detection of larynx carcinomas;
restoration of voice function.
• Reputation
Rarer activities: Voice analysis;
Motto:
“Work and make money”
• Undecided,
skeptical
Typical obstacles: Little to no PC skills. Lack of practice in
using stroboscope. Tangled cables and foot switches.
Profitability.
• Private insurance
customers
• Make money
Family issues: Wife is managing office; 2 children, daughter
going to college and son supposed to take over the office one
day, but has totally different plans…
Other: Strives for expansion and influence. Has a good tax
advisor. Lives in Saarbrücken.
39
© Fraunhofer IESE
Description of Tasks
 Task evaluation
 Objectives
 Possibilities of engagement
 Causes
 Task performance
 Initial situation (precondition, priority, occurrence, rate of iterations)
 Info-In
 Info-Out
 Resources (means for work, actors, partners)
40
© Fraunhofer IESE
Description of Task „Book Return“
 Objective: book is back in library
 Possibilities of engagement: check book quality
 Causes: Loan period expired or voluntary return
 Initial situation: book dispensed; high priority; frequent
 Info-In: book
 Info-Out: confirmation of return
 Resources: processor, book file, user file
41
© Fraunhofer IESE
TORE
TORE: Domain Level
Requirements Decisions
Goal &
Task Level
Supported
Stakeholders
Stakeholder‘s
Goals
Stakeholder‘s
Tasks
As-is Activities
To-be Activities
System
Responsibilities
Domain Data
System Functions
Interactions
Interaction-Data
UI-Structure
Domain
Level
Interaction
Level
System
Level
GUI
Navigation/
Supported Functions
Application Core
Dialog
UI-Data
Screen-Structure
Internal Actions
Architecture
Internal Data
 Decisions:
 As-Is: What activities are relevant for the system?
 To-Be: How does the work process change
by using the system?
 System Responsibility: What is the key contribution of the system?
 Domain Data: What data is relevant in the domain?
 Notations:
 Process modeling notations (UML Activity Diagram, EPK, BPMN)
 Natural Language
 E/R-Diagram, UML Class Diagram
 UML Use Case Diagram
42
© Fraunhofer IESE
Example
Fetch Book
Book Store System
Provide Customer Data
Select Books
Customer
Place Order
Update
Book Store
43
© Fraunhofer IESE
Example
•A book has a title and an author.
It can be included in zero or
more orders.
Order
is_part_of
0...*
1
•A payment transfers money
from the customer to the
bookstore. This can be done
either by credit card or by bank
transfer.
Book
Title
Author
1...*
for
1
Payment
Amount
Type
0..*
is_submitted_
by
1
Customer
Address
44
© Fraunhofer IESE
TORE: Interaction Level
TORE
Requirements Decisions
Goal &
Task Level
Supported
Stakeholders
Stakeholder‘s
Goals
Stakeholder‘s
Tasks
As-is Activities
To-be Activities
System
Responsibilities
Domain Data
System Functions
Interactions
Interaction-Data
UI-Structure
Domain
Level
Interaction
Level
System
Level
 Decisions:
GUI
Navigation/
Supported Functions
Application Core
Dialog
UI-Data
Screen-Structure
Internal Actions
Architecture
Internal Data
 System Functions: Which functions are provided / automated by the
system?
 Interactions: How can the user interact with the system?
 UI-Structure: How to group data and functions in the UI?
 Interaction Data: What data is exchanged between system and user?
 Notations:
 Use Case Template
 System Function Template
 Logical UI
 Natural Language
© Fraunhofer IESE
45
Example: System Functions
 Name: Complete-Order function
 Informal Description:
Trigger: The user inputs shopping bag, payment method and
address.
The system checks the payment method and stores this information.
 Constraints: Shopping bag may not be empty for an order.
 Receives (Inputs): Shopping bag, payment method, address
 Returns (Outputs): „Order can be confirmed“
 Assumes: Nothing
 Result: Shopping bag, payment method, address and order is stored in the
system
46
© Fraunhofer IESE
Example: Interaction
 Name: Place Order
 Initiating Actor: Customer
 Realized User Task: Book Order
 Flow of events:
1. The System displays the shopping basket with the selected book.
2. The Actor selects the “Complete Order”-function. [No Customer Data]
3. The System shows order and supports the Actor in determining the
payment method and the address and submitting the order. [New selection]
[New customer data] [No order]
4. The Actor selects the „Submit Order“-function.
5. The System acknowledges the order to the Actor, stores the order and
supports the Clerk with the “Order Delivery”-responsibility.
6. The Actor receives the selected books
...
© Fraunhofer IESE
47
Use Cases
 Dominant approach of requirements analysis, especially for IT systems
 Focusing on usage of systems
 UML overview diagram
 Textual approach (actually use case description)
48
© Fraunhofer IESE
Usage of Use Cases (1)
 As description of functional requirements
 Comprehensible for users
 From perspective of the users
 Good connection to interface design
 Also as a unit for project planning
 As medium for requirement analysis
 Modeling approach
 Detail, completeness, management (changeability) are less important
 As medium for requirement specification
 Presetting for draft
 Detail, completeness, management (changeability) very important
49
© Fraunhofer IESE
Usage of Use Cases (2)
 A Use Case focuses on
 Interaction between user and system
 The execution of (a sequence) of system function(s)
 Achieving a specific goal
 Description of interaction sequences
 Well suited for communication with the user
50
© Fraunhofer IESE
Description of a Use Case (1)
Name
• Identifier of the use case
Actor
• Who triggers the use case?
Goal
• Describes objectives (rational) of the use case
• Can be replaced by a link to a use case of a higher level
Level
• Abstraction level of the use case
• e.g. overview / main level / detailing
Description
• Core of the use case!
• Describes only the main procedure
Scope
• Indicating the scope the use case refers to if there are
several sub-systems
• Used for clustering of related use cases
51
© Fraunhofer IESE
Description of a Use Case (2)
Business Rules
• Business Rules = organizational standards/agreements
• Description of limitations / background knowledge
Extensions/
Exceptions
• Describe special cases
• Lists reactions on exceptions
Quality Requirements
• Quantifiable quality requirements (NFRs)
Data/functions
• Data and functions that will be used within the use case
Preconditions
• State of the system and the environment according to the
perspective of the actors before the use case may be
performed
Postconditions
• State of the system and environment according to the
actors perspective after the performance of the use case
52
© Fraunhofer IESE
Use Case „Register User“ (1)
Actor
Library employee
Goal
Library user data is stored in the system, user has got a
library card
Level
Main level
Description
1.
2.
3.
4.
5.
Scope
Actor calls user registration
System is generating a new user number and displays
a window for user data input
Actor enters name, address and semester data of the
user
System prints a pass with the user number and the user
data
Actor hands out the pass to the user.
User management
53
© Fraunhofer IESE
Use Case „Register User“(2)
Business Rules
User has to belong to the faculty
Extensions/ Exceptions
3a. In case there is already a user with the same
name, the system asks, if there is really a new
user at hand; if so, proceed with step 4.
Quality Requirements
Step 4: Execution time < 15 Seconds
Data/functions
Data: user data
Function: user registration, pass printing
Preconditions
Librarian is logged in.
Post conditions
A complete data record with a unique number exists for every
user.
54
© Fraunhofer IESE
Creation of Use Cases
1. Identification of actors
(especially identification of user roles)
2. For every actor: identification of tasks
(every task is at least one use case)
3. Creation of a use case diagram
contains all actors and use cases
4. Detailed description of every use case
5. Optimization of the use cases to avoid redundancy
6. Prioritization of use cases
7. Clustering of use cases
55
© Fraunhofer IESE
Suitable Models for Different Aspects Summary
 TORE is IESE’s framework for the typical reference objects to be discussed /
decided within a RE process
 Each reference object / decision point can be described / clarified with
different notations
 TORE has strong focus on users, their tasks and the desired human-systeminteractions
 Use Cases are a very popular approach for modeling such interactions
58
© Fraunhofer IESE
Recommended Specification Practices (Summary)
Specif icat ion
Describe
requirement s in a
t est able w ay
Document
rat ionals
Use document
t emplat es
Document
developer
requirement s
M odel goals
Document
cust omer
requirement s
M odel t he user
int erf ace
M odel usage &
maint anance
scenarios
M odel syst em
f unct ions
M odel business
prociesses
M odel int eract ions
M odel domain
dat a
59
© Fraunhofer IESE
Questions
60
© Fraunhofer IESE