bedrijfsprocessen en vormt daarmee de kapstok voor de producten van andere disciplines. Het PAM is geen RUP concept.

Transcriptie

1 Inleiding Doel De Requirementdiscipline richt zich op het vaststellen en vastleggen van de eisen en wensen die aan een oplossing worden gesteld: de requirements. Rollen De keyrol binnen deze discipline is de System Analist 1. De System Analist is verantwoordelijk voor het vaststellen van de eisen en wensen en het vertalen van deze eisen en wensen in specificaties voor de realiseren oplossing. Deze specificaties worden vastgelegd in een Software Set (SRS). De System Analist wordt hierbij ondersteund door de User Interface Designer die de specificaties ten aanzien van de User Interface uitwerkt. Belangrijke reviewers binnen het projectteam voor de System Analist zijn de Project Architect en de Test Analist. Aanpak De System Analist werkt de specificaties op hoofdlijnen uit in een Use Case Model, waarbij gebruik wordt gemaakt van het Proces Architectuur Model (PAM) 2, waarin de processen en activiteiten zijn weergegeven. De geïdentificeerde Use Cases worden vervolgens verder uitgewerkt in Use Case Specifications en Supplementary Specifications. In de Supplementary Specifications worden algemene specificaties vastgelegd die geldig zijn voor meerdere Use Cases en niet functionele specificaties. Parallel aan het optellen en uitwerken van het Use Case Model door de System Analist werkt de User Interface Designer de specificaties van de User Interface verder uit. Op niveau van het Use Case Model wordt dit vastgelegd in Storyboards en op het niveau van de Use Case Specifications in User Interface Specifications. Het Use Case Model, de Use Case Specifications en de Supplementary Specifications vormen tezamen met de User Inter Specifications de System Set (SRS). Storyboards vormen geen onderdeel van de SRS maar zijn een middel om tot de User Interface Specifications te komen en blijken in de praktijk zeer bruikbaar als basis voor discussie. Diepgang De betrokkenheid van de System Analist begint al in een vroegtijdig stadium (Conception fase) met het vaststellen van het probleem, stakeholders, scope en de belangrijkste eisen en wensen. Deze zaken worden de Conception fase in een concept Vision beschreven. Tijdens de planvorming (Inception fase) vindt de uitwerking van de concept Vision plaats. Dit betekent dat het probleem, de stakeholders, scope en eisen en wensen definitief worden vastgesteld. Tevens moet tijdens de planvorming benoemd zijn welke functionele risico s op welke wijze worden uitgewerkt in de Elaboration-fase. Tijdens de uitwerking en risico-eliminatie (Elaboration) worden de Use Cases zover uitgewerkt dat een risicovrije constructie mogelijk is. Dit betekent dat de Use Cases tot het niveau 'Functioneel Ontwerp zijn uitgewerkt. Tijdens de realisatie (Construction) en uitrolfase (Transition) beperkt de inzet van de System Analist zich uitsluitend tot scopebewaking (RfC procedure) en het actualiseren van de Use Cases. Belangrijk is dat met name in de eerste fasen voldoende tijd voor de System Analist wordt ingepland zodat de requirements volledig kunnen worden uitgewerkt. 1 Ook wel Business Proces Analist, Business Analist, e.d. genoemd 2 Het PAM wordt opgesteld door de Business Process Analist en wordt gebruikt als houvast voor de decompositie van bedrijfsprocessen en vormt daarmee de kapstok voor de producten van andere disciplines. Het PAM is geen RUP concept. Infocon Versie 0.1 Pagina 1 van 8

2 1.2. Rollen Wat doet de System Analist De System Analist is verantwoordelijk voor het vaststellen en vastleggen van requirements, maar ook voor het zorgdragen voor de juiste beeldvorming en het creëren van draagvlak. De System Analist heeft met name ook een communicatierol waarin beelden in de omgeving worden neergezet. Taken System Analist De activiteiten voor de System Analist zijn voor de Conception- en Inception-fase weergegeven in hoofdstuk 2 Activiteiten in Conception fase resp. hoofdstuk 3 Activiteiten in Inception fase 1.3. Samenhang begrippen Centraal in de discipline staat de focus op het probleem en niet op de oplossing. Op basis van het geconstateerde probleem worden de needs, features en requirements (doel-middelen hiërarchie) vastgesteld. Deze zaken worden vastgelegd in de deliverables Vision en SRS. Probleem versus oplossing De requirementsdiscipline richt zich nadrukkelijk op het op het lossen probleem en de eisen/wensen aan de oplossing en niet de oplossing zelf. Om gefundeerde requirements op te stellen is eerst een gedegen analyse van het probleem noodzakelijk ("Wat is het echte probleem waarvoor een oplossing moet worden gezocht?"). Infocon Versie 0.1 Pagina 2 van 8

3 Vervolgens is een gemeenschappelijke visie nodig voor alle belanghebbenden, waarin zowel het probleem als het systeem worden geschetst. Doel-middelen hiërarchie De requirement statements vormen een doel-middelen hiërarchie. Op het hoogste niveau onderkennen we de behoeften van de belanghebbenden (stakeholder needs). Deze business needs worden elk ingevuld door één of meer kenmerken die het systeem moet bieden (system features). De system features worden gerealiseerd in benoemde Use Cases en concreet gemaakt door een set aan detaileisen die aan betreffende Use Cases worden gesteld. Hiermee ontstaat een doel-middelen hiërarchie. Eisen en wensen die op detailniveau worden gesteld zijn herleidbaar tot features en needs. Indien dit niet het geval is, betekent dit dat er nog niet onderkende needs en features zijn die leiden tot een verschuiving in de scope (ofwel scope creep) of dat de detailrequirements die niet tot de scope behoren of niet bijdragen aan de doelen en dus kritisch moeten worden bekeken. Samenhang deliverables Binnen deze discipline spelen de volgende deliverables een belangrijke rol: Vision. Dit document is bedoeld voor beeldvorming en scope en vormt de onderbouwing van planvorming (PlD). De Vision bevat de volgende onderwerpen: probleem, needs, features, stakeholders, scope/omvang en oplossingsrichting (vanuit Anlysis&Design-discipline). Daarnaast wordt ook het visueel concept (de User lnterface op hoofdlijnen) vastgelegd. SRS (System Set), bestaande uit Use Case Model, Use Case Specifications en Supplementary Specifications. De SRS vormt in wezen het contract tussen gebruikers en project en vormt de baseline voor de bouwers. Binnen de SRS worden ook de specificalies van de User Interface vastgelegd. vastlegging Levensloop van de Use Case Use Case is geïdentificeerd en benoemd: de Use Cases zijn opgenomen in het Use Case Model en voorzien van korte omschrijving. Infocon Versie 0.1 Pagina 3 van 8

4 Use Case is globaal beschreven: outlined en alle alternate flows benoemd. Hiermee zijn de Use Case Scenario's geïdentificeerd. Use Case is in detail beschreven: alle flows zijn nader gedetailleerd, de pre-post conditions zijn beschreven, etc. De gedetailleerde beschrijving van de Use Cases is opgenomen in de Use Case Specifications. Use Case Model Dit is het context diagram van het systeem en nodig voor de afbakening van de scope. Het Use Case Model is een model van de functies van het systeem in de context van de omgeving die het systeem gebruikt. Als input wordt hiervoor het PAM model (Business Modeling) gebruikt, hierin zijn de onderkende activiteiten en te realiseren services weergegeven. Use Case Scenario s Use Case Scenario's worden geïdentificeerd door alle flows in samenhang te benoemen. De relevante paden worden in Use Case Scenario's benoemd en vormen tevens de basis voor test. De Use Case Scenario's worden gereviewd vanuit de Test-discipline. Parallel werkt de Test-discipline de scenario's uit in Test Scenario's. Deze Test Scenario's vormen een toets op de juistheid/correctheid van de Use Case-beschrijvingen. In de praktijk roept de review vanuit test vragen/opmerkingen op die helpen de Use Case Specifications consistent en compleet te maken. Use Case Specifications De Use Cases uit het Use Case Model worden in detail beschreven in Use Case Specifications, zodat deze door de Ontwikkelaar eenduidig kunnen worden geïnterpreteerd. In de specificotions wordt aandacht besteed aan de aanwezige velden, validaties, handelingen, etc. Algemene (niet-functionele) of Use Case overstijgende specificaties worden vastgelegd in de Supplementary Specifications. De Use Case Specifications worden gereviewd vanuit de Analysis&Design-discipline. Parallel werkt Analysis&Design de specificaties verder uit in Use Case Realizations. Deze vormen een toets op de juistheid/correctheid van de Use Case Specifications. In de praktijk roept de review vanuit Analysis&Design vragen/opmerkingen op die helpen de Use Case Specifications consistent en compleet te maken. Use Case Realizations Use Case Realizations zijn de vertaling van de interactie zoals beschreven in de flows van een Use Case (blackbox) naar welke interactie daarvoor binnen het systeem tussen de componenten moet plaatsvinden (whitebox). Deze worden opgesteld vanuit de Analysis&Design-discipline en vormen een toets van de specificaties aan de architectuur (SAD). De Use Case Realizations zijn opgenomen in het Analysis Model. Binnen de Analysis&Design-discipline wordt het Analysis Model verder gedetailleerd in het Design Model. User Interface Design De User Interface wordt op drie niveaus beschreven: op het niveau van de Vision wordt een visueel concept van de User Interface gemaakt ter ondersteuning van de beeldvorming; op het niveau van het Use Case Model worden Storyboards gemaakt; op het niveau van de Use Case Specifications worden User Interface Specifications gemaakt. Hierin zijn de visuele aspecten van de User Interface in detail beschreven. Visueel Concept en Storyboards zijn hulpmiddelen om te komen tot (User Interface) specificaties en maken formeel geen deel uit van de System Requirement Set (SRS). Toch bieden de visualisaties vaak ook na vaststelling van de specificaties toegevoegde waarde in discussies. Echter, planmatig zijn alleen afspraken vastgelegd in de SRS leidend voor het project. Situationeel zal een afweging worden gemaakt tussen deze toegevoegde waarde en dubbel onderhoud om visueel concept en/of Storyboards in lijn te houden met de (User Interface) specificaties. Aandachtspunt hierbij is ook hoe om te gaan met User Interface Specifications in het beheer. Als uitgangspunt is de actuele versie van het systeem leidend. Onderhoud op specificaties kan worden beperkt door een Infocon Versie 0.1 Pagina 4 van 8

5 scheiding te hanteren tussen User Interface Specifications en Use Case Specifications en uitsluitend de Use Case Specifications samen met het systeem over te dragen als systeemdocumentatie voor beheer. Immers de User Interface van het gerealiseerde systeem is altijd actueel Aanpak en diepgang De System Analist start in de Conception-fase met het analyseren van het probleem en het in kaart brengen van de needs die de stakeholders hebben. Op basis van deze needs worden de eisen en wensen (features) die aan de oplossing worden gesteld vastgesteld, waarmee tevens de scope van het te realiseren systeem helder wordt. Aanpak requirements Deze zaken worden tezamen met een beschrijving van de oplossingsrichting (Analysis&Design-discipline) in een concept Vision vastgelegd en vormen input voor de Project Brief. Naast het opstellen van de Vision wordt in de Conception-fase ook het Use Case Model opgesteld, waarin alle geïdentificeerde Use Cases benoemd en kort worden toegelicht. Parallel aan het opstellen van het Use Case Model wordt het (visuele) concept uitgewerkt. De concept Vision wordt in de Inception-fase verder uitgewerkt en vastgesteld (baseline). Tevens wordt het Use Case Model verder uitgewerkt waarbij aan het einde van de Inception-fase de volgende zaken zijn gerealiseerd: voor alle Use Cases uit het Use Case Model is een step-by-step outline opgesteld; alle Use Case Scenario's zijn benoemd. Deze scenario s vormen veelal de basis voor de planning en zijn derhalve een belangrijke input voor het PlD. Belangrijk is hierbij ook dat de scenario s worden gereviewd door de Test discipline, die op basis van hiervan tevens de Test Scenario's kon opstellen; de kritische/complexe Use Cases zijn verder uitgewerkt in Use Case Specifications ten behoeve van schatting en planning. Bij het vaststellen van de kritische Use Case speelt met name de complexiteit een rol. De complexiteit wordt bepaald door een aantal criteria. Een eerste criterium is technologisch van aard (nieuwe technologie waar nog geen ervaring mee is opgedaan, oplossingsrichting waarvan de Project Architect aangeeft dat dit complex is). Andere criteria zijn testbaarheid, gebruik van meerdere platforms, betrokkenheid van meerdere organisatie-onderdelen, betrokkenheid van externe partijen, aantal interfaces. Deze uitgewerkte Use Cases kunnen met name bij het realiseren van het Proof of Concept worden gebruikt. Naast het uitwerken van de Use Cases worden Storyboards gemaakt voor alle kritische Use Cases. In de Elaboration-fase worden alle Use Cases uitgewerkt in Use Case Specifications, waarbij geldt dat alle velden, validaties/controles en handelingen zijn beschreven. Het detailniveau van de Use Case Specifications is zodanig Infocon Versie 0.1 Pagina 5 van 8

6 dat deze niet voor meerdere uitleg vatbaar zijn. Hierbij geldt als richtlijn de 80/20-regel. Dit houdt in dat wel alle Use Cases (100%) uitgewerkt zijn, maar dat de diepgang geen 100% hoeft te zijn. Bepaalde formules kunnen bijvoorbeeld tijdens de Construction-fase nader worden uitgewerkt. Belangrijk is dat de ontbrekende specificaties geen risico's (bijvoorbeeld impact op planning) meer met zich meebrengen aangezien de focus van de elaboration risico eliminatie is en de construction 'risico-vrij' moet kunnen worden uitgevoerd. Tijdens de Construction-fase zal de focus van de System Analist met name gericht zijn op het managen van de scope en het strikt hanteren van de RFC-procedure, als er wijzigingen op de scope zijn. Daarnaast zal de System Analist de nog ontbrekende specificaties uitwerken. Verder zal de System Analist de bevindingen die uit test komen analyseren. Ook in de Transition-fase is de focus van de System Analist met name gericht op het managen van de scope. Daarnaast zal de System Analist ook betrokken zijn bij de overdracht aan de beheerorganisatie, waarbij de System Analist zich met name richt op het overdrogen van de documentatie (SRS). Voor zowel deze als de vorige (Construction-)fase geldt dat de betrokkenheid van de System Analist niet fulltime zal zijn. Een vuistregel is dat de betrokkenheid 10-20% bedraagt van de tijd die tijdens Elaboration is besteed. Infocon Versie 0.1 Pagina 6 van 8

7 2. Activiteiten in Conception fase Tijdens deze fase houdt de zich bezig met de beantwoording van de onderstaande vraagstellingen. De antwoorden worden vastgelegd in de weergegeven documenten, waarbij is aangegeven of het een baseline of een concept betreft. Een baseline product wordt formeel vastgesteld. Vraagstelling Toelichting Verantwoordelijke Betrokkenen Vorm/Document Status Welk probleem moet er worden opgelost? Door het probleem te concretiseren wordt enerzijds een gemeenschappelijke en gedragen probleemstelling vastgesteld, anderzijds wordt de focus voor het project geconcretiseerd Managers, Specialisten, Problem statement in Baseline Bedrijfsbrede architecten Vision document Wie hebben er belang bij de oplossing? Inventarisatie van stakeholders en hun belangen Managers, Bedrijfsbrede architecten Stakeholder tabel in Vision document Schets Wat willen de belanghebbenden (stakeholders) op hoofdlijnen Vanuit de businessdoelen (goals) zijn behoeften (needs) en kenmerken (features) waaraan het systeem moet voldoen vast te stellen Managers, Bedrijfsbrede Needs & Features tabel Schets architecten in Vision document Hoe ziet het visuele concept eruit? Eerst indruk van de interactie tussen gebruikers en systeem ondersteund door Project team, Visueel concept Schets User Interface Designer Specialisten Wanneer is de oplossing akkoord, ofwel wat zijn de acceptatiecriteria op hoofdlijnen? Vooraf te bepalen (toetsbare) criteria op basis waarvan het projectteam de oplossing gaat uitwerken en op basis waarvan aan het einde het projectresultaat kan worden getoetst Managers, Specialisten, Bedrijfs-brede Architecten Project Brief, detaillering in Vision (eventueel PAP 3 ), Baseline (Project Brief) Schets (Vision) 3 Product Acceptatie Plan Infocon Versie 0.1 Pagina 7 van 8

8 3. Activiteiten in Inception fase Tijdens deze fase houdt de zich bezig met de beantwoording van de onderstaande vraagstellingen. De antwoorden worden vastgelegd in de weergegeven documenten, waarbij is aangegeven of het een baseline of een concept betreft. Een baseline product wordt formeel vastgesteld. Vraagstelling Toelichting Verantwoordelijke Betrokkenen Vorm/Document Status Welk probleem moet er opgelost worden? Mogelijke wijzigingen in de probleemstelling worden formeel vastgelegd Managers, Specialisten, Problem statement in Baseline Bedrijfsbrede architecten Vision document Wie hebben welke belangen bij de oplossing? In deze fase is het van belang om naast de belanghebbenden ook hun rol en hun (verschillende) belangen gedetailleerd in beeld te brengen Managers, Bedrijfsbrede Stakeholder table in Baseline architecten Vision document Wat willen de belanghebbenden (stakeholders) in detail? Vanuit de business doelen (goals) zijn behoeften (needs) en kenmerken (features) waaraan het systeem moet voldoen vast te stellen Managers, Bedrijfsbrede Needs & Features tabel Baseline architecten in Vision document Wat zijn de specificaties voor de meest cruciale onderdelen van het systeem? Beschrijving van de belangrijkste functionaliteit. Deze dient ter uitwerking van de beeldvorming en scope en vormt een belangrijke basis voor het schatten van de omvang. Uitwerking vindt plaats door uitwerking van alle Use Cases op hoofdlijnen en significante Use Cases in meer detail. Uitwerking is gericht op het afdoende bepalen van complexiteit en omvang alsook het voorbereiden van uitwerkingen ten behoeve van risico eliminatie in de volgende fase Project team, Specificaties (System Baseline Specialisten Requirement Set) Hoe vindt de interactie met de gebruiker plaats? Visueel ontwerp van de interactie. Deze maakt onderdeel uit van de specificaties en dient in deze versie net als de significante Use Cases ter uitwerking van de scope en beeldvorming en vormt een belangrijke basis voor het schatten van de omvang ondersteund door Projectteam, Specialisten Storyboards Baseline User Interface Designer Wanneer is de oplossing akkoord, ofwel wat zijn de acceptatiecriteria? De acceptatiecriteria worden meetbaar gemaakt (SMART) Managers, Specialisten, Bedrijfs-brede Architecten PAP, desgewenst opgenomen in PID, hoofdlijnen vastgelegd in Vision Baseline Hoe ziet de acceptatiestrategie eruit? Vanuit de overall aanpak is een aantal specifieke onderdelen onderkend waarvoor expliciet gekeken wordt naar de te hanteren strategie als input voor de gehele projectaanpak. Op basis van de eerste beelden over aanpak/uitrol, projectresultaten en acceptatiecriteria wordt een teststrategie met bijbehorende planningsconsequenties vastgesteld Projectmanager i.s.m. Project team, Specialisten PID, desgewenst detaillering in PAP Baseline Infocon Versie 0.1 Pagina 8 van 8