Kravspesifikasjon Kravspesifikasjon: Pensum definert gjennom forelesningene (Powerpoint filer) Mye overlapp med IT-strategi delen 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: Del I av Kotonya, G. & Sommerville, I., Requirements Engineering, Wiley, 1997. Få fram at det er fellestrekk mellom strategiarbeid og kravspesifikasjon. I det første ser vi på bedriften under ett, kanskje i et 3-10 års perspektiv. I kravspesifikasjon ser vi på en deloppgave. Hvor store likhetstrekk vi har vil være avhengig av type deloppgave. I noen tilfeller vil disse være klart spesifisert (delsystem). Da har vi færre fellestrekk. I andre vil vi ha en identisk jobb til kravspesifikasjon - å finne ut hva bedriften egentlig trenger. Oshaug: Om bedriften. Utvikle administrativt system (komme tilbake til dette). Ble under dette arbeidset introdusert til en avdeling som ferdigstilte (slipte, målte, ISO kontrollerte) propellblad. Store problemer: formann (overbelastet), Excel (kun av formann, begrenset ISO kontroll, tungv. Å bruke). Lage nytt system som kunne brukes av flere (Access). Utgangspunkt i regneark. Intervjuer. Være i bedriften. Oppdaget andre problem: Enkelte propellere var vanskelig å kontrollere (vis hvordan regneark virker). Manglende standard for koordinatsystem. Tungv. Å lage dokumentasjon. Dekke begge deler. Systemet kostet kun 100.000 å utvikle. Betale seg inn i løpet av en måned. 150% produktivitetsøkning, mindre bruk av innleide tjenester, bedre lev. Sikkerhet. Styref. Påpekte at en kunne se i regnskapet når systemet kom inn. Ikke unntak. Ofte oppdrag for inst. Uten eget utviklingspersonale. Vide horisonter. Demo PPK. 04.04.2017 Kravspesifikasjon

Bakgrunn IT prosjekter har vært plaget av: Budsjettoverskridelser Tidsoverskridelser Mange fiaskoer Uklarhet om mål er oppnådd Ofte legger en skylden på uklare kravspesifikasjoner Med kravspesifikasjonen ønsker en: Bedre styring Fastere former Kontroll over budsjett og tid Systemer som dekker kundens behov 04.04.2017 Kravspesifikasjon

Kravspesifikasjon kan være mangt… 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 Kan starte med en vag ide ”hei, vi har et problem med å lage en ordreplan” 04.04.2017 Kravspesifikasjon

Her skal vi I stor grad se på mer formell kravspesifikasjon Kunnskap om dette er viktig da enkelte organisasjoner krever dette Men, vi skal også se på andre måter å lage en kravspesifikasjon på Kravspesifikasjonen blir viktig for store systemer 04.04.2017 Kravspesifikasjon

Forskjellige typer av krav kan inngå: Generelle Funksjonelle Krav til implementasjon Effektivitet Brukervennlighet 04.04.2017 Kravspesifikasjon

Problemer Upresise mål Kravspesifikasjonen beskriver ikke brukernes virkelige behov Spesifikasjonene er inkonsistente og ikke komplette Spesifikasjonene er for detaljerte (låser utviklerne), mange punkter, svak overordnet forståelse Misforståelser mellom bruker, de som utvikler spesifikasjonene og utviklerne Kravspesifikasjonen forutsetter en stabil verden, det har vi sjelden Kravspesifikasjonen tar ikke hensyn til at visse mål er vanskelig å oppnå Hva når de egentlige kravene endres over tid? 04.04.2017 Kravspesifikasjon

Kan føre til… 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 Kritiske brukere Meget store vedlikeholdskostnader Dårlig tilpassning til andre systemer Systemet blir fort avleggs Indirekte kostnader (jobben blir ikke gjort) 04.04.2017 Kravspesifikasjon

Ofte Store kostnader til utvikling og tilpassning Systemet blir tatt i bruk Det virker Men uklart om en har oppnådd noe F.eks. (fra en vit. artikkel): It is therefore very unlikely that any ERP implementation can simply be asserted to be a success or a failure Men det er selvfølgelig systemer som er en åpenbar suksess eller en åpenbar fiasko 04.04.2017 Kravspesifikasjon

Kravspesifikasjonsprosessen Hvordan man håper at denne skal gå! 04.04.2017 Kravspesifikasjon

Aktiviteter 04.04.2017 Kravspesifikasjon

Kravspesifikasjonsdokumentet inneholder: 04.04.2017 Kravspesifikasjon

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

Hvem bruker kravspes. dokumentet? 04.04.2017 Kravspesifikasjon

Guidelines: 04.04.2017 Kravspesifikasjon

Prosessen 04.04.2017 Kravspesifikasjon

Data 04.04.2017 Kravspesifikasjon

Aktivitetsmodell elicitation – å få fram, synliggjøre 04.04.2017 Kravspesifikasjon

Tradisjonell modell Waterfall model 04.04.2017 Kravspesifikasjon

Mer moderne 04.04.2017 Kravspesifikasjon

Utvikling, først når vi vet hva vi skal lage: Denne fasen er lite formalisert, åpen, med mange usikkerhetet Denne fasen bør være formalisert, entydig og sikker Utvikling av systemet (detaljspesifikasjon, programmering…) 04.04.2017 Kravspesifikasjon

Hvem er involvert? 04.04.2017 Kravspesifikasjon

Roller 04.04.2017 Kravspesifikasjon

Verktøy for å understøtte kravspesifikasjonsprosessen: 04.04.2017 Kravspesifikasjon

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

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

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

Problemer med modellen Mange softwareutviklere bruker en ad hoc modell (nivå 1) med stor suksess Eksempler: Microsoft, Google, Facebook, Apple Men dette kan sies å falle innenfor kreativ softwareutvikling, mens “maturity” modellen kanskje er ment for mer rutinepreget virksomhet?

Forenklet modell for kravspesifikasjon 04.04.2017 Kravspesifikasjon

Best practices 04.04.2017 Kravspesifikasjon

Requirement Elicitation 04.04.2017 Kravspesifikasjon

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

Problemer Application domain understanding Problem understanding Informasjon om dette er ikke samlet på ett sted, mange kilder, også muntlige, eksplisitt og implisitt Problem understanding 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 Hvordan fungerer organisasjonen, er overordnede mål og strategier uttalte? Stakeholder needs and constraints Stakeholders kan ha sine (ofte gode) personlige motivasjoner i et prosjekt, hva er disse? 04.04.2017 Kravspesifikasjon

”Elicitation” og analyse 04.04.2017 Kravspesifikasjon

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

Mål Skal fortelle oss hva vi skal oppnå, hensikten (”rationale”) Disse kan brukes når vi må ta avgjørelser underveis (f.eks. for å velge mellom brukervennlighet og effektivitet) Målene blir viktige når systemet skal evalueres 04.04.2017 Kravspesifikasjon

Oversikt 04.04.2017 Kravspesifikasjon

Analyse /forhandlinger 04.04.2017 Kravspesifikasjon

Teknikker Samle bakgrunnsstoff (strategiplaner, årsrapporter….) Intervjuer Scenarioer ”Soft system methodology” (SSM) Syv faser (se neste slide) 04.04.2017 Kravspesifikasjon

SSM – 7 faser: 04.04.2017 Kravspesifikasjon

04.04.2017 Kravspesifikasjon

Etnografisk undersøkelse Observasjon av brukerne i arbeid, intervjuer, video, ”de-briefing” hvor vi trekker ut verdifull informasjon 04.04.2017 Kravspesifikasjon

Prototyping Alternativer: Mange fordeler: Bruk og kast Evolusjonær prototyping (mer aktuell nå med bedre verktøy) Mange fordeler: 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 Gir utviklerne tidlige kunnskaper om metoder, tidsbruk m.m. 04.04.2017 Kravspesifikasjon

Prototype Av hele systemet, prototypen kan da bli systemet (ref. Oshaug) Av deler av systemet: Brukergrensesnitt Komplekse tekniske løsinger Tidsaspekt Det er smart å konsentrere seg om ukjente deler først. Prototyper kan hjelpe oss her. 04.04.2017 Kravspesifikasjon

Analyse av kravspesifikasjon, sjekkliste 04.04.2017 Kravspesifikasjon

Validering Sjekker for: Avsluttende fase i arbeidet Kompletthet Konsistens Nøyaktighet Avsluttende fase i arbeidet 04.04.2017 Kravspesifikasjon

Input & Output 04.04.2017 Kravspesifikasjon

Reviews Reviews (gjennomgang), teknikk for å verifisere kravspesifikasjonen 04.04.2017 Kravspesifikasjon

Sjekkliste 04.04.2017 Kravspesifikasjon

Prototyping Validering gjennom prototyping: Velg testpersoner Utvikle testscenario Utfør scenario Mange krav kan best testes gjennom prototype: Opplæring Brukervennlighet Effektivitet (delvis) 04.04.2017 Kravspesifikasjon

Prosess 04.04.2017 Kravspesifikasjon

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

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

Requirements management Her er vi opptatt av: Stabile og dynamiske krav Identifisering av krav, lagring Versjonskontroll Sporing (traceability) 04.04.2017 Kravspesifikasjon

Behovet for endringer 04.04.2017 Kravspesifikasjon

Identifisering av krav 04.04.2017 Kravspesifikasjon

Lagringsstruktur for krav 04.04.2017 Kravspesifikasjon

Versjonskontroll (faser) 04.04.2017 Kravspesifikasjon

Versjonskontroll (prosess) 04.04.2017 Kravspesifikasjon

Sporing 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? 04.04.2017 Kravspesifikasjon

Typer av sporing 04.04.2017 Kravspesifikasjon

Oppsummering Følgende må være på plass: 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 04.04.2017 Kravspesifikasjon

Små systemer – store systemer Mange av de konkrete eksemplene vi har brukt tidligere har vært for små systemer Små systemer har mange fordeler: Oversiktlige Begrenset arbeidsmengde Få brukere, få installasjoner Da kan vi få en betydelig reduksjon av arbeidet med: Kravspesifikasjon Testing Opplæring Med store systemer blir alt annerledes, spesielt om de utvikles under en detaljert kravspesifikasjon 04.04.2017 Kravspesifikasjon 62