Kravprocessen som. Project Challenge Factors ETS672. Engineer. Lärandeprocess Underrättelseverksamhet Beslutsprocess

Transkript

1 Kravprocessen som ETS672 Requirem ents Engineer ing Lärandeprocess Underrättelseverksamhet Beslutsprocess L2: Elicit ation 2 Krav, kravhantering, kravprocessens delar Elicitering Analys När göra vad? Hur? När färdig? Specifikation Validering Behov Mål Idéer Önskemål Strategier Konkurrenter Project Challenge Factors Standish Group Survey Chaos Report Top 10 Challenges Dokumenterade representationer av krav Prioritering Planering Ändringshantering Används för Planering Design Test Lack of User Input 2. Incomplete Requirements 3. Changing Requirements 4. Lack of Executive Support 5. Technology Incompetence 6. Lack of Resources 7. Unrealistic Expectations 8. Unclear Objectives 9. Unrealistic Time Frames 10. New Technology 3 4 [Standish Group]

2 Krav på krav Precist och otvetydigt Tydligt och begripligt (för vem?) Komplett Korrekta Genomförbara Testbara Ej redundanta Krav är direkt avgörande För följande aktiviteter: Planering och kostnads uppskattning Design- och arkitekturbeslut Veri=iering och validering 5 6 Systemet ska vara användarvänligt Hur testar man detta? 4 av 5 nya användare kan boka en gäst inom 5 min efter att... Ingen unik identifierare Tänk även på... Använd inte inte Vad betyder deras, den, det...? Vad menas med snabbare, lagom, minst...? Vad menas med ibland, ofta, vanligen...? Använd inte osv, t. ex, etc... Och oftast två krav Definiera i terminologi Unik identifierare 7 8

3 Krav lätta att missa Funktionalitet för att stänga av systemet Behörigheter Felmeddelande Larm när fel inträffar Loggning vid fel Krav på utvecklingsmetod Hantering vid överbelastning Finns det några undantag från normal användning Krav på dokumentation Krav på hjälptexter Krav på leverans Olika sammanhang och projekttyper Internutveckling för egna behov (In-house) Produktutveckling för öppen marknad (Product Dev.) Utveckling på löpande räkning (Time&Materials) Inköp av generisk (hyll-)programvara (COTS) Kundspecifik anpassning av generisk programvara Anbudsförfrågan (Tender) för upphandling av kundspecifik utveckling för upphandling av generisk programvara Kontraktsbaserad utveckling med fast/rörligt pris Underleverantörskontrakt med fast/rörligt pris Okänd förstudie för att utreda lämplig projekttyp Hybrider kombinationer av ovanstående Sammanhanget är avgörande för kravhanteringen! 9 10 Övergripande kravspec först Vad är ett krav? Önskemål Måste Begränsning Behov? Produktegenskap Funktion Dokumenterad representation Beslut 12

4 Intressenter (stakeholders) är personer eller roller som direkt eller indirekt påverkas av systemet Exempel: Användare olika typer Kunder, kundens kunder Underleverantörer Marknadsförare Säljare Systemarkitekter Utvecklare Testare Produktledare Who are the stakeholders? 14 External stakeholders Internal stakeholders Customers Direct customers Operators Global customers Regional customers Other key customers Retailers Indirect customers Consumers Market segments Service providers Content providers Product providers Direct Competitors Mobile phone developers Indirect Competitors Cameras Mobile music players consumer wallet competition Platform providers Operating Systems Technical Platforms Network system providers Standardization bodies Legislation and authorities National International Manufacturing sub-contractors Component providers Marketing Long term branding Customer relations Product management Product planning Roadmapping and portfolios Product development Hardware design Electronics Analog Digital Mechanics Software design User interface Service logic Network access Codecs Platform development Mother, daughter, cluster Global functions Sub-contracting management Technical platforms Operating systems Original Design Manufacturing Technology forecasting Market research Customer Services Support Repair Legal Sourcing Accessories 15 PlayNow find the right person to talk to get the deep domain knowledge En avgörande förutsättning för lyckad kravhantering är god domänkunskap

5 Inlåsning Vem lyssnar när man ringer och klagar på att det inte funkar? Ömsesidigt förhållande kund - leverantör Vem har störst makt? Vem har störst kunskap? [Hof] Vem tar största risken? Vem får största vinsten? På kort sikt? På lång sikt? Ömsesidig nytta? 19

6 Intressenter Användare olika typer Kunder, kundens kunder Underleverantörer Marknadsförare Säljare Systemarkitekter Utvecklare Testare Produktledare Distributions kanaler Återförsäljare Lösningsleverantörer som bygger på er produkt Konkurrenter 21 Identifiera vem ni behöver prata med Intressentanalys Vem/vilka Domänkunskap Teknisk bakgrund Utmärkande egenskaper Önskemål Prioriteringar Begränsningar Av Henrik Kniberg

7 Undersökning visade Sju av tio tillfrågade användare anser att: införandet av systemet inte sker med tillräcklig medverkan från användare och verksamhet användarnas förslag till förbättringar inte tas tillvara. De flesta användare är missnöjda med hur datasystemet underlättar arbetet eller bidrar till nytta i verksamheten Av Henrik Kniberg Users Award Användarorganisation som arbetar för bättre IT-stöd i arbetslivet. 727 användare deltagit i undersökningen Olika yrkeskategorier 90% använt Cosmic Det blev tvärtom Det skulle ge mer tid till vård Det skulle vara arbetsbesparande Sjukvårdens nya datasystem är fullt av fel och har ställt till stora problem för både personal och patienter

8 Cambio Healthcare systems En patient en journal Med en enkel knapptryckning kommer åt allt journaler, remisser, recept Vunnit upphandlingar i 7 landsting (investeringar i miljardklass) Fel felrapporter skickade av personalen i Uppsala som använt systemet under 2 åren efter leverans. Cambios vd Tomas Mora Morrison erkänner ej nådd leveransprecision och vissa kvalitetsproblem Exempel på fel: Provsvar försvinner Patienten felaktigt markerad som avliden Journalanteckningar hamnar i fel journal Doseringar omkastade på e-recept Prestanda problem Dåliga flöden i applikationen Cambio höll inte vad de lovade. Bara hälften av de krav man tecknat kontrakt om uppfylldes fullt ut. Trots det godkände Värmlands landsting leveranserna och betalade slutfakturan

9 Tänk på Betamax VHS You cannot sit in your office and produce requirements based on intuition and logic. You have to discover the nontrivial requirements from users and other stakeholders. (Lausen, page 42) Fig 1.6B Ask why Fig 1.6C Recommendation: why + how Neural diagnostics System shall have mini keyboard with start/stop button,... Why? Possible to operate it with left hand. Why? Both hands must be at the patient. Why? Electrodes, bandages, painful... Measuring neural response is a bit painful to the patient. Electrodes must be kept in place... So both hands should be at the patient during a measurement. R1: It shall be possible to perform the commands start, stop,... with both hands at the patient. Might be done with mini keyboard (wrist keys), foot pedal, voice recognition, etc. Domain - why Req. Example - how From: Soren Lauesen: Software Requirements Pearson / Addison-Wesley 2002 From: Soren Lauesen: Software Requirements Pearson / Addison-Wesley 2002

10 Inte bara det uppenbara Diskussion Elicitering Varför är elicitering i verkliga projekt svårt? Tillfredställelse Sensationella Normala Uppfyllande Förväntade [Cohen] 37 Som kund/beställare Svårt att veta vad man vill ha Först när man ser en lösning förstår man vad man vill ha Ofta tyvärr inte det som man trodde man beställt Fig 8.1 Elicitation issues Should be simple. Ask stakeholders what they need! Barriers: Cannot express what they need Cannot explain what they do and why May ask for specific solutions Lack of imagination - new ways Lack of imagination - consequences Conflicting demands Resistance to change Luxury demands New demands once others are met Things to elicit - intermediate work products: Present work, Present problems Consequences and risks Goals and critical issues Commitment, Conflict resolution Future system ideas Requirements, Priorities Realistic possibilities Completeness From: Soren Lauesen: Software Requirements Pearson / Addison-Wesley 2002

11 Intervjuer Ställer frågor 8ll en eller flera intressenter Förmodligen vanligaste tekniken Enskilda och gruppvisa intervjuer Strukturerade Semi-strukturerade Ostrukturerade 41 Strukturerade Förbestämda frågor, ev. förbestämda svarsalternativ Fördelar: systematisk och effektiv Nackdelar: mindre flexibel i valet av frågor risk för ledande frågor inte lägga till frågor under tiden Semi-strukturerade Vissa frågor är förberett men frihet i ordning och djup Fördelar: Kan förbereda frågeformulär eller checklista innan Kan komplettera med öppna frågor Nackdelar: Ta reda på fakta om intressenter innan

12 Ostrukturerade Inga förberedda frågor alt. några få öppna frågor. Berätta om din syn på..? Fördelar: Får frågorna utförligt besvarade Krävs lite förberedelser och träning Kostnadseffektivt Nackdelar: Intervjuaren behöver styra Risk för att tid läggs på oväsentligheter Enkät Hitta krav som beställaren inte är medveten om eller vid utvärdering av system Ställer frågor till många personer Frågans formulering viktig Hur upplever du systemets prestanda och stabilitet? Hur upplever du systemets prestanda? Enkät forts. Använd gärna ja och nej frågor, skalor samt varje dag, en gång i veckan etc. Fig 8.4 Focus groups Fördelar: Många personer på kort tid Andra saker än vid intervjuer Nackdelar: Krävs mycket av dem som skriver frågorna En chans Several stakeholder groups Brainstorm - bad experience Brainstorm - wishes & ideal future Each group selects top ten issues A few days later: Decide. Each group must get something From: Soren Lauesen: Software Requirements Pearson / Addison-Wesley 2002

13 Observationer Sitter och observerar användaren i dennes miljö. Fördelar: Inga omfattande förberedelser Kan hitta alla typer av krav Nackdelar: Svårt att få möjlighet till det Avbrott av annat Identifiera nya krav Kvalitetssäkra krav Prototyper Fördelar: Kortare utvecklingstid Mer rätt från början Nackdelar: Kräver planering och förberedelse Summering Summering Kravhantering Krav kommer från intressenter Det finns många olika typer av krav En av de viktigaste delarna av utvecklingsprocessen Processen innehåller ofta Elicitering (Identifikation) Analys Dokumentation (Specifikation) Validering Prioritering Ändringshantering 51 Vilka är intressenterna? Varför är elicitering så svårt? Eliciteringstekniker vs Saker att elicitera Barriers: Cannot express what they need Cannot explain what they do and why May ask for specific solutions Lack of imagination - new ways Lack of imagination - consequences Conflicting demands Resistance to change Luxury demands New demands once others are met