Samenvatting
Summary Final exam Requirements Engineering
- Instelling
- Universiteit Utrecht (UU)
Only the last couple of lectures, including notes.
[Meer zien]Voorbeeld 3 van de 20 pagina's
Voorbeeld 3 van de 20 pagina's
In winkelwagengesponsord bericht van onze partner
Voorbeeld van de inhoud
Requirements Engineering FinalLecture 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
Voordelen van het kopen van samenvattingen bij Stuvia op een rij:
Verzekerd van kwaliteit door reviews
Stuvia-klanten hebben meer dan 700.000 samenvattingen beoordeeld. Zo weet je zeker dat je de beste documenten koopt!
Snel en makkelijk kopen
Je betaalt supersnel en eenmalig met iDeal, creditcard of Stuvia-tegoed voor de samenvatting. Zonder lidmaatschap.
Focus op de essentie
Samenvattingen worden geschreven voor en door anderen. Daarom zijn de samenvattingen altijd betrouwbaar en actueel. Zo kom je snel tot de kern!
Veelgestelde vragen
Wat krijg ik als ik dit document koop?
Je krijgt een PDF, die direct beschikbaar is na je aankoop. Het gekochte document is altijd, overal en oneindig toegankelijk via je profiel.
Tevredenheidsgarantie: hoe werkt dat?
Onze tevredenheidsgarantie zorgt ervoor dat je altijd een studiedocument vindt dat goed bij je past. Je vult een formulier in en onze klantenservice regelt de rest.
Van wie koop ik deze samenvatting?
Stuvia is een marktplaats, je koop dit document dus niet van ons, maar van verkoper IsabelleU. Stuvia faciliteert de betaling aan de verkoper.
Zit ik meteen vast aan een abonnement?
Nee, je koopt alleen deze samenvatting voor €6,49. Je zit daarna nergens aan vast.
Is Stuvia te vertrouwen?
4,6 sterren op Google & Trustpilot (+1000 reviews)
Afgelopen 30 dagen zijn er 53068 samenvattingen verkocht
Opgericht in 2010, al 14 jaar dé plek om samenvattingen te kopen