1. REQUIREMENTS ENGINEERING LECTURE 2014/2015
Dr. Jörg Dörr
Conceptual Modelling
Lecture 4: Conceptual Modeling of Requirements
Why Modeling?
Models in General
Types of Models and Their Purposes
Goal Models
Overview Models
Data Models
Activity Models
State Models
Summary

2. AGENDA Standards & Templates Natural Language Requirements
Specification with Conceptual Models
Suitable Models for different Aspects

3. Specification with conceptual models
Requirements Specification
Specification with conceptual models

4. 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.

5. Means for Requirements Analysis
Analysis Checklists
Conceptual Modeling

6. 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?

7. 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?

8. 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.

9. 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 …

10. 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.“

11. 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

12. 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

13. Representation of Goals
Various notations exist for goal modeling
i-star (i*)
GRL
SIG (Softgoal interdependency graphs)
And / OR – Trees
Just text …

14. 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.

15. Objects in i* Objects in i*
An actor is a person or a system that is in contact with the system. (Agents, Roles, Positions)
Actor
Actor Boundary
A resource is a result required or supplied by the actor for completing the goal
Resource
A soft-goal describes the wish of an actor to complete a function regarding the quality
Softgoal
Goal
A goal is the documented intention of an actor
A task consists of a number of steps which an actor has to execute for completing a task
Task

16. Dependencies in i* Connections in i*
Depender
Dependee
The soft-goal dependency describes an actors (Depender) completion of a soft-goal depends on another actor (Dependee). D D
Soft-goal Dependency
The goal dependency describes an actors (Depender) completion of a goal depends on another actor (Dependee) D D
Goal Dependency
The task dependency describes that an actor (Depender) depends on a task and that task depends on another actor (Dependee) D D
Task Dependency
The resource dependency describes an actors (Depender) depending on a resource for goal completion and the resource is supplied by another actor (Dependee) D D
Resource Dependency

17. Links Connections in i*
The means-ends-link expresses what soft-goals, tasks and/or resources are needed to complete a goal. A means-ends-link documents the reason why an actor is able to complete a specific goal, execute a specific task or use a specific resource.
Means-end-Link
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 soft-goals an the needed resources.
Task-Decomposition-Link
+/-
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.
Contribution-Link
+ pos. affected
- neg. affected

18. Example SDM
Example taken from Master Software Engineering for Embedded Systems, TU Kaiserslautern, Textbook E-M.2

19. Example SRM
Example taken from Master Software Engineering for Embedded Systems, TU Kaiserslautern, Textbook E-M.2

20. 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.

21. Example
Example taken from Master Software Engineering for Embedded Systems, TU Kaiserslautern, Textbook E-M.2

22. Example SRM for Goals
Example taken from Master Software Engineering for Embedded Systems, TU Kaiserslautern, Textbook E-M.2

23. 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

24. 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 …

25. UML Class Diagram to show Object Relationships
Figures taken from: Dr. Darius Silingas, Prof. Rimantas Butleris
„UML-Intensive Framework for Modeling Software
Requirements“

26. UML Diagram for Object Lifecycle
Figures taken from: Dr. Darius Silingas, Prof. Rimantas Butleris
„UML-Intensive Framework for Modeling Software
Requirements“

27. UML Use Case Model for Functional Overview
Figures taken from: Dr. Darius Silingas, Prof. Rimantas Butleris
„UML-Intensive Framework for Modeling Software
Requirements“

28. UML Activity Diagram to refine a Use Case
Figures taken from: Dr. Darius Silingas, Prof. Rimantas Butleris
„UML-Intensive Framework for Modeling Software
Requirements“

29. UML Information Flow Diagram for System Context
Figures taken from: Dr. Darius Silingas, Prof. Rimantas Butleris
„UML-Intensive Framework for Modeling Software
Requirements“

30. Conceptual Models in Different RE-Approaches
Holtzblatt
[Beyer & Holtzblatt, 98]
Work Model
Focus Area
User Environment Design (UED)
Storyboard
Use Case
Object Model
Constantine
[Constantine & Lockwood, 99]
Task model
Domain model
Content model
Context Navigation Map
Essential Use Case
Use Case Maps
Armour [Armour & Miller, 01]
Use Case Diagram
Domain Object Modell
Initial what-is System Use Case
Initial what will be System Use Case
Base System Use Case
Internal Use Case
Elaborated System Use Case
Transaction Information Model
Transaction Trees
Analysis Object Model
Many different models and tasks, but basic design decisions are in common

31. 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
completeness: contents that was missed prior to using standards will be identfied and can be specified thus raising
Problems usually the HOW is the biggest problem. Usaully people are statisfied at first when given such a template. Problems tend to arise quite fast as people generally do not know HOW to write the different sections. Major problems arise in the requirements sections (NFR and FR) as this is one of the most tricky parts. In addition IEEE830 indicates characteristics but does not give hints on how to achieve them. From experience this is usually one of the major problems with IEEE830.

32. Suitable models for different aspects
Requirements Specification
Suitable models for different aspects

33. TORE as a Model for Reference Objects and Decision Points
Requirements Decisions
Goal & Task Level
Supported
Stakeholders
Stakeholder‘s
Goals
Stakeholder‘s Tasks
Domain Level
As-is Activities
To-be Activities
System
Responsibilities
Domain Data
Interaction Level
System Functions
Interactions
Interaction-Data
UI-Structure
System Level
GUI
Navigation/
Supported Functions
Dialog
UI-Data
Screen-Structure
Application Core
Internal Actions
Architecture
Internal Data

34. TORE: Task Level Decisions: What roles have to be supported?
What are the goals of the users?
What tasks do these roles perform as part of their work?
Notations:
Personas
Role descriptions
Goal Modeling Notations (i*)
Task description template
Natural language

35. 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

36. 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

37. 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

38. 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

39. Further Possibility: Description of “Personas”
Personas describe stereotypical users
Personas are very concrete

40. 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)

41. 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

42. TORE: Domain Level 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

43. Example

44. Example

45. TORE: Interaction Level
Decisions:
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

46. 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

47. 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
...

48. 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)

49. 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

50. 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

51. 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

52. 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

53. 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
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.
Scope
User management

54. 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.

55. Creation of Use Cases
Identification of actors (especially identification of user roles)
For every actor: identification of tasks (every task is at least one use case)
Creation of a use case diagram contains all actors and use cases
Detailed description of every use case
Optimization of the use cases to avoid redundancy
Prioritization of use cases
Clustering of use cases

56. Actor Is external to the software
Interacting with the system (active or passive)
An actor represents a human in a certain role or an external system, e.g.:
correct: system administrator
correct: database application
wrong: John Smith (what‘s his role?)

57. Use Case Diagram Ordering Consulting Publisher Dispensing Returning
Counter employee
Collecting
Librarian
Registering
Deregistering

58. 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-system-interactions
Use Cases are a very popular approach for modeling such interactions
completeness: contents that was missed prior to using standards will be identfied and can be specified thus raising
Problems usually the HOW is the biggest problem. Usaully people are statisfied at first when given such a template. Problems tend to arise quite fast as people generally do not know HOW to write the different sections. Major problems arise in the requirements sections (NFR and FR) as this is one of the most tricky parts. In addition IEEE830 indicates characteristics but does not give hints on how to achieve them. From experience this is usually one of the major problems with IEEE830.

59. Recommended Specification Practices (Summary)

60. Questions ?
Specification