Software engineering
samenvatting P2
Inhoud
Functionele analyse: situering en soorten..............................................................................................2
Situering.............................................................................................................................................2
Requirement Analyse – Behoeften Analyse........................................................................................2
Requirement Analyse -Technieken.....................................................................................................6
Systeem Use Case...............................................................................................................................7
Use case 1.......................................................................................................................................7
Use case 2.......................................................................................................................................9
Use case 3.....................................................................................................................................11
Use case diagram..............................................................................................................................12
Voorbeelden.....................................................................................................................................16
Pagina 1 van 17
,Functionele analyse: situering en soorten
Gegevens analyse -> functionele analyse
o Gegevens: focussen op data
Data = doel om ergens gebruikt te worden
Overbodige data = niet opnemen in gegevensanalyse
o Functioneel: focussen op wat we gaan doen
o De twee samen bekijken en het één beslist of dat we iets van het ander nodig
hebben
Ze hebben invloed op elkaar, hangen van elkaar af
Use-cases
o = beschrijving van wat we gaan doen
Situering
In periode 2
(conceptueel) Klassediagram = domeinmodel
> Objectdiagram moest ergens een klassediagram tonen om te weten welke objecten en
afhankelijkheden van objecten daarin gebruikt moesten worden
Klassediagrammen + objectdiagrammen
o = structuurdiagrammen
Gedragsdiagram
o Gaat alle use-cases groeperen in die opdracht
Gaan zeggen wat er allemaal gebeurt
=> overzicht van hoe het geheel er gaat uitzien
Requirement Analyse – Behoeften Analyse
Requirement (behoefte)
o = datgene waar een systeem/project aan moet voldoen
o Dit wordt bepaald door een opdrachtgever
o Evolutionaire behoefte
behoeften die onderhevig zijn aan wijzigingen tijdens het ontwikkelproces
Gaat evolueren, de opdrachtgever kan van gedachte veranderen
Pagina 2 van 17
, Dit kan door de korte iteraties (agile), flexibel zijn
o Vertellen wat het te ontwikkelen systeem moet kunnen en geven aan wat de eisen
en de behoeften aan geautomatiseerde ondersteuning van de belanghebbenden uit
de business zijn
o Hebben een brugfunctie tussen de belanghebbenden uit de business en het
softwareontwikkelteam
Kijken naar alle mogelijke soorten behoeften/requirements
o Dit doen we voor we de use-cases starten
o Om zeker te zijn dat we geen requirements gaan modelleren die niet noodzakelijk
zijn voor de use-cases
Brugfunctie van Requirements
Requirement types:
o FURPS+
o Onderscheid tussen functionaliteit en n-functionaliteit is zeer belangrijk
o Functionaliteit: features, kenmerken, mogelijkheden, wat moet dat systeem kunnen
o Bruikbaarheid: meestal menselijke factoren behandelen, de bruikbaarheid, de
aantrekkelijkheid, … (= vorm)
o Betrouwbaarheid: bedrijfszekerheid, foutbestendigheid, herstelbaarheid, …
Gaan wij niet bekijken want dat heeft ook de data niet nodig die wij hebben
bekeken in periode 1
Pagina 3 van 17
samenvatting P2
Inhoud
Functionele analyse: situering en soorten..............................................................................................2
Situering.............................................................................................................................................2
Requirement Analyse – Behoeften Analyse........................................................................................2
Requirement Analyse -Technieken.....................................................................................................6
Systeem Use Case...............................................................................................................................7
Use case 1.......................................................................................................................................7
Use case 2.......................................................................................................................................9
Use case 3.....................................................................................................................................11
Use case diagram..............................................................................................................................12
Voorbeelden.....................................................................................................................................16
Pagina 1 van 17
,Functionele analyse: situering en soorten
Gegevens analyse -> functionele analyse
o Gegevens: focussen op data
Data = doel om ergens gebruikt te worden
Overbodige data = niet opnemen in gegevensanalyse
o Functioneel: focussen op wat we gaan doen
o De twee samen bekijken en het één beslist of dat we iets van het ander nodig
hebben
Ze hebben invloed op elkaar, hangen van elkaar af
Use-cases
o = beschrijving van wat we gaan doen
Situering
In periode 2
(conceptueel) Klassediagram = domeinmodel
> Objectdiagram moest ergens een klassediagram tonen om te weten welke objecten en
afhankelijkheden van objecten daarin gebruikt moesten worden
Klassediagrammen + objectdiagrammen
o = structuurdiagrammen
Gedragsdiagram
o Gaat alle use-cases groeperen in die opdracht
Gaan zeggen wat er allemaal gebeurt
=> overzicht van hoe het geheel er gaat uitzien
Requirement Analyse – Behoeften Analyse
Requirement (behoefte)
o = datgene waar een systeem/project aan moet voldoen
o Dit wordt bepaald door een opdrachtgever
o Evolutionaire behoefte
behoeften die onderhevig zijn aan wijzigingen tijdens het ontwikkelproces
Gaat evolueren, de opdrachtgever kan van gedachte veranderen
Pagina 2 van 17
, Dit kan door de korte iteraties (agile), flexibel zijn
o Vertellen wat het te ontwikkelen systeem moet kunnen en geven aan wat de eisen
en de behoeften aan geautomatiseerde ondersteuning van de belanghebbenden uit
de business zijn
o Hebben een brugfunctie tussen de belanghebbenden uit de business en het
softwareontwikkelteam
Kijken naar alle mogelijke soorten behoeften/requirements
o Dit doen we voor we de use-cases starten
o Om zeker te zijn dat we geen requirements gaan modelleren die niet noodzakelijk
zijn voor de use-cases
Brugfunctie van Requirements
Requirement types:
o FURPS+
o Onderscheid tussen functionaliteit en n-functionaliteit is zeer belangrijk
o Functionaliteit: features, kenmerken, mogelijkheden, wat moet dat systeem kunnen
o Bruikbaarheid: meestal menselijke factoren behandelen, de bruikbaarheid, de
aantrekkelijkheid, … (= vorm)
o Betrouwbaarheid: bedrijfszekerheid, foutbestendigheid, herstelbaarheid, …
Gaan wij niet bekijken want dat heeft ook de data niet nodig die wij hebben
bekeken in periode 1
Pagina 3 van 17
