Een uitgebreide samenvatting voor het examen iEXA Application Design and Development. De samenvatting is geschreven aan de hand van de leerstof van de LOI. De opbouw van de samenvatting is op basis van het iEXA servicedocument. Aangezien het document netjes is opgemaakt zijn het zo'n 110 pagina's. ...
iEXA Application Design and Development
A6 Application Design
A6.1 De kandidaat heeft inzicht in principes, technieken en
meeteenheden m.b.t. applicatie ontwerp
A6-K1.1 De kandidaat kan modellering van vereisten (requirements modelling) en
technieken voor behoefteanalyse onderscheiden. (b)
Aan de hand van:
De stappen van requirements engineering:
- Inception (basisbegrip van probleem waarvoor oplossing wordt gezocht)
- Elicitation (verhelderen en vaststellen bedrijfsdoelen)
- Elaboration (verfijnen/ opstellen model van vereisten (requirements model)
- Negotiation (onderhandelen over mogelijkheden)
- Specification (specificeren vereisten)
- Validation (beoordelen of de vereiste goed is gespecificeerd)
- Requirements management (managen van (veranderingen) van vereisten)
Requirements engineering omvat 7 taken: inception, elicitation, elaboration, negotiation,
specificication, validation en management. Sommige taken gaan parallel en allemaal worden ze
aangepast aan de behoeften van het project.
opnieuw beoordelen
Inception – basisbegrip van probleem waarvoor oplossing wordt gezocht.
De belanghebbende stellen fundamentele probleemvereisten vast, stellen dwingende
projectbeperkingen vast en richten zich op de belangrijkste kenmerken en functies die aanwezig
moeten zijn om de doelstellingen van het systeem te kunnen verwezenlijken
- Wat is het probleem?
- Om welke gebruikers gaat het
- De aard van de oplossing die gewenst is
- Hoe gaat de communicatie verlopen tussen stakeholders en het ontwikkelteam
Elicitation – verhelderen en vaststellen bedrijfsdoelen - inventariseren van requirements
- Gebruik gemaakt van gefaciliteerde meetings, QFD, en de ontwikkeling van user scenario’s
- Wie zijn belanghebbende? => alle groepen vertegenwoordigt? => eisen en wensen
inventariseren => expliciet maken requirements
- Actief proces
- Moeilijkheid – domeinkennis vaak niet op één plaats als consistente set aanwezig =>
verschillende bronnen zijn nodig
2 belangrijkste bronnen: domein en belanghebbenden
§ Documentstudie – nuttig als requirementsanalist organisatie niet kent
§ Analyse bestaand systeem – waarom vraag
§ Interviews – laagdrempelig
§ Workshops – belanghebbende werken als groep samen om sneller en consistent
resultaat te bereiken
Samenvatting iEXA Application Design and Development april 2018 1
, § Observatie – dagelijkse praktijk (tijdrovend)
§ Brainstormen – ideaal voor nieuw requirement
§ Taakanalyse – onderverdelen in subtaken -> hierarchie
§ Scenario – opeenvolging van stappen
§ Prototypen
• Horizontale prototyping – gehele gebruikersinterface gemaakt zonder
achterliggende functionaliteit – getoonde gegevens zijn nep
Ø Om te beoordelen of functionaliteit ontbreekt, overbodig is of
aangepast moet worden
• Verticale prototyping – proof of concept PoC – een deel van de
gebruikersinterface, met wel de volledige functionaliteit erachter
Ø Gebruikt om te toetsen of voldoet aan de gestelde (niet-
functionele) eisen.
(Niet echt elicitatietechniek, meer voor risicoreductie)
§ Combinatietechnieken
§ Hulpmiddelen – post-it etc.
Eleboration – verfijnen/opstellen model van vereisten (requirements model)
- Collectie van scenario based, activity based, class based, behavioral en flow-oriented elements
- Beschrijft hoe gebruikers met het systeem omgaan
- Maken van use cases
- Het model kan verwijzen naar analyse patronen, kenmerken van het probleem domein waarvan
is vastgesteld dat het terugkomt in verschillende applicaties.
Negotiation – onderhandelen over mogelijkheden
- Onderhandelen tussen softwareteam en andere belanghebbende bij het project over prioriteit,
beschikbaarheid en relatieve kosten van elk requirement.
- Wat wel en niet in systeem komt
- De volgorde van de requirements bepalen met stakeholders en gebruikers
- Om een realistisch projectplan te ontwikkelen – risico’s identificeren en analyseren.
Analystechnieken – vaak samen met elicitation (dit bestaat uit eleboration en negatiote ???)
- Na elke elicitatiestap evalueren verzamelde requirement
Filteren:
- Punten die geen eisen zijn => verwijderen
- Inconsistenties en overlapping => opheldering vragen
Technieken voor opsporen en communiceren
- Checklist – helpt bij standaardiseren analyse
- Requirementscategorieën – 1 requirement kan in meerdere categorieën vallen
- Requirementattributen – ondersteunende informatie bij requirement – helpen bij
interpreteren en beheren
- Interactiematrix – helpt bij niet vergeten requirement bij zoeken naar overlappingen,
inconsistentie en conflicten
§ Alleen voor bepaalde scope -> meest gedetailleerde vorm = systeem
requirements
Samenvatting iEXA Application Design and Development april 2018 2
, § 1 = conflict, 1000 = overlap, 0 = beïnvloed elkaar niet
- Probleempatronen – hulpmiddelen om een groot analyseprobleem op te delen in
kleinere problemen waarvoor bekende oplossingen bestaan
5 basisprobleempatronen: benodigd gedrag, opgedragen gedrag, informatie tonen,
gereedschap en transformatiepatronen
Specification – specificeren vereisten
- Vastleggen in document, of set van grafische modellen of een formeel wiskundig model, een
collectie van usage scenario’s, een prototype of een combinatie
Opgenomen in
requirement
Gepresenteerd in document doelgroep
model Gemaakt voor
Opgenomen in
Afbeelding 1 Relatie tussen requirements, modellen en documenten
- Scopemodellen
§ Systeemcontextdiagram – SCD
§ Use-case model
- Structuurmodel
§ Entiteitsrelatiediagram – ERD
- Dynamisch gedrag
§ Toestandtransitiediagram
§ Stroomschema (in UML activiteitendiagram)
- Standaardzinsamenstelling – template vaste zinsconstructie => makkelijker te begrijpen
Scope Structuur Gedrag
Systeemcontextdiagram X
Use-casemodel X
Entiteitrelatiediagram X
Stroomschema X
Toestandtransitiediagram X
Samenvatting iEXA Application Design and Development april 2018 3
, Validation – beoordelen of vereiste goed is gespecificeerd
- Tegenover klant, om ervoor te zorgen dat het juiste systeem wordt gebouwd.
- Door verschillende belanghebbende
Requirements management – geheel van activiteiten die het projectteam helpt bij het identificeren,
controleren en volgen (trace) van requirements en changes in requirements naarmate project volgt.
Activiteiten grotendeels identiek aan softwareconfiguratiebeheertechnieken (SCM).
Use Case – beschrijft hoe systeem reageert op handeling van gebruiker
Granulariteit use case:
§ Cloud – hoogst niveau
§ Kite
§ Sea – correspondeert met processtap –
meest toegepast
§ Fish
§ Clam – te ver doorgegaan
Use Case diagram – visualiseert samenhang tussen use cases
User stories – geeft doel van gebruiker aan
Als <de rol> wil ik <activitiet> zodat <waarde business>
vb. als projectmanager wil ik per week een overzicht krijgen van de gewerkte uren zodat ik
kan zien of mijn project nog op schema ligt.
Technieken voor niet-functionele requirements
- Expliciet maken met ISO 25010
- Bepaal de belangrijkste
- Per bepaalde kwaliteitseigenschap vastleggen indicatoren, meetvoorschriften, norm
§ Indicator – in welke mate is kwaliteitseigenschap gerealiseerd
§ Meetvoorschrift – instructie voor het afleiden waarden van indicator
§ Norm – eenheid waaraan voldaan moet worden
indicator
meetvoorschrift
norm
Afbeelding 2 - kwaliteitseisen meetbaar maken
Samenvatting iEXA Application Design and Development april 2018 4
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 SuzVer. Stuvia faciliteert de betaling aan de verkoper.
Zit ik meteen vast aan een abonnement?
Nee, je koopt alleen deze samenvatting voor €15,49. Je zit daarna nergens aan vast.
