PV7170 Föreläsning 4a Validering Kravhantering PV7170 Föreläsning 4a Validering

Verifiering och Validering Verifiering är processen som avgör om ett system eller modul motsvarar dess specifikation Validering är processen som avgör om ett system är lämpligt för sitt syfte Kravvalidering är det första steget för att se till att ett system är lämpligt för sitt syfte

Validering av krav Syfte För att kontrollera att vi har insamlat och dokumenterat de rätta kraven ”Bygger vi rätt system?” Metoder Inspektioner Checklistor Kravklassificeringar Prototyper Simulationer

Inspektioner Utvecklad av M.E. Fagan, IBM, 1970-talet En formell utvärderingsteknik där kraven manuellt undersöks i detalj av en grupp annan än utvecklaren för att hitta defekter Generella mål Hitta defekter Överföra kunskap Lärande från defekter

”N-fold” inspection Replikerar inspektionsaktiviteter med N oberoende lag Kravdokumentet ges till alla N lagen En moderator / ordförande leder alla lagen Varje lag genomför inspektioner med hjälp av en checklista Flera lag kan hitta samma defekter

”N-fold” inspection

Checklista Kravdokumentet Innehåller kravdokumentet följande: Sammanfattning Innehållsförteckning Funktionella krav Kvalitets krav Index Finns all refererad information tillgänglig?

Checklista Krav Innehåller kravet förtidig design eller implementationsinformation? Beskriver kravet ett enda krav eller kan det delas upp i flera olika krav? Är samma tjänst beskriven i andra krav? Kan olika krav grupperas tillsammans? Använder olika krav samma uttryck men på olika sätt?

Checklista Är kravet testbart? Finns tilltänkta (syften) ord utelämnade för att göra kravet testbart? Ex: Det tilltänkta är att en användare skall hitta information snabbt. För att göra den vaga beskrivningen testbar så tar man bort ”snabb”. Syftet är borttaget men kravet är testbart. Kan kravet realiseras men tillgänglig teknologi? Är kraven unikt identifierbara? Är specialtermerna definierade? Är dokumentet självständigt eller krävs det att man har tillgång till andra dokument för att förstå det?

Checklista Ord och grammatik Har varje ”den/det” och ”dess” en explicit och omisskännelig referens? Är komparativa former såsom ”tidigast”, ”senast” precisa och förståeliga Har alla ord samma innebörd för kunder, användare eller utvecklare? Kolla efter: Komplett, avsluta, nåbar, simultan, normal, önskad, osv.

Checklista Innehåller kravet ord som gör det icke-kvantifierbart? Ex.: Flexibel Modulär Effektiv Adekvat Möjlig Snabb Lite Ofta, vanligtvis

Kravklassificering Dela upp kraven i kategorier eller grupper För att se vad som är angränsande De hör möjligtvis ihop Och kanske skall ändras tillsammans För att se om det saknas några krav Tomma kategorier och grupper

Validering med prototyper Snabba prototyper (Throw-away prototyping) Utvecklande prototyper (Evolutionary prototyping) Arbetsgång Välj prototypmiljö Välj ut prototyptestare Utveckla testfall Genomför testfallen Dokumentera problem

PV7170 Föreläsning 4b Prioritering Kravhantering PV7170 Föreläsning 4b Prioritering

Behovet av prioritering ”Vad vi vill ha överstiger alltid det vi har råd med” ”Vi måste förbättra prestandan” ”Vi har inte tillräckligt med pengar” ”Vi måste möta de nya kundernas krav” ”Vi har inte tillräckligt med tid” ”Vi måste fixa problemen i programvaran” ”Vi har inte tillräckligt med personal”

Behovet av priortering Källa: Butler Group.

Behovet av prioritering 80-20-regeln Paretoprincipen (fåtal vitala, många enkla) 20% av kraven motsvarar 80% av värdet 20% av kraven motsvarar 80% av kostnaden 20% av kraven står för 80% av riskerna Vissa krav: Har högt värde men kostar lite, andra Har lågt värde men kostar mycket

Fördelar med prioritering Möjliggör identifiering av hög- och lågprioritering av krav Fokusera resurser på vad som är viktigt Implementation av de viktiga kraven först Skära ner på kostnader och utvecklingstid Genom att välja viktiga funktioner Genom att minimera konflikter med mindre viktiga krav Genom att tidigarelägga testning av de viktigaste funktionerna Möjliggör ”inkrement” för systemet

Prioriteringstekniker Klassificera på skala Högt, mellan eller lågt värde Väsentlig, förhandlingsbar eller önskvärd [IEEE830] 3, 2, 1 Tilldela värden 1-10 1-100 Fördela poäng Dela ut 100 poäng mellan kraven – ju mer poäng desto viktigare Multipla kriterium QFD Focal Point AB utvecklar ett verktyg för prioritering

Hantering av prioritetsförändring När ett nytt krav är identifierat Lägg till den till strukturen Jämför kravet med en del andra krav Kan man utifrån givna krav bestämma dess prioritet? Diskutera och besluta om det nya kravet skall inkluderas i planen eller inte

Omprioritering När nya krav kommer fram När det är dags för en ny version Med jämna intervaller I projektets olika faser När andra ändringar sker

PV7170 Föreläsning 4c Kravstyrning, (Management) Kravhantering PV7170 Föreläsning 4c Kravstyrning, (Management)

Omfattning Hanterar ändringar i krav Förändringspolicy Hanterar krav Enskilda krav Relationer mellan krav Versioner av krav Hanterar kravdokumentet Dokument Beroenden av andra dokument Hanterar spårbarhet

Procedurer Verktyg och tekniker för versionshantering Procedurer för nya och ändrade krav Hur de föreslås Hur de processas Hur de förhandlas Hur de kommuniceras ut till berörda

Procedurer (forts.) Hur utformas kraven? Styrning av kravens status Vem får lov att ändra? Status kontroll och rapporteringsförfarande Påverkansanalyser för ändrade krav Hur kravförändringar påverkar projektplaner och åtaganden

Kravdatabas Version- och ändringskontroll Relationer mellan krav (motsv. kravmatris) Ansluten till Projektplaneringsverktyg Testverktyg Exempel, RequsitePro

Flyktiga krav (Volatile requirements) Föränderliga Krav som förändras med systemmiljön T.ex. skattesystem ändras pga ändrade lagar Framträdande Krav som ändras efterhand som systemet klarare framträder T.ex. hur information skall presenteras Påföljande Krav som baseras på antagande som inte stämmer Användare anpassar sig till systemet och ”uppfinner” nya sätt att använda det →krav på ändringar Jämförbarhet Krav som är beroende på annan utrustning eller process, när dessa ändras medför det att kraven ändras En instrumentpanel behövs ändras om en ny display införs

Ändringsprocessen Hitta påverkade krav Hitta andra beroenden Kravlista Ändringsförslag Hitta andra beroenden Kontrollera önskemålets giltighet Kravändringslista Kundinformation Föreslå krav-ändring Rådfråga kund om kostnaden Kravändring Bedöm ändrings-kostnaderna Kostnads-information Kostnads-information Kundinformation

Initialt krav / intressent / affärsmål Spårbarhet Initialt krav / intressent / affärsmål ”Framåt-mot”-spårbarhet Krav-specifikation ”Framåt-från”-spårbarhet ”Bakåt-från”-spårbarhet ”Bakåt-mot”-spårbarhet Design / Produkt

Varför spårbarhet? För att Hitta källan till ett krav Hitta andra krav från samma källa Hitta var i designen kravet är implementerat Hitta vilka krav som påverkar en viss del i designen Hitta beroenden mellan krav Hitta beroenden mellan versioner av krav

Varför spårbarhet? Säkerställande! Har alla krav blivit implementerade? Påverkan? Vilka krav och delar av system påverkas av ändringar? Underhåll Var implementerar jag en ändring? Projektkontroll Vilken status har projektet? Återanvändning Vilka andra krav är gränsar till detta? Testning Var testar vi det här kravet?

PV7170 Föreläsning 4d Kravspecifikation, Arkitekturer Kravhantering PV7170 Föreläsning 4d Kravspecifikation, Arkitekturer

Kravspecifikationen Den viktigaste leverabeln ifrån kravprocessen Kan variera i form Text Grafiska modeller Formella specifikationer

Vem använder kravspecifikationen? Kunder och marknadsföringsavdelningen Projektledare Utvecklingsgrupper Testgrupper Underhållsgruppen / underhållsprojekt Dokumentalister Utbildare

Kravspecifikationens användare Produkt dokumentation Utbild- mtrl Utbildare Dokumentalister Underhålls- gruppen Produkt Kunder Krav- specifikation Utvecklings- gruppen Marknads- föringsavd. Projekt- ledaren Test- gruppen Projekt- plan Testspec.

Kravens relation till Projektplanen Bedömning av produktens storlek Problemanalys Bedömning av produktens komplexitet Design och kod Övergripande arkitektur Moduler Tester Use Cases Scenarios

Kvalitetsattribut Beakta kvalitetsattributen (kvalitativa krav) för att finna den lämpligaste arkitekturen Vad göra? Kvantifiera kvalitetsattributen Gör dem mätbara Prioritera kvalitetsattributen Välj lämplig arkitektur

Lämplig arkitektur Prestanda Strömlinjeformning Få indirekta nivåer Genvägar? Modifierbar / flexibel Fler indirekta nivåer Modularitet Underhåll Inga genvägar Portabilitet Hårdvaruabstraktioner Modularitet Användbarhet Särskilj användargränssnittet Följ standarder och ”look-and-feel”