Föreläsning 3: Elicitering, Kvalitetskrav

Transkript

1 Föreläsning 3: Elicitering, Kvalitetskrav Christin Lindholm Kravhantering rep o Krav kommer från intressenter o Det finns många olika typer av krav o En av de viktigaste delarna av utvecklingsprocessen o Kravprocessen innehåller Elicitering (Identifikation) Analys Dokumentation (Specifikation) Validering Prioritering Ändringshantering Diskussion Elicitering Varför är elicitering i verkliga projekt svårt?

2 Som kund/beställare Fig 8.1 Elicitation issues Should be simple. Ask stakeholders what they need! 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 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 Intervjuer Ställer frågor till en eller flera intressenter Förmodligen vanligaste tekniken Enskilda och gruppvisa intervjuer Strukturerade Semi-strukturerade Ostrukturerade 7

3 Strukturerade Förbestämda frågor, ev. förbestämda svarsalternativ systematisk och effektiv 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 Kan förbereda frågeformulär eller checklista innan Kan komplettera med öppna frågor Ta reda på fakta om intressenter innan Ostrukturerade Inga förberedda frågor alt. några få öppna frågor. Berätta om din syn på..? Får frågorna utförligt besvarade Krävs lite förberedelser och träning Kostnadseffektivt 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?

4 Fig 8.4 Focus groups Enkät forts. Använd gärna ja och nej frågor, skalor samt varje dag, en gång i veckan etc. Många personer på kort tid Andra saker än vid intervjuer 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 Observationer Prototyper Sitter och observerar användaren i dennes miljö. Inga omfattande förberedelser Kan hitta alla typer av krav Svårt att få möjlighet till det Avbrott av annat Identifiera nya krav Kvalitetssäkra krav o Kortare utvecklingstid o Mer rätt från början o Kräver planering och förberedelse

5 Några tekniker till Card sorting Card Sorting - kategorisering Laddering begreppsnätverk Scenario-analys händelsesekvenser Etnografiska studier långtidsobservation För att arbeta fram en informationsstruktur Antal påstående om t.ex. problem, innehåll -> sorterar dem i kategorier Fördelar: God översikt över användarens syn på problemet Nackdelar: Kräver domänkunskap för gruppering Laddering Skapa förståelse för olika termer. Kan användas som underlag för terminologi Hierarkisk bild över termerna Kravhanteraren kommer med olika påståenden kring termerna. Laddering forts o Bra förståelse för termer och begrepp o Medvetandegör olika tolkningar o Onödigt om termer och begrepp är välkända Vid missuppfattning flyttas termerna runt

6 Scenario - analys Användningsfalls modellering Beskriver systemet genom att beskriva hur systemets aktörer använder sig av funktioner Scenario analys forts. Bra teknik för normala krav Andra saker än vid intervjuer Kräver förmåga att hitta relevanta användningsfall Förhållandevis hög inlärningströskel Fig 8.5 Business goals Shipyard goals. Business administration A1. Replace outdated platform P A2. Integrate order documents and database P A3. Use experience data for quotation D A4. Support systematic marketing D A5. Faster capture of cost data Q A6. Speed up invoicing Q Hospital goals. Payroll and roster planning B1. Reduce IT costs Personnel department B2. Automate some tasks B3. Remove error sources B4. Observe deadlines B5. Less trivial work and less stress Hospital department B6. Reduce over- and undertime payment B7. Faster roster planning B8. Improve roster quality Tax payer s association. Membership adm. C1. We cannot do without it. Noise source location. New product D1. Marketing plan. Demand, competitors... Att gå från domän till krav Fig 8.8 Quality-issue analysis Example: Shipyard, usability Issue: Job calculation easy to learn. Style: Task time. Req. outline: After xx hour course, marketing staff can perform task yy in zz minutes. Req., final: After hour course, marketing staff can calculate proposal B in minutes. Customer expects 12 hour course. How can we tell? How can we measure it? What are xx, yy, and zz?

7 I praktiken behöver man iterera fritt mellan olika aktiviteter och jobba parallellt med olika saker Spårbarhet Elicitering Specificering Validering Bakåt Req A1:Printing Beroende Framåt package samples.simple; public class Hello1 { public void printhello() { Prioritering Källa Req F8: Color Krav System.out.println( "Hello!" ); } } Design/Kod/Test 26 Fig 1.3 Contents of ReqSpec Fig 1.5A Domain and product level User groups Interfaces System Platform: HW, OS, DB Spreadsheet Ext. products: Sensors, dev. Special SW Data requirements: System state: Database, comm. states Input/output formats Functional requirements, each interface: Record, compute, transform, transmit Theory: F(input, state) -> (output, state) Function list, pseudocode, activity diagram Screen prototype, support tasks xx to yy Quality reqs: Performance Usability Maintainability... Other deliverables: Documentation Install, convert, train... Managerial reqs: Delivery time Legal Development process... Helping the reader: Business goals Definitions Diagrams... Business domain Clients Domain I/O User activities Domain Domain-level req: The product shall support the following user activities:... Product Product I/O Platform Control computers Actors? Elevators Product-level reqs: The product shall accept the following input:...

8 Fig 1.5B Redefined limits Fig 1.6A The goal-design scale Business domain Domain R1. Our pre-calculations shall hit within 5% Goal-level requirement Mål-nivå Syfte, affärsmål, vinst, användarnytta Clients User activities Product Control computers R2. Product shall support cost recording and quotation with experience data R3. Product shall have recording and retrieval functions for experience data Domain-level requirement Product-level requirement Domän-nivå Samverkan användare och produkt -> nytta, sammanhang, omgivning Produkt-nivå Funktioner och egenskaper observerbara externt R4. System shall have screen pictures as shown in app. xx Design-level requirement Design-nivå Specifik utformning av produktens innehåll Boken Lauesens stilar & tekniker i relation till processen: Specificering Olika stilar för att specificera funktionella krav: Lau:2-5 Olika stilar för att specificera kvalitetskrav: Lau:6 Elicitering Olika tekniker för att identifiera kraven: Lau:8 Validering Olika tekniker för att kontrollera kraven: Lau:9 Lausens bok fungerar som en katalog över olika stilar & tekniker med information om i vilka sammanhang de passar bra/dåligt Olika typer av krav Funktionella krav (FR) o Anger vad systemet ska göra (input/output) Kvalitetskrav (NFR) o o o Sätter begränsningar på systemet (eller utvecklingsprocessen) Kan ofta slå tvärs över många funktioner Styr valet av arkitektur

9 FR & NFR hänger ihop Olika typer av kvalitetskrav I praktiken är funktionella krav och kvalitetskrav svåra att separera då kvalitetskraven manifesterar sig i extra funktionalitet. Användbarhet Tillförlitlighet Skärmbilden ska synas på en meters håll T ex accepterad nertid Exempel: kvalitetskrav om säkerhet kräver inloggningsfunktion Prestanda Underhållbarhet T ex svarstider Krav på t ex designen Säkerhet T ex inloggning Diskussion Vilka kvalitetsegenskaper värdesätter du hos en ordbehandlare? Svåra avvägningar mellan kvalitetskrav Kvalitetsaspekter ofta motverkande. Vanliga exempel: Ökad prestanda -> minskad underhållsbarhet Ökad säkerhet -> minskad användbarhet Kräver noggrant övervägda avvägningar!

10 Kvalitetskraven styr arkitekturvalet REQ REQ REQ REQ Kostnad? Värde? Långsiktigt vs kortsiktigt? Produktarkitektur GUI A C L1 L2 B D DB Requirements measures Property Speed Size Ease of use Reliability Robustness Portability Measure Processed transactions/second User/Event response time Screen refresh time K Bytes Number of RAM chips Training time Number of help frames Mean time to failure Probability of unavailability Rate of failure occurrence Availability Time to restart after failure Percentage of events causing failure Probability of data corruption on failure Percentage of target dependent statements Number of target systems Fig 6.1 McCall US Airforce 1980 Operation: Integrity Correctness!! Reliability Usability Efficiency Revision: Maintainability Testability Flexibility Transition: Portability Interoperability Reusability!! Quality factors ISO 9126 Functionality Accuracy Security Interoperability Suitability!! Compliance!! Reliability Maturity Fault tolerance!! Recoverability!! Usability Efficiency Maintainability Testability Changeability Analysability!! Stability!! Portability Adaptability Installability!! Conformance!! Replaceability!! Use as check lists Fig 6.2 Quality factors for Hotel system Quality grid Critical Operation Integrity/security Correctness Reliability/availab. 1 Usability 2 Efficiency Revision Maintainability Testability Flexibility Important As usual Unimportant Ignore Transition Portability Interoperability 3 4 Reusability Installability 5 Concerns: 1. Hard to run the hotel if system is down. Checking in guests is impossible since room status is not visible. 2. We aim at small hotels too. They have less qualified staff. 3. Customers have many kinds of account systems. They prioritize smooth integration with what they have. 4. Integration with spreadsheet etc. unimportant. Built-in statistics suffice. 5. Must be much easier than present system. Staff in small hotels should ideally do it themselves.

11 Summering o Vilka är intressenterna? o Varför är elicitering så svårt? o 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