Velkommen til Kravspecifikation i Softwareudvikling Workshop hos 14. september 2012, 9.30 12.30 Flemming Hansen, IT innovation e-mail: flemming.hansen@it-innovation.dk Kravspecifikation i softwareudvikling, side 0
Agenda 9.30 12.30 Introduktion til Kravspecifikations aktiviteten Kravspecifikation med Use Case Identifikation og beskrivelse af Use Case Metodetrin for kravspecifikation Pause Workflow analyse sammenhæng imellem Use Case Kravspecifikations dokumentet Anvendelse af Kravspecifikationer og Use Case i en System udviklings process Kravspecifikation i softwareudvikling, side 1
Hvorfor kravspecifikation? Er ofte et aftalegrundlag mellem kunde/marketing og udvikler Definerer mål og forventninger til projektet Danner grundlag for: estimering og resurseallokering den videre systemudvikling udarbejdelse af en accepttestspecifikation Beskriver hvad og ikke hvordan Er et fundament for senere udvidelser og ændringer Kravspecifikation i softwareudvikling, side 2
Den gode kravspecifikation er: Entydig Fuldstændig Konsistent Korrekt Testbar Modificerbar Sporbar Kravspecifikation i softwareudvikling, side 3
Indhold i en Kravspecifikation En kravspecifikation indeholder: En generel introduktion til det system eller det produkt, der ønskes udviklet De funktionelle krav til systemets eller produktets virkemåde De ikke funktionelle krav, der beskriver generelle krav som systemet skal leve op til Kan i nogle tilfælde også indeholde krav til selve udviklingsforløbet alternativt er disse beskrevet i et selvstændigt dokument det er ofte fornuftigt at adskille produkt fra proces Et krav er en egenskab som et produkt må have for at give værdi for en interessent. Kravspecifikation i softwareudvikling, side 4
Funktionelle og ikke funktionelle krav Eksempler på funktionelle krav: AAS - Ability to retrieve recorded data from PTI-files should be implemented (Group: PTI handling) Speed/tacho profile should be calculated using Automotive Group libraries (Group: General) Eksempler på ikke funktionelle krav: Calculation times should be reduced to < 1 min for 3k points/80 intervals (Group: Performance) Load time should be improved compared to current solution (Group:mapping) Kravspecifikation i softwareudvikling, side 5
Kravspecifikation med Use Case Kravspecifikation Aktør-kontekst diagram 1. Indledning 2. Generel beskrivelse 3. Specifikke krav 4. Ekstern grænseflade 5. Krav til ydelse 6. Kvalitetsfaktorer 7. Design krav 8. Andre krav 9. Dellevering Aktør System X Use Case diagram Use Case 1 Use Case 2... Use Case n Kravspecifikation i softwareudvikling, side 6
En traditionel tekstspecifikation Potentielle problemer med en ren tekst specifikation: Det kan være svært at finde kravene Det er vanskeligt at få et overblik (50-200 sider) Den er vanskelig at modificere Udvidelser udføres til tider som tilføjelser Det er meget svært at undgå redundans Der er ofte unødvendige design krav Ofte har specifikationen ingen standard struktur Overgang til design kan være vanskelig Fordele ved en ren tekst specifikation: Den er let at læse forstået på den måde at man starter side 1 og slutter side nn Specifikationer baseret på såvel diagrammeringsteknikker som tekst er langt mere konsistente, entydige, modificerbare og gennemskuelige Kravspecifikation i softwareudvikling, side 7
Produkter fra kravspecifikationsfasen Kravspecifikation option option Kravspecifikation med Use Cases Accepttest specifikation (G)UI Prototype Begrebsmodel Kunde Salg/marketing Review Kravspecifikation i softwareudvikling, side 8
Basal Use Case notation System Aktør Use Case Use Case specifikation Aktør beskrivelse Kravspecifikation i softwareudvikling, side 9
Hvad er en aktør ( Actor )? Alt der skal eller kan kommunikere med det ønskede system repræsenteres som aktører IKON: En aktør kan repræsentere: en person rolle et andet system en fysisk enhed (sensor, transducer,..) Aktør Kravspecifikation i softwareudvikling, side 10
Nye valgfrie aktører i UML2 Anvendes fint til tekniske systemer som er de primære produkter hos Brüel og Kjær Person Blockhead Clockhead Gearhead Kravspecifikation i softwareudvikling, side 11
Systemafgrænsning Systemafgrænsningen foretages ved at udarbejde et aktør-kontekst (actor-context) diagram Systemafgrænsning er en af de vigtigste aktiviteter, der bør foretages tidligt i et specifikationsforløb Foretages ved: at finde og navngive de aktører, der er i samspil med det ønskede system at navngive det system, der ønskes specificeret og udviklet Resultatet dokumenteres vha. et aktør-kontekst diagram Kravspecifikation i softwareudvikling, side 12
Aktør-kontekst diagram Passager Balise PositonsId Balise SignalStatus TogFører Tog System Tog Kontrol LokoFører Center System MaskinStyring BremseSystem HjulSensor DørSystem Kravspecifikation i softwareudvikling, side 13
Review af aktør-kontekst diagram Checkliste til review Er alle relevante aktører identificeret? Er aktørerne primære, sekundære eller begge dele? Er der brugt rollenavne for personaktører? Er hver aktør beskrevet vha. et navneord i ental? Har aktørerne forståelige navne? Er aktørbeskrivelserne udfyldt? Har systemet et forståeligt navn? Er de øvrige interessenter også identificeret? Kravspecifikation i softwareudvikling, side 14
Målopfyldelse og Use Cases En Use Case skal opfylde et mål: Det vil normalt være et mål for den primære aktør eller f.eks. vil det at indtaste en pinkode ikke være et mål for en aktør og derfor ikke være en Use Case Det kan være et mål for en af de øvrige interessenter (Stakeholders) til systemet f.eks Use Casen Registrér Kundeinformation, der måske ikke udgør et specielt erkendt mål for en aktør Kravspecifikation i softwareudvikling, side 15
Use Case diagram En Use Case er en enhed af meningsfuldt arbejde på forretnings- eller system niveau Et Use Case diagram indeholder: Aktører, som portrættere entiteter der udfører en særlig rolle i et givet system. En aktør kan være en person, et andet system, en organisation, Use Cases, som en visuel repræsentation af forretnings eller system processen Associations pile, der viser, hvem der tager initiativ til at starte en Use Case System grænse definere rammerne for systemet Aktør Initier Use Case System Grænse Use Case beskrivelse Kravspecifikation i softwareudvikling, side 16
Eksempel: Use Case Diagram Passager Giv passagerinformation <<extends>> Tog-System (TS) Udfør Turplan Giv vigtig meddelelse <<extends>> TogFører Giv akut ressourcesvigt Ændring af KørselsInformation LokoFører <<extends>> Foretag togstyring <<extends>> <<extends>> Foretag Katastrofebrems Tog Kontrol Center System Foretag dørstyring Foretag automatisk nedbremsning Bestem Hastighed Bestem Toglokation DørSystem Maskin Styring Bremse System Balise SignalStatus LokoFører HjulSensor Balise PositionsId Kravspecifikation i softwareudvikling, side 17
Review af Use Case diagram Checkliste til review Har hver Use Case et veldefineret og entydigt mål? fremgår dette mål af navnet? er målet beskrevet i en Use Case specifikation Er Use Casen navngivet ved hjælp af et udsagnsord, der virker på et navneord? Er hver Use Case forbundet til mindst en aktør? Er der aktører, der ikke er forbundet til nogle Use Cases? Mangler der Use Cases, for at tilfredsstille de øvrige interessenter? Er der tænkt på Use Cases, der aktiveres af systemet? Kravspecifikation i softwareudvikling, side 18
Use Case specifikation Hver Use Case har en specifikation, der beskriver samtlige mulige scenarier, incl. fejlsituationer Use Case Use Case specifikation Scenariet er den konkrete instantiering med et bestemt gennemløb af Use Casen. Kravspecifikation i softwareudvikling, side 19
Use Case og scenarier Specifikationen skal beskrive samtlige scenarier Aktør 2 Use Case 4 Use Case 4 specifikation...aktør 2...... A... B...B1... Solskinsscenario xxxx yyyy zzzzz... Alternativ scenario 1 xxxx cc yyyy dd zzzzz... Alternativ scenario 2 xxxx yyyy eee zzzzz dddd... ffff... Kravspecifikation i softwareudvikling, side 20
Use Case specifikation - skabelon Use Case nr. X: Use Case navn Mål: Inititering: Startbetingelser: Slutresultat: Succes: Fejl: Normalforløb: Undtagelser: Kravspecifikation i softwareudvikling, side 21
Use Case specifikation - eksempel Use Case 1: BestemToglokation Mål: At bestemme et togs præcise position på en tur ud fra en absolut positionsbestemmelse ved passage af en balise og en relativ positionsbestemmelse ud fra antallet af hjulomdrejninger siden sidst passerede balise Initiering: af Tog-Systemet ved opstart Aktører og interessenter: Aktører: BalisePositionsId (en del af den fysiske balise), Hjulsensor og TogKontrolCenter-System Øvrige interessenter: jernbaneselskabet og personer der kører med toget, da denne Use Case udgør en vigtig kernefunktion i sikkerhedssystemet Antal samtidige forekomster: 1 Frekvens: kontinuert funktion Ikke funktionelle krav: Balisesignalet skal kunne aflæses ved den maksimale hastighed for toget Referencer: Grænsefladebeskrivelse for Balise se dokumentet TBD. Startbetingelser: ingen Slutbetingelser: Succes: at togets position kontinuert er fastlagt med den ønskede præcision Fejl: at togets position ikke kan fastlægges Normalforløb: Systemet skal til stadighed foretage følgende: 1.A.1 Når toget passerer en balise aflæser Tog-Systemet en identifikationskode fra balisen. 1.A.2. Tog-Systemet omsætter balisens identifikationskode til en absolut lokation på baggrund af information fra Turplanen. Lokationen angiver det segment, toget befinder sig på samt afstanden fra segmentets start. 1.A.3. Tog-Systemet sender ved passage af balisen lokationen til TogKontrolCenter-Systemet sammen med togets nummer og en turidentifikationskode. 1.B.1 Tog-Systemet udregner mellem to Baliser en relativ afstand ved at tælle hjulomdrejninger, der aflæses vha. aktøren hjulsensor og ud fra kendskab til hjulets diameter. 1.B.2. Tog-Systemet tester, at der modtages et Balisesignal for hver km dvs. at den relative afstand er mindre end 1 km. [Undtagelse: manglende Balisesignal] Undtagelser: manglende Balisesignal: I dette tilfælde beregnes toglokationen vha. hjulsensoren og fejlen logges i systemet og Use Casen fortsætter. Hvis næste baliseaflæsning også fejler så gives der fejlmelding til TogKontrolCentret-Systemet, der beslutter om toget kan fortsætte. Kravspecifikation i softwareudvikling, side 22
Use Case skabelon - eks Use Case name Status Use Case Goal Initiating event Primary Actors Secondary Frequency Non-functional requirements Comments Precondition Success Result Error Flow of events Variations Exceptions Nr. Version #Concurrent instances Kravspecifikation i softwareudvikling, side 23
Review af Use Case specifikation Checkliste til review er der anvendt en skabelon? er der mellem 3-10 trin? er hvert trin beskrevet på et passende niveau? er det klart i hvert trin, hvem der har initiativet? er der anvendt en aktiv sætning i nutid? er hvert trin beskrevet med et klart delmål, der fører mod hovedmålet? er normal forløbet let at læse og forstå? er alle relevante undtagelser og varianter identificeret og beskrevet? er interessenternes interesser beskyttet? er alle felter i skabelonen udfyldt? Kravspecifikation i softwareudvikling, side 24
Arbejdsgange - workflow Ope ra+ Visitationssystem LIS Find målgruppe Angiv matchgruppering Vælg pakke Vælg tilbudspakke sortering ikke tilfredsstillende Specificer borgerprofil Fremsøg resultat Foresp ørgsel «datastore» Nøgletal Vurder søgeresultat Vis resultat Resultat forespørgsel sortering tilfredsstillende Afslut søgning Exit visitationssystem Kravspecifikation i softwareudvikling, side 25
Accepttest specifikation Accepttestspecifikationen påbegyndes på kravspecifikationstidspunktet Udføres på basis af kravspecifikations-dokumentet Formål: at gøre kravspecifikationen testbar, dvs. at sikre at alle krav kan testes Kravspecifikation med Use Cases Accepttest specifikation ver. 0.5 Kravspecifikation i softwareudvikling, side 26
Eksempler på ikke testbare krav Alle krav skal være testbare Følgende krav skal enten fjernes fra krav-specifikationen eller også skal de gøres testbare: Svartiden skal være rimelig Systemet skal være brugervenligt Systemet skal udvikles efter gode designprincipper Systemet skal være veldokumenteret Systemet skal være robust og fejltolerant Aktøren skal prøve et par gange Kravspecifikation i softwareudvikling, side 27
Hvad testes i en accepttest? De funktionelle krav (dvs. Use Casene) samt de ikke funktionelle krav, der kan relateres til en enkelt Use Case f.eks. svartider Perform Measurement De generelle ikke funktionelle krav brugervenlighed sikkerhed effektivitet performance kvalitet Kravspecifikation i softwareudvikling, side 28
Arbejdstrin for Use Cases modellering 1. Foretag systemafgrænsningen Find aktører og beskriv disse Find øvrige interessenter Dokumenteres vha. et aktør-kontekst diagram 2. Review aktør-kontekst diagrammet 3. Find Use Cases for hver primær aktør og evt. for øvrige interessenter Beskriv målet for hver af disse Use Cases Dokumenteres vha. et eller flere Use Case diagrammer 4. Review Use Case diagrammet Kravspecifikation i softwareudvikling, side 29
Arbejdstrin 2 af 4 5. Udarbejd en begrebsliste identificer og fastlæg begreber (domænemodel) beskriv de identificerede begreber i en begrebsliste 6. Tilpas den skabelon, der skal anvendes ved beskrivelsen bør tilpasses til projektets type 7. Udvælg og uddeleger Use Cases til beskrivelse minimum, dem der indgår i første dellevering uddeleger til flere personer (evt. til kunden) fordel at flere kan arbejde parallelt og uafhængigt af hinanden Kravspecifikation i softwareudvikling, side 30
Arbejdstrin 3 af 4 8. Beskriv Use Cases ud fra en skabelon Beskriv først mål feltet Beskriv felterne: startbetingelser, slutresultat, initiering og aktører Beskriv dernæst normalforløbene (solskinsscenarierne) Brainstorm dernæst over undtagelses og variant forløb Beskriv dernæst for hver undtagelse og variant, hvordan systemet skal reagere på disse Udfyld de resterende skabelon felter 9. Review Use Casen Kravspecifikation i softwareudvikling, side 31
Arbejdstrin 4 af 4 10. Overvej anvendelse af include, extends og specialisering 11. Review Use Case modellen 12. Integrer Use Case specifikationerne i kravspecifikations dokumentet 13. Udfyld de resterende afsnit i kravspecifikationen 14. Review den komplette kravspecifikation Kravspecifikation i softwareudvikling, side 32
Aktivitetsperspektiv Analyse og kravspecifikation Kravspec. med OO Analyse OO System design SW & HW implementering af X Use Case s System integrations test Accept test Use Case Model Use Case Model næste iteration Kravspecifikation i softwareudvikling, side 33
Kravspecifikation i SW udvikling Kravspec med Use Case Domæne Analyse OO Analyse Applikation Analyse Arkitektur Design OO System Design Iterationer Interface Design Detaljeret Analyse og Design Implementering Test, Integration, Deployment Kravspecifikation i softwareudvikling, side 34
Kravspecifikation i SW udvikling Kravspec med Use Case Domæne Analyse Analyse Identifikation af krav. Udarbejdelse af en Kravspecifikation vha. Use Case teknikken UML: Use Case diagrammer, Aktivitets diagrammer Identifikation og opdeling af koncepter og objekter udtrykt ved en domæne model. UML: Klasse diagrammer Applikation Analyse Arkitektur Design System Design Interface Design Viderebearbejdning af domænemodel til en applikationsmodel. Beskrivelse af udvalgte use case scenarier i en interaktionsmodel. UML: Klassediagrammer, sekvens-/communication diagrammer,(state diagrammer) Udarbejdelse og beskrivelse af de væsentlige arkitekturale elementer i systemet efter 4+1 view. Anvendelse af Arkitektur patterns UML:Pakker, Aktive klasser og objekter, Deploymentdiagram, komponentdiagram Fastlæggelse og beskrivelse af de væsentlige interfaces imellem de forskellige komponenter samt principper for interaktion og anvendelse UML:Interface, komponenter Detaljeret Analyse og Design Implementering Viderebearbejdning af den logiske model. Anvendelse af Design patterns UML: Klassediagrammer, sekvens- /communicationdiagram, state diagrammer Implementering (konstruktion) af modellerne i et OO sprog (C++, Java, C#). Implementering af tabeller fra datamodel Test Integration, Modul (unit) test, Deployment integration test, accept test Kravspecifikation i softwareudvikling, side 35
Roadmap Beskrivelse af workproducts Kravspec med Use Case Domæne Analyse Analyse Workproduct: Kravspecifikation med Use Case Applikation Analyse Workproduct: Analyse dokument Arkitektur Design OO System Design Workproduct: System/software Architecture Document - SAD Interface Design Workproduct: Komponent beskrivelser Detaljeret Analyse og Design Workproduct: Kørende kode Implementering Workproduct: Test dokument(test case, procedure, test komponenter) Test, Integration, Deployment Kravspecifikation i softwareudvikling, side 36
Iterationer - illustreret Kravspec m. Use Case Analyse System Design Processen: -Use Case Drevet -Iterativ -Arkitektur Centreret Detaljeret Analyse Og Design Implementering Test,Integration, Deployment... Iteration 1 Iteration 2 21.01.07 Use Case 2,3,11,12 Work Product: xxx, yyy 15.03.07 Use Case 4,5,6,10 Work Product: xxx, yyy Kravspecifikation i softwareudvikling, side 37
Kravspecifikation og Analyse Use Case Kravspec med Use Case Activity Activity Activity Domæne Analyse Analyse Use Case diagram Aktivitetsdiagram B1 B2 Applikation Analyse C1 D1 D2 Klassediagram Arkitektur Design System Design Interface Design Sekvensdiagram :B1 :C1 :D1 :B2 Tilstandsdiagram Detaljeret Analyse og Design :D2 Implementering Test Integration, Deployment Kravspecifikation i softwareudvikling, side 38
System afgrænsning Under kravspecificerings aktiviteten vil de funktionelle system Use Case som regel blive udledt Disse System Use Case vil danne grundlag for at udlede de arkitekturalt væsentligste funktionelle scenarier Metodetrin for Use case kravspecifikation; 1. Foretag systemafgrænsningen Find aktører og beskriv disse Find øvrige interessenter Dokumenteres vha. et aktør-kontekst diagram 3. Find Use Cases for hver primær aktør og evt. for øvrige interessenter Beskriv målet for hver af disse Use Cases Dokumenteres vha. et eller flere Use Case diagrammer Kravspecifikation i softwareudvikling, side 39
System Use Case Udled de funktionelle krav udtrykt ved System Use Cases Metodetrin for Use case kravspecifikation; 1. Foretag systemafgrænsningen Find aktører og beskriv disse Find øvrige interessenter Dokumenteres vha. et aktør-kontekst diagram 3. Find Use Cases for hver primær aktør og evt. for øvrige interessenter Beskriv målet for hver af disse Use Cases Dokumenteres vha. et eller flere Use Case diagrammer Kravspecifikation i softwareudvikling, side 40
Funktionelle Scenarier Funktionelt Use Case scenarie Bestem Tog lokation TOG System togsæt CTbestemToglokation BDbalisePositionsId turplan BDhjulSensor BDtogKontrolCenterSystem HjulSensor BalisePositionsId TKC tilknytturplan start start start balisesignal togvedbalise omsættillokation nulstilrelativafstand nytoglokation hjulpulssignal læstoglokation læsrelativafstand stop stop stop Kravspecifikation i softwareudvikling, side 41
Kravspecifikations aktiviteten Lære teknikken Forstå og anvende de enkelte trin i aktiviteten rigtigt Få kravspecificeret på det rigtige abstraktionsniveau Scope nyt produkt, nye krav til eksisterende Afholdelse af workshops Anvende teknikkerne på workshops Sikrer kommunikation imellem marketing og produktudvikling Sikrer enighed og forståelse deltagere imellem Sikrer dokumentation af beslutninger Bør faciliteres Kravspecifikation i softwareudvikling, side 42
Spørgsmål Kravspecifikation i softwareudvikling, side 43