PV7170 Föreläsning 1a Introduktion Kravhantering PV7170 Föreläsning 1a Introduktion

Lite statistik

Varför? ”The hardest single part of building a software system is deciding what to build” ”No other part of the work so cripples the resulting system if done wrong” ”No other part is more difficult to rectify later” [Brooks 1987, ”No silver Bullet: Essence and Accidents of Software Engineering”]

”Lagar” ”Requirements engineering is more difficult now, because all systems that were easy to specify have been built some time ago.” Tom DeMarco, Bonn 2001 ”Requirements deficiences are the prime source of project failures.” R.L. Glass, Software Runaways. Lessons Learned from Massive Software Failures, 1998 ”Errors are most frequent during the requirements and design activities and are the more expensive the later they are removed” B.W. Boehm, IEEE Transaction 1975

Standish Group (rapport 1994) 31% av alla projekt avbryts innan de är avslutade 52.7% av projekten kostar 189% av de ursprungliga kalkylerna Tre av de vanligaste faktorerna som anges som fällor i projekten var: Avsaknad av användarinput: 13% av alla projekt Ofullständiga krav och specifikationer: 12 % aap Ändrade krav och specifikationer: 12 % aap (Summa 37%...)

Standish Group (rapport 1994) 9% av projekten i stora företag levererades i tid och inom budget 16% av projekten i mindre företag levererades i tid och inom budget Tre av de vanligaste faktorerna som anges som fällor i projekten var: Involvering av användare: 16% av alla lyckade projekt (aalp) Ledningsstöd: 14% aalp Klara kravdefinitioner: 12% aalp

% Relativt storleken på problemet

Capers Jones undersökning… Defektursprung Defektpotential Effektiv borttagning Krav 1,00 77% Design 1,25 85% Implementation 1,75 95% Dokumentation 0,60 80% Felaktig kodrättning 0,40 70% Totalt 5,00

Kostnad för borttagande av fel

Vad göra? Formalisera och kontrollera Insamlingen av krav Specificeringen av krav Analys och förhandling av krav Testning med avseende på krav Hantering av krav

Vad är då ett krav? Definition (enligt IEEE): Ett tillstånd eller förmåga önskad av en användare för att lösa ett problem eller uppnå ett mål 2) Ett tillstånd eller förmåga som måste uppnås eller innehas av ett system eller system komponent för att uppfylla ett kontrakt, standard, specifikation eller något annat formellt dokument 3) En dokumenterad representation av ett tillstånd eller förmåga enligt 1) eller 2)

Definition av krav Enligt Sommerville and Sawyer (ISBN: 0-471-97444-7, sid 4, Requirements Engineering – A good practice guide) ”Requirements are … a specification of what should be implemented. They are descriptions of how the system should behave, or of a system property or attribute. They may be a constraint on the development process of the system”

Hur? Krav skall beskriva problem Inte lösa dem! Eftersom Det är svårt att lösa problem Om man löser dem så löser man dem ofta på ett icke-optimerat sätt Om man bara beskriver problemet så underlättar vi en optimerad lösning eftersom mängden möjliga lösningar är större

Varför är det så svårt? Krav är abstraktioner av verkligheten Ibland i flera led Krav innehåller ofta dold kunskap eller förutsätter viss grundinformation Jämför med: Försök att beskriva hur man cyklar Försök att beskriva hur man knyter skosnöre

Kravhantering Består av: Utveckling av krav genom en iterativ process Dokumentation av problem och krav Verifiering av förståelsen för kraven Och innehåller följande aktiviteter Identifikation och dokumentation av kund- och användarkrav Skapande och underhåll av ett dokument som sammanställer beteenden, behov och begränsningar Analys, verifiering och validering av kraven med avseende på konsekvens, fullständighet och realiserbarhet Iterativt och inkrementellt arbete

Kravhantering – huvudsaklig arbetsgång Identifiera intressenter Samla in krav Analysera och förhandla kraven med kunden Dokumentera kraven Verifiera och validera kraven Paketera på ett användbart sätt för utvecklingsfasen Möjliggör spårbarhet av krav Hantera och återanvänd krav Kontrollera att kraven uppfylls

Risker med svag kravhantering Otillräcklig inblandning av slutanvändare Flytande krav Tvetydiga krav Onödiga eller oönskade krav Minimalistiskt kravdokument Utelämnade / bortglömda användargrupper Otillräcklig information för planeringen av utvecklingen av systemet

Kravhantering och andra aktiviteter Planering Kontroll Konstruktion Kravhantering Dokumentation CM V & V