H3 Behoefteanalyse PDF

**[1.0 Vereisten]** - Behoeften v/klant waaraan project moet voldoen worden ook wel vereisten genoemd - We kunnen behoeften opdelen i/2 categorieën: functionele vereisten n x-functionele vereisten - Functionele vereisten = eisen die beschrijven wat programma moet kunnen...

**[1.0 Vereisten]** - Behoeften v/klant waaraan project moet voldoen worden ook wel vereisten genoemd - We kunnen behoeften opdelen i/2 categorieën: functionele vereisten n x-functionele vereisten - Functionele vereisten = eisen die beschrijven wat programma moet kunnen - Zegt m.a.w. welke functionaliteiten zullen beschikbaar zijn op systeem - X-functionele vereisten beschrijven daarentegen hoe systeem die functionele vereisten moet uitvoeren of hoe ze er moeten uitzien - Deze vereisten hebben x invloed op functionele ontwerp v/systeem zelf - Je kan beide gemakkelijk vergelijken met werking v/wagen - Deze heeft als functionele vereisten o.a. dat je bij wagen moet kunnen gas geven, remmen, richting aangeven,... - X-functionele vereisten kunnen dan vastleggen HOE je gas moet geven (met pedaal of knop op stuur), kleur v/richtingaanwijzer,... **[2.0 Use case]** - = tekstuele beschrijving v/taak voor bepaalde partij - Beschrijft gebruik (interactie tussen actor n systeem) v/systeem om bepaald doel te verwezenlijken - Hierin is ! dat alle acties die systeem moet uitvoeren om taak te realiseren duidelijk beschreven worden - Beschrijft wel alleen maar wat systeem moet doen x maar x dit moet uitvoeren - Dit is doc dat begrijpbaar moet zijn voor alle belanghebbende partijen - M.a.w. x technisch doc om communicatie met klant te vereenvoudigen - Use case zelf = contract tussen belanghebbende partijen n ontwikkelteam ***2.1 Verschillende soorten actors*** - I/use case komen versch. soorten actoren aan bod !ste = primary actor - Dit is actor die verhaal (use case) zal starten n dus als doel heeft om functionaliteit te verwezenlijken - Om dat doel te bereiken soms zijn dat hij nood heeft aan andere actor die bepaald subdoel verwezenlijkt om totale doel te bereiken - Zo actor is supporting actor - Tot slotte kunnen ook stakeholders betrokken zijn - Dit zijn actoren die zelfde doel als primaire actor wensen te bereiken maar deze nemen x actief deel aan use case zelf - Als voorbeeld kunnen we dit als volgt illustreren - Je wenst dagje aan zee te spenderen dit betekent dat jij als primary actor hebt om zee te bereiken - Hiervoor zal systeem (=auto) gebruikt om aan zee te geraken - Indien je te ver v/zee woont om met volle tank ter plaatse te geraken zal je dus onderweg moeten tanken - Pompbediende kan je dan als supporting actor zien omdat hij subdoel verwezenlijkt om jou weer op weg te krijgen door jouw tank te vullen - Supporting actor kan dan vriend(in) zijn die samen moet jou dag aan zee wou spenderen Hij/Zij gebruikt jouw auto x actief dus ondersteund jou enkel ***2.2 Hoe lezen*** - Use case bestaat uit versch. onderdelen: primary actor, supporting actor, pre- n postcondities, normaal n alt. verlopen, domeinregels n op te klaren punten - 1^ste^ 2 hebben we reeds voorgaand behandeld - Precondities = zaken die, meestal door systeem, moeten vervuld zijn alvorens verhaal kan gestart worden - Postcondities = alle zaken die door systeem moet uitgevoerd zijn als normaal verloop werd uitgevoerd - Normaal verloop, of main success story, is verhaal dat i/bijna alle gevallen kan gevold worden om doel te bereiken - Indien verhaal toch zou afwijken i/bepaalde stap komen we terecht i/bijhorende alt. verloop - Na uitvoeren v/afwijkende stappen kunnen we vanuit alt. verloop ofwel terug normale verloop vervolgen, ander alt. verloop activeren of kan use case stop gezet worden omdat we doel x meer kunnen bereiken - Domeinregels bevatten alle regels waaraan validatie v/versch. stappen of gegevens moet voldoen - Indien we toch nog x alle info v/klant hadden of sommige zaken zijn nog onduidelijk dan kunnen we dit opnemen i/op te klaren punten **[3.0 Use Case Diagram]** - Eens we alle vereisten v/klant verzameld hebben n scope bepaald hebben plaatsen we alle functionaliteiten (=use cases) die we gaan uitwerken i/use case diagram - Dit geeft overzicht v/alle functionaliteiten die op systeem gaan aanwezig zijn - Anderzijds tonen we ook alle rollen die met systeem i/interactie kunnen treden - Deze rollen komen dan later overeen met primary actor i/versch. use cases - Per rol wordt door middel v/relatie i/use case diagram ook aangeduid welke primary actor welke functionaliteiten kan uitvoeren op systeem - Dit schema kan dan ook i/mindere mate dienen als soort v/beveiligingsschema nr klant toe zodat hij ziet dat sommige rollen x foute functionaliteiten kan uitvoeren - Indien bepaalde functionaliteit bij uitvoeren v/z'n normaal verhaal altijd nood heeft aan ander verhaal dan modeleren we dit als "includes" - Oorspronkelijke functionaliteit bevat m.a.w. functionaliteit die we oproepen - Als we tijdens uitvoeren v/alt. verloop nood hebben aan extra use case dan duiden we dit aan met "extends" - Functionaliteit die we oproepen breidt m.a.w. oorspronkelijke functionaliteit uit - Aangezien dit schema dient als communicatiemiddel met klant is aangewezen om x te overdrijven met includes n extends omdat schema zo heel snel heel complex kan worden **[4.0 Activity Diagram]** - Zal zoals woord zelf zegt overzicht geven v/activiteiten die uitgevoerd worden tijdens uitvoeren v/bepaalde functionaliteit - Is dus grafische weergave v/use case normaal verloop n alle alt. verlopen worden hieri/opgenomen - Activity diagram zal enerzijds als testmiddel gebruikt worden omdat alle scenario's bevat die kunnen optreden bij uitvoeren v/bepaalde user goal - Anderzijds wordt schema ook gebruikt om te communiceren met klant omdat i/schema al gedrag vastlegt wordt dat systeem vertoond tijdens zijn werking i/chronologische volgorde ***4.1 Bouwstenen*** - Activity diagram bevat volgende elementen - Initial node: startknoop v/schema - Dit symboliseert start v/use case - Acitivity = elementaire stap uit normale of alt. verloop - Decision node: deze knoop gebruik je om beslissingswegen te modelleren - Je verzamelt verkeer voor beslissing i/1 knoop n v/hieruit vertrekt weg per versch. beslissing - Merge node: deze knoop gebruik je om versch. wegen te verzamelen zodat ze verder gaan als 1 weg - Control flow: alle activiteiten i/schema worden i/chronologische volgorde verbonden met elkaar - Activity final node = eindknoop deze komt voor als normaal verloopt stopt, maar kan ook voorkomen i/alt. verloop indien use case daar stopt - Je vermeldt hierbij telkens welke postcondities bereikt werden voor gevolgde weg ***4.2 Stappenplan*** - Activity diagram start altijd bij initial node n dus startpunt v/use case - Nadien plaats je voor elke stap uit normale verloop activiteit i/schema n verbind je deze i/chronologische volgorde met control flows - Je eindigt met final node na laatste stap v/normale verloop - Hierbij vermeld je postcondities v/use case tussen \[\] - Nadien voeg je alt. verlopen toe - Per alt. verloop zoek je stap waar deze start i/schema voeg collector node toe na activiteit die er voor zorgt dat er meerdere wegen zullen ontstaan, dien gelijkaardig verloop i/alt. weg nog x gemodelleerd werd - Voeg tussen \[\] voorwaarde toe wrm we i/deze alt. weg komen bij juiste beslissingsweg - Indien alt. leidt tot stopzetten v/use case eindigt deze opnieuw i/final node met vermelding v/postcondities - Als alt. echter leidt tot terugkeren nr stap i/normaal verloop (of ander alt. verloop) dan voeg je, indien nodig collector node toe VOOR terugkeer activiteit