S.V.M. Systeeminceptie

Fase 1 - Definitiestudie Doel: WAT wensen de gebruikers?

Activiteit 1.1 – Initialisatie van het project Projectorganisatie opzetten Projectrollen bepalen Project afbakenen Planning maken / projectbeheersing Middelen vastleggen Fasering opstellen => Plan van aanpak

Activiteit 1.2 – Detailleren functies Use-case analyse Toegevoegde waarden van systeem voor de gebruiker onderzoeken. Objectieven van de gebruiker staan central. Use-case is beschrijving van manier waarop een systeem gebruikt kan worden. Systeem zelf is black-box. Interactie met gebruiker staat centraal. => Geheel van alle use-case van een systeem is een USE-CASE MODEL

USE CASE MODEL Doelstellingen Overeenstemming over functionele eisen Richtlijn voor verder ontwerp Basis voor tests Basis bouw en uitbouw van het systeem Communicatie-instrument voor klant, ontwikkelaar, teams voor test, marketing, verkoop, ondersteuning, documentatie

Een use-case Een use-case is een beschrijving van de interactie tussen één of meer actoren en het systeem. Een use-case is een scenario, dat een doelstelling van een gebruiker met het systeem ondersteunt. Vb. Een rekening openen, een order plaatsen, een formulier invullen Met tekst of activiteitendiagram Eenvoudige tekst, voor de gebruiker begrijpbaar, Zie rational rose

Het begrip ACTOR Een actor is een entiteit die buiten het systeem staat en direct communiceert met het systeem. Een actor is een rol die iets of iemand in de context van een systeem speelt. Met tekst of activiteitendiagram Eenvoudige tekst, voor de gebruiker begrijpbaar, Zie rational rose

Het use-case diagram systeemgrens use-case actor associatie Met tekst of activiteitendiagram Eenvoudige tekst, voor de gebruiker begrijpbaar, Zie rational rose actor associatie

Use-cases stappenplan Identificeer de grenzen van het systeem en vind de actoren. Definieer use-cases voor iedere actor. Bepaal per use-case de aannamen of precondities. Bepaal per use-case de interactie. Bekijk per use-case mogelijke uitzonderingen. Beschrijf elke use case en maak het use-case diagram. Inleiding Definitie: een verzameling van door een systeem uitgevoerde sequenties, die voor een bepaalde actor een waarneembaar waardenresultaat opleveren. Waardenresultaat: communicatie, berekeningen, andere werkzaamheden. Kenmerken: Door een actor geïnitieerd. Levert een waarde voor de actor. Is compleet. Communcatie-associaties. Naam naar instantie. Is een klasse, instantie = scenario. Use-cases identificeren Vertrek van actors. Welke functies eist de actor? Wat moet de actor doen? Moet de actor iets lezen, maken, verwijderen, opslaan? Actor en events? Verbetering voor actor door nieuwe functies? Andere vragen: Welke input/output? Voornaamste problemen huidige werkwijze? Minimaal 1 actor. Use-cases in UML. Ellips met naam erin of eronder. Relaties tussen use-cases Extends-relatie: generalisatie door toevoegen uitbreidende use-case Uses-relatie: generalisatie waarin ee use-case een andere gebruikt Groepering: bundelen in UML-package

De beschrijving van use-cases Scenario = instantie Testen op volledigheid: Alle actors een communicatierelatie? Mogelijk basisklasseactor Uses-relatie? Nog functionele vereisten die niet worden gedekt?

Use-cases in UML

Het testen van use-cases Validatie door gebruiker Verificatie in verdere analyse « Walking the use case » Verificatie: correct en volgens specificaties ontwikkeld? Validatie: systeem in ontwikkeling voldoet aan behoeften? Walking the use-case: rollenspel.

Use-case valkuilen

Oefening - frisdrankautomaat

Use case oefeningen – achtergrond Use-cases = excellent tool om potentiële gebruikers te stimuleren om vanuit hun standpunt over een systeem te laten vertellen. Achtergrond = gebruikers in het vroegste stadium bij systeem-ontwikkeling betrekken om zo de kans te verhogen dat het systeem uiteindelijk ook levert wat gebruikers wensen.

Oefening – Peru-aid Peru-aid is een non-profit organisatie die giften verzamelt van particulieren. Verzamelde giften worden geattesteerd om ze fiscaal aftrekbaar te maken voor de gever. Peru-aid omvat meerdere projecten. Giften worden geheel of gedeeltelijk aan specifieke projecten gegeven. De enige voorwaarde is dat de totale som van alle giften voor een project niet groter mag zijn dan het projectbudget. Voor elke gift aan een project krijgt de gever een bedankbrief. Zo’n bedankbrief mag uiteraard maar één keer verstuurd worden voor elke gift. Gevers, giften en projecten worden gearchiveerd zoals het hoort. Giften mogen maar één keer geattesteerd worden. Wanneer giften een specifiek project dienen, worden deze projecten op het fiscaal attest vermeld.

Oefening – Easyshop (achtergrond) Hans en Jacqueline gaan samenwonen. Ze hebben een verdieping van een Brussels pand kunnen kopen, omdat ze beide goed verdienen. Jacqueline is piloot bij een luchtvaartmaatschappij en vliegt vanaf Zaventem. Hans is arts in een universitair ziekenhuis in Brussel. Beiden hebben vanwege hun werk een zeer wisselend weekschema. Ze voorzien dat er hierdoor problemen zullen ontstaan met het doen van inkopen voor de dagelijkse maaltijd. Daarom willen ze een computersysteem laten maken dat draait op hun nieuwste aanwinst: een supersnelle PC. Ze hebben zelfs al een naam voor het systeem bedacht. Het gaat EasyShop heten.

Oefening – Easyshop (functionele eisen) De informatici die het systeem zullen bouwen komen een avond praten over hoe het eruit moeten komen te zien. Globaal komt het hierop neer: Hans en Jacqueline moeten onafhankelijk van elkaar het systeem kunnen gebruiken. Ze willen per week een scherm zien waarop ze kunnen aangeven of ze wel of niet aanwezig zijn bij het diner, lunch en/of ontbijt. Bovendien moet aangegeven kunnen worden of er gasten verwacht worden. Het is de bedoeling dat elke huisgenoot alleen voor zichzelf de agenda invult. Per dag wordt bovendien aangegeven wie er kookt. Deze persoon zal uit een aantal recepten kiezen wat er die dag gegeten wordt. Op basis van de gegeven recepten plus informatie over de meest geprefereerde lunch en ontbijt van zowel Hans als Jacqueline zal het systeem één keer per week een boodschappenlijst maken. Hans of Jacqueline zal deze actie aangeven want aanwezigheid van een van hen is vereist voor de bezorging. Op dagen die niet ingevuld zijn, wordt geacht dat er niemand aanwezig zal zijn. Deze boodschappenlijst zal per fax naar de lokale supermarkt gestuurd worden waarna de supermarkt de gevraagde boodschappen thuisbrengt (tussen 17.00 en 18.00 u.). Het systeem bewaart een lijst met faxnummers van lokale supermarkten met een bezorgdienst. De gebruiker zal uit deze lijst kunnen kiezen. Het systeem zal de voorraad van het huishouden bijhouden. Wanneer de boodschappen bezorgd worden zal de gebruiker deze met de juiste hoeveelheden invoeren in het systeem. Wanneer een dag verstreken is dan gaat het systeem ervan uit dat de maaltijden die dag genuttigd zijn. Hans en Jacqueline zijn allebei geen ster in de keuken, daarom willen ze een kookboek met een groot aantal eenvoudige recepten in het systeem onderbrengen. Dit kookboek moet onafhankelijk van de agenda in te zien zijn, bijv. op het moment dat gekookt moet worden.

Oefening – Easyshop (niet-functionele eisen) De systeemeisen die Hans en Jacqueline stellen zijn de volgende: 1. Het systeem moet werken op een PC. 2. Het systeem moet een faxverbinding mogelijk maken met minstens één supermarkt. 3. De beide gebruikers moeten onafhankelijk van elkaar van het systeem gebruik kunnen maken, maar ze hoeven er niet beide tegelijkertijd mee te werken. 4. Het systeem moet een grafische userinterface hebben.

Oplossing – Frisdrankautomaat De “koop frisdrank” use-case Scenario: Klant steekt geld in automaat Klant maakt selectie Machine levert geselecteerde drank Klant neemt blikje uit toestel Precondities (aannamen) Dorstige klant Postcondities (resultaat) Klant heeft blikje gekregen Dit is slechts één scenario! Je kan onmiddellijk andere bedenken en de use-case opnieuw “beleven”.