Requirements Engineering Final
Lecture 8 - Requirements Modelling (exercise in BB)
On modelling requirements
• Applications of requirements modelling
o For certain types of requirements it makes more sense to create models than to
have text
o Requirements can be modelled with different purposes in mind:
▪ As a form of specification (petri nets)
▪ To support testing (sequence diagrams)
▪ To increase clarity (class diagram; communication between teams)
• Graphical presentation allows you to communicate things in a different way. Content
is equivalent to textual presentation, but the visual presentation is different.
• Which diagram type?
o The relevance of a diagram type depends on
▪ Target audience
▪ Type of requirements (to show data, to show user…)
▪ Type of system (information system vs. embedded system)
▪ Application domain (bank, automation technology, vehicle industry)
o Universal languages like UML and SysML (not single modelling languages, but
many) make the distinction between requirements models and system design
blurred. While we talk about requirements modelling, several things also apply
to things that go beyond requirements.
• Benefits of requirements modelling
o Requirements are easier to understand: “A picture is worth a thousand words!”
o Support of fundamental system design paradigms
o Separation of concerns: Requirements modeling allows for the identification
and separation of different concerns or aspects of the system. This modular
approach helps in managing complexity by breaking down the system into
smaller, more manageable components, each addressing specific aspects of the
overall functionality.
o Divide and conquer: breaking down complex problems into smaller, more
manageable pieces. This approach simplifies the development process, as
individual components can be addressed independently before being integrated
into the larger system.
o Reduced risk of ambiguity: Requirements modeling helps in clarifying and
specifying system requirements in a structured manner. Ambiguities in the
requirements, which can lead to misunderstandings and errors in the final
product, are minimized through clear visual representations and well-defined
models.
o Potential for automated analysis: Requirements models can be subjected to
automated analysis tools. This allows for the detection of inconsistencies,
dependencies, or other issues early in the development process. Automated
analysis contributes to the overall quality of the requirements and helps in
preventing downstream problems.
o Requirements in context: Requirements models provide a way to place
requirements in the context of the overall system. This contextual understanding
1
, is crucial for stakeholders to see how individual requirements contribute to the
overarching goals and functionalities of the system.
• Quality of requirements models
o
o 3 dimensions:
▪ Syntactic: model is compliant with syntactic rules
▪ Semantic: correctness and completeness of content
▪ Pragmatic: fit for use?
Automated extraction of models with the Visual Narrator
• OK, so you’ve got a set of sanitized user stories - Additional obstacles
o As development goes on, the number of user stories increases
o How to get a holistic view?
o Team members leave, and take away their know-how
o Novices need to learn the jargon
o In agile development, often without a glossary!
• How can you get a clear view of the concepts? Conceptual modelling to the rescue!
• Conceptual model extraction
1. Split on indicators
i. Role As a visitor,
ii. Means I want to choose an event
iii. End so that I can book a ticket for that event
2. Functional role
▪ As a [visitor]entity
3. Simplify the means
i. [I]=visitor want to choose an event
4. Main relationship
i. [I]=visitor want to [choose]rel an [event]ent
5. Simplify the end
i. so that [I]=visitor can book a ticket for that event
6. End relationship
▪ Role As a [visitor]entity
i. Means [I]=visitor want to [choose]rel an [event]ent
2
, ii. End so that [I]=visitor can [book]rel a [ticket]ent for that [event]ent
Manual derivation: interaction model
• The Visual Narrator work has some good impact, but . . .
• The goal is to extract a model, no big emphasis on its purpose
• Alternative approach:
1. Interaction model to represent the user-system relationship
2. Information structure model to represent the domain entities
• Interaction Model - Use Cases as a basis
o A use case defines
▪ the functions to be provided by the system
▪ which actors will use which functions
o Each use case is
▪ a pattern of behavior (function) required of the new system
▪ a sequence of related actions performed by an actor and the system
o An actor is anything that needs to interact with the system
▪ a person
▪ a role
▪ an external system
• Main elements of a use case
o Actors
o Primary actor: actor who initiates the interaction with the system to achieve a
goal
o Trigger: this is the event that causes the use case to be initiated
o Precondition: what must be true or happen before and after the use case runs
o Main success scenario [Basic Flow]: use case in which nothing goes wrong
o Alternative paths [Alternative Flow]: Variations of the basic flow in which
things do not go right
• From Use Cases to Use Case Diagrams (UCD)
o A use case diagram captures the relationship between actors and use cases
o Here, the staff is the main actor responsible for change client contact
• Extension, inclusion, generalization
o <<extend>> when one case adds behavior to a base case, a more advanced
version of a base case
3
Lecture 8 - Requirements Modelling (exercise in BB)
On modelling requirements
• Applications of requirements modelling
o For certain types of requirements it makes more sense to create models than to
have text
o Requirements can be modelled with different purposes in mind:
▪ As a form of specification (petri nets)
▪ To support testing (sequence diagrams)
▪ To increase clarity (class diagram; communication between teams)
• Graphical presentation allows you to communicate things in a different way. Content
is equivalent to textual presentation, but the visual presentation is different.
• Which diagram type?
o The relevance of a diagram type depends on
▪ Target audience
▪ Type of requirements (to show data, to show user…)
▪ Type of system (information system vs. embedded system)
▪ Application domain (bank, automation technology, vehicle industry)
o Universal languages like UML and SysML (not single modelling languages, but
many) make the distinction between requirements models and system design
blurred. While we talk about requirements modelling, several things also apply
to things that go beyond requirements.
• Benefits of requirements modelling
o Requirements are easier to understand: “A picture is worth a thousand words!”
o Support of fundamental system design paradigms
o Separation of concerns: Requirements modeling allows for the identification
and separation of different concerns or aspects of the system. This modular
approach helps in managing complexity by breaking down the system into
smaller, more manageable components, each addressing specific aspects of the
overall functionality.
o Divide and conquer: breaking down complex problems into smaller, more
manageable pieces. This approach simplifies the development process, as
individual components can be addressed independently before being integrated
into the larger system.
o Reduced risk of ambiguity: Requirements modeling helps in clarifying and
specifying system requirements in a structured manner. Ambiguities in the
requirements, which can lead to misunderstandings and errors in the final
product, are minimized through clear visual representations and well-defined
models.
o Potential for automated analysis: Requirements models can be subjected to
automated analysis tools. This allows for the detection of inconsistencies,
dependencies, or other issues early in the development process. Automated
analysis contributes to the overall quality of the requirements and helps in
preventing downstream problems.
o Requirements in context: Requirements models provide a way to place
requirements in the context of the overall system. This contextual understanding
1
, is crucial for stakeholders to see how individual requirements contribute to the
overarching goals and functionalities of the system.
• Quality of requirements models
o
o 3 dimensions:
▪ Syntactic: model is compliant with syntactic rules
▪ Semantic: correctness and completeness of content
▪ Pragmatic: fit for use?
Automated extraction of models with the Visual Narrator
• OK, so you’ve got a set of sanitized user stories - Additional obstacles
o As development goes on, the number of user stories increases
o How to get a holistic view?
o Team members leave, and take away their know-how
o Novices need to learn the jargon
o In agile development, often without a glossary!
• How can you get a clear view of the concepts? Conceptual modelling to the rescue!
• Conceptual model extraction
1. Split on indicators
i. Role As a visitor,
ii. Means I want to choose an event
iii. End so that I can book a ticket for that event
2. Functional role
▪ As a [visitor]entity
3. Simplify the means
i. [I]=visitor want to choose an event
4. Main relationship
i. [I]=visitor want to [choose]rel an [event]ent
5. Simplify the end
i. so that [I]=visitor can book a ticket for that event
6. End relationship
▪ Role As a [visitor]entity
i. Means [I]=visitor want to [choose]rel an [event]ent
2
, ii. End so that [I]=visitor can [book]rel a [ticket]ent for that [event]ent
Manual derivation: interaction model
• The Visual Narrator work has some good impact, but . . .
• The goal is to extract a model, no big emphasis on its purpose
• Alternative approach:
1. Interaction model to represent the user-system relationship
2. Information structure model to represent the domain entities
• Interaction Model - Use Cases as a basis
o A use case defines
▪ the functions to be provided by the system
▪ which actors will use which functions
o Each use case is
▪ a pattern of behavior (function) required of the new system
▪ a sequence of related actions performed by an actor and the system
o An actor is anything that needs to interact with the system
▪ a person
▪ a role
▪ an external system
• Main elements of a use case
o Actors
o Primary actor: actor who initiates the interaction with the system to achieve a
goal
o Trigger: this is the event that causes the use case to be initiated
o Precondition: what must be true or happen before and after the use case runs
o Main success scenario [Basic Flow]: use case in which nothing goes wrong
o Alternative paths [Alternative Flow]: Variations of the basic flow in which
things do not go right
• From Use Cases to Use Case Diagrams (UCD)
o A use case diagram captures the relationship between actors and use cases
o Here, the staff is the main actor responsible for change client contact
• Extension, inclusion, generalization
o <<extend>> when one case adds behavior to a base case, a more advanced
version of a base case
3
