Bolk om Kravspesifisering

Transkript

1 Bolk om Kravspesifisering Guttorm Sindre, IDI Læremål Forstå Hva en kravspesifikasjon er, og hva den bør inneholde? Hvorfor god kravspesifikasjon er viktig i IS - utviklingsprosjekter Hvordan man går fram for å lage gode kravspesifikasjoner Praktiske ferdigheter i å Vurdere kvaliteten av kravspesifikasjoner Selv lage gode kravspesifikasjoner Bedømme hvilke uttrykksformer som passer til hva ifbm problemanalyse og kravspek, og hvorfor Men selvsagt ikke perfekt etter dette kurset! Innhold Kravspesifikasjoner, P11 (F13, F14) Innhold Kvalitetsvurdering (validering) Objekter og analyse / krav, P10, P13 (F15) Forskjell på problemanalyse, krav, design Ulike objekter i ulike faser Kravspek og hyllevare, P14 (F16) Spesielle metodiske problemer PORE-metoden Use cases, P12 (F17, F18) Motivasjon for use cases i kravspesifikasjon Hvordan skrive gode (tekstlige) use cases? Denne uka: P11 Utdrag fra Kotonya/Sommerville: Requirements Engineering: Processes and Techniques Del 1: Processes Kap 1: Intro Kap 2: Requirements Processes Kap 3: Requirements Elicitation and Analysis Kap 4: Requirements Validation Kap 5: Requirements Management Del 2: Techniques : navngitte teknikker (SADT, VORD,...) Disposisjon dagens forelesning 1. Hva er et krav? 2. Hvorfor er gode kravspesifikasjoner viktig? 3. FAQs om krav 4. Kravspesifisering i en større utviklingsprosess 5. Kravdokumentet Hva skal en kravspesifikasjon inneholde? 6. Hvordan skrive gode krav? 1. Hva er et krav? Krav sier Hva et system skal gjøre, og hvilke Betingelser/begrensninger det må operere under Ikke hvordan systemets indre skal utformes for å oppnå dette (design/implementasjon) Eksempler (P11, s. 4) 1. Systemet skal behandle info om biblioteksmateriale Systemet skal tillate brukerne å søke på Systemets brukergrensesnitt skal være web-basert Systemet skal støtte minst 20 transaksjoner pr sek. 5. Systemfasilitetene som er tilgjengelige for allmenn bruk skal kunne demonstreres på max 10 min. 1

2 2. Hvorfor er god kravspesifikasjon viktig? Dårlig kravspek gir flg problemer: Krav uttrykker ikke kundens reelle behov Krav er inkonsistente eller ukomplette Dyrt med senere endringer av vedtatte krav (og kostnaden øker til lenger feilaktige krav er med på lasset) Misforståelser mellom kunder, kravkonsulenter og designere Store tapsprosjekter, hva er grunnen? Dårlig prosjektstyring? Dårlig kravspek? Dårlig programmering? Eksempler på tapsprosjekter TRESS-90: 1,2 mrd kroner e-billetten (1995): 300 mill kroner Statens Vegvesen: 152 mill kroner Ariane-5: 5 mrd kroner Uheldig gjenbruk, kode som hadde virket for Ariane -4 Manglende spesifikasjon av forskjeller NASA s Mars-fiasko (1999), tap ca. 3,6 mrd Orbiter brant opp, Polar Lander kræsjet caused by a missing line of computer code several management mistakes, including inadequate testing before launching Viktigheten av å avsløre feilaktige krav tidlig Anslått at kostnaden ved et feilaktig krav multipliseres med 10 per fase Dvs: Oppdages allerede i kravfasen: kostnad 1 Oppdages etter design: kostnad 10 Oppdages etter ferdig implementasjon: kostnad 100 Oppdages etter bruk hos kunden: kostnad 1000 Eksempel på feilaktig (her inkomplett) krav (s.5)... søke på tittel, forfatter eller ISBN. Hva med CD er? 3. FAQs om krav (1.1) Hva er krav? Formulering av en tjeneste, eller Formulering av en begrensning Ulike kategorier av krav Tjenester på brukernivå Generelle systemegenskaper Spesifikke begrensninger Beregningsregler Begrensninger på utviklingsprosjektet (f.eks budsjett, valg av prog.språk) Dvs. ikke nødvendigvis bare HVA systemet skal gjøre Hva er kravspesifisering (RE)? Aktiviteter for å oppdage, dokumentere og vedlikeholde krav til et system Ved hjelp av systematiske teknikker For å sikre at kravene er komplette, konsistente, relevante etc. Hvor mye koster kravspesifisering (RE)? Varierer utifra type applikasjon, vanskegrad etc. Gjennomsnitt 15% for store systemer 10% for mindre systemer Hva skjer når krav er feil? Systemet blir forsinket, dyrere Kunder og brukere blir misnøyde Systemet kan bli lite pålitelig Høye kostnader til drift, vedlikehold, videreutvikling ~100 ganger så dyrt å fikse krav-feil som prog.-feil Hva er en kravspesifiseringsprosess? Strukturert sett av aktiviteter I en eller annen sekvens el. Iterasjon For å finne krav, analysere og forhandle om krav, spesifisere og validere krav Få organisasjoner har standardiserte prosesser 2

3 Fins det noen ideell kravspes-prosess? Ingen riktig for alle organisasjoner Avhengig av type prosjekt, involvert personell etc. De fleste standarder (IEEE std 830, US DoD std 2167A) handler mest om dokumentene som skal produseres, ikke om prosessen Hva er en kravspesifikasjon? Dokumentet, i motsetning til kravspesifisering (aktiviteten) Offisiell formulering av kravene, for kunder, brukere og programvareutviklere Her: kravdokumentet (requirements document) Hva er interessenter (stakeholders)? Personer eller organisasjoner som vil bli påvirket av systemet, og har (eller bør ha) innflytelse på kravene direkte eller indirekte Interessenter, automatisert togsignalsystem Operatører som skal være ansvarlige for systemet Togpersonell Ledelse i jernbanen Passasjerer Utstyrsinstallatører, vedlikeholdsingeniører Tilsynsmyndigheter FAQs (forts) Hva er forholdet mellom krav og design? Krav: HVA, design: HVORDAN Ikke alltid enkelt skille Systemet må virke sammen med andre eksisterende systemer Store systemer: Noe overordnet arkitekturdesign nødvendig før man kan gi detaljerte krav for subsystemer Ønske om å gjenbruke deler av eksisterende system Mhp godkjenning fra eksterne myndigheter: behov for å benytte et standard, utprøvet design Dvs., kan ikke alltid gi en helt ren framstilling av HVA og velge et hvilket som helst HVORDAN innen dette FAQs (siste) Hva er kravstyring (Req. Management)? Holde rede på endringer i kravspek Pga endrede behov, omgivelser, forretningsmål, lover og regler Hovedaktiviteter Endringskontroll: formelle prosedyrer for å innhente og gjennomføre endringer Endringseffektanalyse (change impact analysis): hvordan en endring vil påvirke resten av systemet Forutsetter sporbarhet Krav-krav (hvordan de er relatert til hverandre) Pre-krav (hvordan krav er relatert til overordnede forretningsmål, hvem som hadde kravet,...) Post-krav (hvordan krav er relatert til designet) 4. Kravspesifisering i større utv.prosess Systems engineering : utvikling av systemer med Programvare Maskinvare og annet utstyr Organisasjonelle rutiner for hvordan det skal betjenes To hovedkategorier Brukerkonfigurerte systemer: settes sammen av eksisterende programvareprodukter (hyllevare) Skreddersøm: kunde gir krav, kontraktør utvikler system ihht kravene. Kan være ulike divisjoner i samme organisasjon, eller ulike firmaer Etter hvert nå en glidende overgang Skreddersøm, ulike typer systemer Informasjonssystemer Hovedoppgave: prossesere info i DB Standard plattformer Krav programvarekrav (+ organisasjonsrutiner) Embedded systems (innbakte systemer) Hovedoppgave: kontroll av maskinvare Spesiallaget plattform Krav både til maskinvare og programvare Kommando- og kontrollsystemer Kombinasjon av info.sys og emb.sys. Ulike plattformer satt sammen i nettverk Spesifikasjon av maskinvare, programvare og org.rutiner 3

4 Emergent properties skjulte egenskaper, dvs som ikke kommer til syne før subsystemene er utviklet og satt sammen Pålitelighet Vedlikeholdbarhet Ytelse Anvendbarhet Sikkerhet Trygghet Generisk prosess (Fig 1.2) ]^ W X YZ[ \ g h_ i` jh a]bgc*b g kjhd ief G!H IQJRKLM STUI VLN HO P :;4 < ABCBCD E CE F! "# $% & ' ($% )*% +,-. / 0 1/.. 21/ 0 l m n opq prs t u v w v xy z {*v } ~ ƒ ˆ Š Œ Ž 5. Kravdokumentet (1.3) Skal beskrive følgende: Tjenester / funksjoner som systemet skal tilby Begrensninger som systemet må operere under Overordnede egenskaper for systemet (emergent properties) Grensesnitt til andre systemer som dette må integreres med Informasjon om anvendelsesområdet Mange måter å strukturere dette på Standarder fra IEEE, DoD Begrensninger på utviklingsprosessen Organisasjon kan ha egen standard IEEE Standard 830 (1993) 1. Introduksjon 1. Formål med dokumentet 2. Produktets omfang 3. Terminologi 4. Referanser 5. Oversikt over resten 2. Generell beskrivelse 1. Produktperspektiv 2. Produktfunksjoner 3. Brukerkarakteristikker 4. Generelle begrensninger 5. Antagelser og avhengigheter 3. De spesifikke kravene 4. Appendiks 5. Indeks Brukere av kravdokumentet Kunder Gi krav, sjekke om de stemmer med behov Ledelse (av utviklerfirma) Vurderer anbud, planlegger prosjekt Systemutviklere Forstå hva som skal lages Systemtestingeniører Utvikle systemtester Vedlikeholdsingeniører Forstå systemet og relasjoner mellom ulike deler 6. Hvordan skrive gode krav? (intro) De fleste organisasjoner skriver i naturlig språk Forståelig for alle grupper av lesere Stor, generell uttrykkskraft Ulemper Ikke entydig beskrivelse, potensielle misforståelser Vanskelig med automatisert analyse av krav Kan gi falsk følelse av mestring / enkelhet Vanlige problemer Komplekse undersetninger (hvis... ) Sløv, inkonsistent bruk av terminologi Implisitt kunnskap / antagelser 4

5 Hvordan skrive gode krav? (huskeregler) 1. Krav leses oftere enn de skrives Dvs. lønner seg å bruke mer tid på skriving for å optimalisere lesbarheten 2. Leserne har ulik bakgrunn Ikke regn med at de har samme kunnskap som deg! 3. Det er ikke lett å skrive klart og konsist! Utkast Gjennomgang (review) Forbedring Detaljnivå: avhengig av type krav, kundens forventninger, standarder osv. Hvordan skrive gode krav? (retningslinjer) Definer standard format for kravdokumentasjon Mer oversiktlig Reduserer sannsynligheten for å utelate viktig info Format kan variere noe for ulike krav Skriv enkelt, konsekvent og konsist Korte setninger og avsnitt, lister og tabeller Unngå sjargong, faguttrykk Bruk diagrammer for oversikt Supplementer med andre uttrykksformer Kvantifiser hvis mulig Gjelder særlig ikke-funksjonelle krav (dvs overordnede systemegenskaper) Eksempel på krav Ifbm et prosjekt for å skaffe et nytt ERP system for en større bedrift, fikk man i intervjuer med ulike interessenter typisk fram krav a la følgende: Fra brukere: Denne funksjonen må bli bedre enn i det gamle systemet Fra dataeksperter: Samme data må kun lagres ett sted, dvs. ingen duplisering. Ville dette vært gode eller dårlige krav? Hvorfor? Oppsummering Har gått igjennom Hva krav er Hvor kravspesifisering hører hjemme i en større utviklingssammenheng Hva kravdokumentet bør inneholde Noen retningslinjer for å skrive gode krav Neste gang Validering av krav (Requirements validation) 5 š