This document includes lecture slides and notes. It only contains the last lectures after Christmas Break. Everything before this (for the midterm) is in a separate file
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
The benefits of buying summaries with Stuvia:
Guaranteed quality through customer reviews
Stuvia customers have reviewed more than 700,000 summaries. This how you know that you are buying the best documents.
Quick and easy check-out
You can quickly pay through credit card or Stuvia-credit for the summaries. There is no membership needed.
Focus on what matters
Your fellow students write the study notes themselves, which is why the documents are always reliable and up-to-date. This ensures you quickly get to the core!
Frequently asked questions
What do I get when I buy this document?
You get a PDF, available immediately after your purchase. The purchased document is accessible anytime, anywhere and indefinitely through your profile.
Satisfaction guarantee: how does it work?
Our satisfaction guarantee ensures that you always find a study document that suits you well. You fill out a form, and our customer service team takes care of the rest.
Who am I buying these notes from?
Stuvia is a marketplace, so you are not buying this document from us, but from seller IsabelleU. Stuvia facilitates payment to the seller.
Will I be stuck with a subscription?
No, you only buy these notes for $7.04. You're not tied to anything after your purchase.
