Ida 750 IT Strategi Kravspesifikasjon n Kravspesifikasjon n

Ida 750 IT Strategi Kravspesifikasjon n Kravspesifikasjon: n Pensum definert gjennom forelesningene (Powerpoint filer) n Mye overlapp med IT-strategi delen n Vi har tidligere sett på hvordan organisasjoner kan få maksimalt ut av alle sine IT systemer, her ser vi på kravene til ett system Denne forelesningen kan også fungere som en oppsummering av mye av det vi tidligere har snakket om Referansebok: n 30. 10. 2020 Del I av Kotonya, G. & Sommerville, I. , Requirements Engineering, Wiley, 1997. Kravspesifikasjon 1

Bakgrunn n IT prosjekter har vært plaget av: n n n Budsjettoverskridelser Tidsoverskridelser Mange fiaskoer Ofte legger en skylden på uklare kravspesifikasjoner Med kravspesifikasjon ønsker en: n n Bedre styring Fastere former Kontroll over budsjett og tid Systemer som dekker kundens behov 30. 10. 2020 Kravspesifikasjon 2

Kravspesifikasjon kan være mangt… n n Et formelt dokument, en juridisk bindende kontrakt, mellom kunde og utvikler om hva som skal gjøres En prototype En liste av mål for systemet, samt en skisse til løsning Vag målsetting n ”hei, vi har et problem med å lage en ordreplan” 30. 10. 2020 Kravspesifikasjon 3

Her skal vi n n n I stor grad se på mer formell kravspesifikasjon Kunnskap om dette er viktig da enkelte organisasjoner krever en formell spesifikasjon Men, vi skal også se på andre måter å lage en kravspesifikasjon på 30. 10. 2020 Kravspesifikasjon 4

Forskjellige typer av krav kan inngå: Generelle Funksjonelle Krav til implementasjon Effektivitet Brukervennlighet 30. 10. 2020 Kravspesifikasjon 5

Problemer n n n Upresise mål Kravspesifikasjonen beskriver ikke brukernes virkelige behov Spesifikasjonene er inkonsistente og ikke komplette Spesifikasjonene er for detaljerte (låser utviklerne) Misforståelser mellom bruker, de som utvikler spesifikasjonene og utviklerne Kravspesifikasjonen forutsetter en stabil verden, det har vi sjelden 30. 10. 2020 Kravspesifikasjon 6

Kan føre til… n n n n Forsinket leveranse Fordyret leveranse Behov for store endringer etter installasjon Systemet blir benyttet galt, lite eller ikke i det hele tatt Systemet kan være upålitelig Meget store vedlikeholdskostnader Dårlig tilpassning til andre systemer Systemet blir fort avleggs 30. 10. 2020 Kravspesifikasjon 7

Kravspesifikasjonsprosessen Hvordan man håper at denne skal gå! 30. 10. 2020 Kravspesifikasjon 8

Aktiviteter 30. 10. 2020 Kravspesifikasjon 9

Kravspesifikasjonsdokumentet inneholder: 30. 10. 2020 Kravspesifikasjon 10

IEEE/ANSI 830 -1993 (standard): n Introduction n n n General description n n n Product perspective Product functions User characteristics General constraints Assumptions and dependencies Specific requirements n n Purpose Scope of the product Definitions References Overview of document functional, non-functional, interface, performance, database and network requirements, etc. Index 30. 10. 2020 Kravspesifikasjon 11

Hvem bruker kravspes. dokumentet? 30. 10. 2020 Kravspesifikasjon 12

Guidelines: 30. 10. 2020 Kravspesifikasjon 13

Prosessen 30. 10. 2020 Kravspesifikasjon 14

Data 30. 10. 2020 Kravspesifikasjon 15

Aktivitetsmodell elicitation – å få fram, synliggjøre 30. 10. 2020 Kravspesifikasjon 16

Tradisjonell modell Waterfall model 30. 10. 2020 Kravspesifikasjon 17

Mer moderne 30. 10. 2020 Kravspesifikasjon 18

Utvikling, først når vi vet hva vi skal lage: Utvikling av systemet (detaljspesifikasjon, programmering…) 30. 10. 2020 Kravspesifikasjon 19

Hvem er involvert? 30. 10. 2020 Kravspesifikasjon 20

Roller 30. 10. 2020 Kravspesifikasjon 21

Verktøy for å understøtte kravspesifikasjonsprosessen: 30. 10. 2020 Kravspesifikasjon 22

CMM – Capability Maturity Model SEI, Software Engineering Institute i Pittsburgh bruker disse 5 nivåene. 30. 10. 2020 Kravspesifikasjon 23

Nivåer av utvikling mht softwareutvikling: n Initial: n n Repeatable level: n n Dokumentasjon, standardisering Managed level: n n Grunnleggende prosesser for budsjettering og planlegging av utviklingsprosesser er beskrevet og kan repeteres Defined level: n n Udisiplinerte prosesser, individer bestemmer hvordan ting skal gjøres og hvilke teknikker som skal brukes Kvalitetskontroll Optimizing level: n Kontinuerlig prosess forbedring, objektive målinger 30. 10. 2020 Kravspesifikasjon 24

”in” å karakterisere organisasjoner på denne måten n n Mest anvendelig for store softwarehus Har mange prosjekter Ofte store prosjekter Mange prosjektdeltagere Formalisering er nødvendig for å få oversikt og kontroll 30. 10. 2020 Kravspesifikasjon 25

Forenklet model for kravspesifikasjon 30. 10. 2020 Kravspesifikasjon 26

Best practices 30. 10. 2020 Kravspesifikasjon 27

Requirement Elicitation 30. 10. 2020 Kravspesifikasjon 28

Fire dimensjoner n Application domain understanding n n Problem understanding n n Hva er målene for systemet, hvilke problemer skal vi løse… Business context n n Forstå institusjonen, området der systemet skal anvendes. Hvem er brukerne, hva er brukernes bakgrunn. Hvilke holdninger eksisterer… Systemet skal (som oftest) bidra til utvikling av organisasjonen, hvordan passer systemet inn med andre, med overordnede strategier Stakeholder needs and constraints n Hva er deres motivasjon, hva ønsker de å oppnå 30. 10. 2020 Kravspesifikasjon 29

Problemer n Application domain understanding n n Problem understanding n n De har et problem, men akkurat hva dette går ut på og hvordan det skal løses må vi ofte finne ut selv. De vi skal arbeide med er ofte opptatt… Business context n n Informasjon om dette er ikke samlet på ett sted, mange kilder, også muntlige, eksplisitt og implisitt Hvordan fungerer organisasjonen, er overordnede mål og strategier uttalte? Stakeholder needs and constraints n Stakeholders kan ha sine (ofte gode) personlige motivasjoner i et prosjekt, hva er disse? 30. 10. 2020 Kravspesifikasjon 30

”Elicitation” og analyse 30. 10. 2020 Kravspesifikasjon 31

4 kritiske aktiviteter: n Mål n n Bakgrunnskap n n Organisasjon, anvendelsesområde, andre systemer… Organisering n n Beskriv målene for systemet, oversikt over problemet, hvorfor et nytt system kan være nødvendig, begrensninger som budsjett… Organiser data og informasjon samlet inn til nå, prioriter mål Brukerkrav n Hva er brukernes krav til det nye systemet 30. 10. 2020 Kravspesifikasjon 32

Oversikt 30. 10. 2020 Kravspesifikasjon 33

Analyse /forhandlinger 30. 10. 2020 Kravspesifikasjon 34

Teknikker n n Samle bakgrunnsstoff (strategiplaner, årsrapporter…. ) Intervjuer Scenarioer Soft system methodology (SSM) n Syv faser (se neste slide) 30. 10. 2020 Kravspesifikasjon 35

SSM – 7 faser: 30. 10. 2020 Kravspesifikasjon 36

30. 10. 2020 Kravspesifikasjon 37

Etnografisk undersøkelse Observasjon av brukerne i arbeid, intervjuer, video, ”debriefing” hvor vi trekker ut verdifull informasjon 30. 10. 2020 Kravspesifikasjon 38

Prototyping n Alternativer: n n n Bruk og kast Evolusjonær prototyping (mer aktuell nå med bedre verktøy) Mange fordeler: n n n Kan vise hvordan systemet vil bli, inklusiv ”look and feel” Håndfast Lettere for brukerne å forholde seg til en prototype enn en spesifikasjon, mer og bedre tilbakemeldinger Hurtigere utvikling Understøtter utvikling i faser 30. 10. 2020 Kravspesifikasjon 39

Analyse av kravspesifikasjon, sjekkliste 30. 10. 2020 Kravspesifikasjon 40

Validering n Sjekker for: n n Kompletthet Konsistens Nøyaktighet Avsluttende fase i arbeidet 30. 10. 2020 Kravspesifikasjon 41

Input & Output 30. 10. 2020 Kravspesifikasjon 42

Reviews (gjennomgang), teknikk for å verifisere kravspesifikasjonen 30. 10. 2020 Kravspesifikasjon 43

Sjekkliste 30. 10. 2020 Kravspesifikasjon 44

Prototyping n Validering gjennom prototyping: n n Velg testpersoner Utvikl testscenario Utfør scenario Mange krav kan kun testes gjennom prototype: n n n Opplæring Brukervennlighet Effektivitet (delvis) 30. 10. 2020 Kravspesifikasjon 45

Prosess 30. 10. 2020 Kravspesifikasjon 46

Modellvalidering n Vi kan ha detaljerte modeller av systemet, for eksempel for dataflyt n n n Er disse i orden? Inkluderer de all relevant informasjon? Konfliktfritt? Er de konsistent med andre modeller? Beskriver de brukernes behov? 30. 10. 2020 Kravspesifikasjon 47

Testing n Kan kravene testes? n n Eksempel: n n n Kan vi gjøre en eller flere tester i det ferdige systemet for å vise at kravet er oppfylt Systemet skal være lett å lære? 95% av brukerne skal kunne benytte systemet etter 10 minutter? Hvilket krav er testbart? 30. 10. 2020 Kravspesifikasjon 48

Requirements management n Her er vi opptatt av: n n Stabile og dynamiske krav Identifisering av krav, lagring Versjonskontroll Sporing (traceability) 30. 10. 2020 Kravspesifikasjon 49

Behovet for endringer 30. 10. 2020 Kravspesifikasjon 50

Identifisering av krav 30. 10. 2020 Kravspesifikasjon 51

Lagringsstruktur for krav 30. 10. 2020 Kravspesifikasjon 52

Versjonskontroll (faser) 30. 10. 2020 Kravspesifikasjon 53

Versjonskontroll (prosess) 30. 10. 2020 Kravspesifikasjon 54

Sporing n n n Vi ønsker å kunne spore endringer begge veier. Hvilke underordnede krav kan bli berørt av endringen i dette kravet? I hvilke overordnede krav inngår kravet som er endret? 30. 10. 2020 Kravspesifikasjon 55

Typer av sporing 30. 10. 2020 Kravspesifikasjon 56

Oppsummering n Følgende må være på plass: n n n n Det er viktig å vite målsettingene for systemet Vi må ha en god og utarbeide idé av systemfunksjonaliteten Brukergruppene må være kjent Vi må ha valgt metodikk Vi må vite hvordan systemet skal implementeres Koplinger til andre systemer må være kjent Installasjonsfasen må være beskrevet Før vi starter utviklingen av systemet 30. 10. 2020 Kravspesifikasjon 57