Specificatieproces

Download Report

Transcript Specificatieproces

Specificatiefase
Training
Versie 0.2, laatste update 2009/04/01 MS
Inhoud
1. Introductie
2. Specificatieproces
3. Specificatiedocument
4. Requirements
5. Use Cases
Introductie
Introductie
Projecten..
Introductie
Projecten… succesvol volbrengen start bij goede specificaties!
Goede set specificaties zorgt voor:
 overeenstemming tussen opdrachtgever en leverancier over het beoogde systeem
 een gezamenlijke visie is over het project bij alle stakeholders
 een gedegen basis is voor schattingen en planningen
 een soepeler verloop van de bouw van de applicatie
Immers: Garbage In…
Garbage Out!
Introductie
• Het opstellen van specificaties is niet louter een zaak van de consultant of leverancier:
• dit is een gezamenlijk proces waarin alle stakeholders bij moeten worden betrokken –
dus niet alleen de ICT!
Specificatie
Bouw
Test
Beheer
•Het opstellen van juiste specificaties bepaalt in hoge mate het succes van het project
Introductie
• De Wet de Boehm:
• Fouten en verkeerde aannamen bij start van het project hebben een progressieve
impact op de ‘technical debt‘. Maw: dit resulteert in een verlies in geld en/of tijd in latere
fasen.
Introductie
• Technical debt
• In short het verschil tussen (werkelijke) technische voortgang en de voortgang in budget
en planning.
Verminderen fouten en
onduidelijkheden
Sturing door PL
Specificatieproces
Specificatieproces
Doel
 Weet iedereen wat er wordt gebouwd?
 Weet iedereen waarom het wordt gebouwd?
 Is iedereen het eens over hoe het wordt gebouwd?
Specificatieproces
• De rol van de consultant
Business
Opdrachtgever
(vertegenwoordiging)
Account
Manager
Gebruikers
(vertegenwoordiging)
Project
Manager
Klant
Medewerkers
Overige
stakeholders
Ontwikkelaars
en testers
Specificatieproces
Algemeen
Specificatie
Requirements
Ontwerp
Gedetailleerd
‘Twin Peaks’ model (Nuseibeh 2001)
Specificatieproces
Verdieping
Nieuwe informatie
Inventarisatie
input
Specificaties
en hyaten
Verduidelijken
Controle
Analyse
Opnieuw beoordelen
Corrigeren
requirements
specificaties
Specificatie
Specificatieproces
Programma
van eisen
Requirements
Doelstellingen
Business
Businessrules
documenten
Kwaliteitseisen
Beperkingen
Gebruiker
Specificatie
Document(en)
Ontwerp
GO!
Systeem
Interviews
en meetings
Inventarisatie
Analyse
Specificatie
Controle
Requirements
Requirements
businessrule
prioriteit
eis
doel
wens
afhankelijkheid
Applicatie
doelstelling
categorie
behoefte
bron
betrokkenen
beperking
Requirements
Voorbeeld
138 - De website dient snel de lijst met
records aan de gebruiker te tonen.
138a – De website toont onder menu x
de lijst met records aan de gebruiker in
het hoofdscherm
138b De lijst wordt binnen 10 seconden
(marge: 5 sec) aangeboden
‘Functionals’
138c – Per record wordt de naam, datum
en nummer getoond
138d – De lijst is gebruiksvriendelijk
138e – De lijst is onderhoudbaar
138f – De gegevens zijn alleen
wijzigbaar door de beheerder
‘Non-Functionals’
Specificaties
Projectdefinitie
Projectplan
(PM)
(Visie, scope, relaties, uitsluitingen etc)
(Functionaliteiten, Businessrules,
gegevensstromen)
Requirements
Requirements doc.
(Product Beschrijvingen)
Architectuur & Infrastructuur
(PBS, PFD, HLA, globaal ERD,
standaarden en technieken)
Use Case Specificaties
Specificatiedocument
Functionele Analyse
Technisch Ontwerp
(LD)
Visual
Design
Mockup
Specificaties
• Specificatiedocument
• - projectdefinitie (businesscase, scope, relaties, aannamen etc)
• - functionele analyse (functionaliteiten, infra- en architectuur, standaarden en
technieken)
• - Requirements (lijst, document, businessrules)
• - overzicht Use Case Model (UC Specificaties, actoren, top UML)
• - overzicht globaal gegevensmodel (top ERD, )
• - overzicht tracering
• Verklarende Woordenlijst
Use Case Model
• Use Case Specificaties
• Specificeert een doel van een gebruiker in het systeem via een stappenplan:
• 1. Definieer het doel en de actoren
• 2. Definieer de samenvatting van de Use Case
• 3. Definieer het hoofdscenario (succes) en de gegevensstroom
• 4. Definieer alternatieve scenario’s (succes) en de foutscenario’s (falen)
• 5. Verder neem je ook op:
• - Traceringsmatrix en de relevante businessrules
• - Relevante informatiemodel (gebruikte entiteiten)
• - Functionele testen
• 6. Dynamisch gedeelte:
• - openstaande vragen  ontwerpbeslissingen  ontwerpkeuzes
Use Case Model
• Use Case Specificaties ontwikkelen
• 1. ‘blanco’ use case naar klant
 inleiding, samenvatting actoren en doel
 Feedback van de klant mbt successcenario
• 2. Uitbreiden Use Case
 opstellen hoofdscenario
 opstellen gegevensstroom
 bepalen waar een alternatief of foutscenario mogelijk is
 bepalen beperkingen en regels (bussinessrules)
 vaststellen onduidelijkheden en conflicten (openstaande vragen en beslissingen)
3. Controle van Use Case
 validatie door klant / in vergadering
 wijzigingen en correcties doorvoeren
 validatie door klant / in vergadering
 maken van ontwerpkeuzes
• 4. Overige zaken bijvoegen
 gegevensstroom
 traceringsmatrix