Innehåll. Kravhantering. Kravhantering TDDD06 Introduktion till kravhantering. Vad är kravhantering?

Transkript

1 Innehåll Kravhantering TDDD06 Introduktion till kravhantering Institutionen för datavetenskap (IDA) Linköpings universitet Kravhantering Omfattning Grundläggande koncept Aktörer Aktiviteter Artefakter Sida 2 Problemet och lösningen Problem world / machine solution Vad är kravhantering? World: rötterna till problemet finns i verkligheten som har fysiska, tekniska och organisatoriska delar Machine: det som ska installeras för att lösa problemet Programvara (utveckla/köpa) Hårdvara/mjukvara implementationsplattform, in/utdata-enhet (sensor, ) Kravhantering Machine :ns effekt på problemet Antaganden om world System: ett antal samverkande komponenter som strukturerar problemvärlden system-as-is, system-to-be och system-to-be-next Identifiera och analysera problem med ett befintligt system Identifiera och evaluera målet och alternativen för det nya systemet Identifiera och definiera funktionalitet och begränsningar hos det nya systemet Specificera och dokumentera för att kunna underhålla systemet Sida 3 Sida 4

2 Sida 5 Exempel Vad är kravhantering? Handbromssystem i bilar Lösa vissa problem med en programvara Problemförståelse Upptäck Förstå Formulera Analysera Vad ska lösas Varför ska det lösas Vem ska involveras Sida 6 Exempel: Transport mellan flygterminaler [Lamsweerde, 2009] Kravhantering i programvarulivscykeln Problem (system-as-is) Missade flyg Ökande passagerarantal Syfte, alternativ (system-to-be) Stöd för täta tågtransporter Med eller utan förare Funktionalitet, begränsningar Programvarubaserat tågkontrollsystem (fart, dörrar, ) Utdata: Kravspecifikation för system-to-be Att få rätt system Att få programvaran rätt Bild: an introduction to requirements engineering, I.K. Bray Sida 7 Sida 8

3 Sida 9 Varför-, vad- och vem-dimensioner Varför system-to-be behövs System-as-is Problem, domain kunskap Software-to-be Person Enheter Omgivning System-to-be Syfte Uppfylla Krav, Begränsningar, Antagandet Varför ett nytt system? Tilldelas Befintlig programvara Vad ska systemet innehålla? Vem ska göra vad? Förvärva domänkunskap Identifiera målet (system-to-be, verksamhetsmål, ) Flygplatsexempel Betjäna fler passagerare Minska transporttid mellan terminaler Svårigheter Alternativa sätt att uppfylla samma mål Olika tekniker Hantera motstridiga mål Sida 10 Vad system-to-be gör Vem gör vad Funktionalitet för att uppnå målet Realistiska antaganden Begränsningar (säkerhet, prestanda, ) Flygplatsexempel Beräkning av säker tågacceleration Meddelande till passagerare ombord Svårigheter Hitta rätt funktioner Specificera funktioner för alla intressenter Bakåtspårbarhet för systemmål Fördela ansvaret bland systemenheter Flygplatsexempel: Säker tågacceleration: förare eller vilken komponent i system-tobe? Uppskatta tågets hastighet och position: spårningssystem eller framförvarande tåg? Svårigheter Olika alternativ Rätt grad av automatisering Sida 11 Sida 12

4 Sida 13 Deskriptiva respektive normativa formuleringar Funktionella och icke-funktionella krav om tågets dörr är öppen, så är den inte stängd om tågets acceleration är positiv, så är tågets hastighet inte noll e.g. naturlag, fysiskt tvång Dörrar skall vara stängda när tåget rör sig System-to-be :s effekt på omgivningen Tågets styrprogram skall kontrollera accelerationen av alla tåg i systemet Tågets dörrar skall öppnas enbart när tåget har stannat helt Systemkrav respektive Programvarukrav Hur ska system-to-be uppfylla ett funktionellt krav Accelerationskommandon skall skickas till varje tåg var tredje sekund Sida 14 Kravhanteringsprocessen Kvalitet i kravhanteringsprocessen och kravdokumentet Domain understanding & elicitation Consolidated requirements Quality assurance Alternative proposals Start Documented requirements Evaluation & negotiation Agreed requirements Specification & documentation Fullständighet (completeness) Konsekvens (consistency) Ändamålsenlighet (adequecy) Tydlighet (unambiguity) Mätbarhet (measurability) Relevans (pertinence) Genomförbarhet (feasibility) Begriplighet (comprehensibility) Strukturering (structuring) Förändringsbarhet (modifiability) Spårbarhet (traceability) Sida 15 Sida 16

5 Sida 17 Kravhanteringsprocessen i olika projekt Varför kravhantering? Greenfield/Brownfield Helt ny programvara byggd från scratch Förbättra, utöka, befintlig programvara Customer-driven/Market-driven Att ta hänsyn till kunds behov Att hantera de potentiella behoven i ett helt marknadssegment In-house/Outsourced Samma företag genomför alla projektfaser Underleverantörer genomför olika delar Single project/product-line En produktversion utvecklas En familj av produkter utvecklas Viktigt Misslyckad programvara (kravrelaterade fel) Allvarliga konsekvenser (kostnad, fördröjning, olyckor, ) Flera effekter (legal, social, ekonomisk, teknisk)a Svårt Bredden Flera systemversioner (as-is, to-be, to-be-next) Hybridmiljö Multipla aspekter (funktionalitet, kvalitet, utvecklingsaspekter) Multipla abstraktionsnivåer Sida 18 Varför är kravhantering svårt? Bygga system utan att tänka på kravhantering? Multipla intressenter (multiple stakeholders) Bakgrund Intresse och konflikter Flera olika uppgifter under iterativ elicitering, utvärdering, specificering Konflikthantering Riskhantering Prioritering Kvalitetssäkring Förändrad förväntan Tidigare erfarenheter Projektstorlek och komplexitet Känd problemdomän Mindre kritiskt problem Sida 19 Sida 20

6 Sida 21 Kravproblem Kravproblem: Standish report, 1995 Survey of 350 US companies, 8000 projects Kostnad Dålig kravhantering 50 % Sida 22 Kravproblem: Standish report, 1995 Kravproblem: European survey, 1996 Täckning: 3800 EU organisationer, 17 länder Huvudsakliga programvaruproblem Kravspecifikation > 50 % Kravevolution (Requirements evolution management) 50 % [European Software Institute, 1996] Sida 23 Sida 24

7 Sida 25 Kravproblem Kravdokumentet i utvecklingsprocessen Failure % Project estimations (size, cost, schedules) Call for tenders, proposal evaluation Project contract Project workplan Follow-up directives 100 other causes Software prototype, mockup Requirements Document Software architecture 50 requirements-related Acceptance test data Quality Assurance checklists Implementation directives User manual Software evolution directives Software documentation Impacts on [J. Maresco, IBM developerswork, 2007] Sida 26 Kravhanteringseffekter Kravhantering i agila utvecklingsprocesser Tekniska effekter Acceptanstest Arkitektur Kvalitetssäkringschecklista Handbok Evolution (programvara) Ledningsrelaterade effekter Legala effekter Manifesto for Agile Software Development Tidigt och kontinuerligt tillhandahållande av funktionalitet som är mest värd för kunden Minska kravhanteringsarbete och krav-till-kod-avståndet Sida 27 Sida 28

8 Sida 29 Kravhantering i agila utvecklingsprocesser Sammanfattning Viktiga funktionella tillägg direkt från användaren Specifikation = testfall på implementation Litet team på samma plats, nära användaren för omedelbar feedback, enligt strikta regler Stakeholder = slutanvändaren Litet projekt Mindre dokumentationsarbete Kravförändringar kommer inte att kräva mycket code refactoring Vad är kravhantering? Kravhantering och problem world Vad-, varför- och vem-dimensioner Deskriptiva och normativa formuleringar Funktionella och icke-funktionella krav Spiralformad process Olika betoning på kravhanteringsfaser beroende på projekt Kravhanteringseffekter på andra artefakter Varför kravhantering? Kravhantering i utvecklingsprocesser More/less agility is achievable by less/more weight in elicitation, evaluation, documentation, consolidation phases of RE cycles [Lamsweerde, 2009] Sida 30