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
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 SuzVer. Stuvia facilitates payment to the seller.
Will I be stuck with a subscription?
No, you only buy these notes for $16.84. You're not tied to anything after your purchase.
