ETS672 Requirements Engineering Lecture 3: Quality Requirements Christin Lindholm Kravhantering rep. Krav kommer från intressenter Det finns många olika typer av krav En av de viktigaste delarna av utvecklingsprocessen Kravprocessen innehåller Elicitering (Identifikation) Analys Dokumentation (Specifikation) Validering Prioritering Ändringshantering Repetition Varför är elicitering svårt? 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 Repetition Vilka är intressenterna? Eliciteringstekniker vs Saker att elicitera
Några tekniker till Card Sorting - kategorisering Laddering begreppsnätverk Scenario-analys händelsesekvenser Etnografiska studier långtidsobservation Card sorting 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 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. Kravhanteraren kommer med olika påståenden kring termerna. Vid missuppfattning flyttas termerna runt Vid missuppfattning flyttas termerna runt
Laddering forts Fördelar: Bra förståelse för termer och begrepp Medvetandegör olika tolkningar Nackdelar: Onödigt om termer och begrepp är välkända Scenario - analys Användningsfalls modellering Beskriver systemet genom att beskriva hur systemets aktörer använder sig av funktioner Scenario analys forts. Fördelar: Bra teknik för normala krav Andra saker än vid intervjuer Nackdelar: 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 I praktiken behöver man iterera fritt mellan olika aktiviteter och jobba parallellt med olika saker Issue: Job calculation easy to learn. Style: Task time. How can we tell? Specificering Req. outline: After xx hour course, marketing staff can perform task yy in zz minutes. How can we measure it? Req., final: After hour course, marketing staff can calculate proposal B in minutes. Customer expects 12 hour course. What are xx, yy, and zz? Elicitering Validering Prioritering QFD kundcentrerad planering Vem är användarna? O Ringa in och kartlägg användarna O Skapa personas O Framstå som en riktig person O Namn O Bild O Beskrivning O Relevanta beteenden O Attityd O Behov O Mål
Bertil, 47 år, mäklare Fru, fyra barn Åker ofta till sommarhuset på landet Spårbarhet Sara, 28 år, IT-konsult Ensamstående Kör till vänner Ingegärd, 39 år, rörmokare Hund Bor i en mindre by Kör rör och verktyg Källa Bakåt Req A1:Printing Beroende Req F8: Color Krav Framåt package samples.simple; public class Hello1 { public void printhello() { System.out.println( "Hello!" ); } } Design/Kod/Test 18 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:...
Fig 1.5B Redefined limits Fig 1.6A The goal-design scale Business domain Clients User activities Domain Product Control computers R1. Our pre-calculations shall hit within 5% R2. Product shall support cost recording and quotation with experience data R3. Product shall have recording and retrieval functions for experience data R4. System shall have screen pictures as shown in app. xx Goal-level requirement Domain-level requirement Product-level requirement Design-level requirement Marknadsdriven kravhantering - en annan sorts elicitiering Marknadsdriven kravhantering några ytterliggare aspekter Aspekt Marknadsdriven Kundspecifik Kravinsamling Uppfinna krav. Marknad eller Identifiering, Analys, teknikmöjligheter. Validering Kravspecifikation Mindre formell Kontrakt Användare Svårdefinierade Kända Kunder Marknadsfolk, nyckelkunder Beställare Huvudintressent Utvecklande organisation Kundens organisation Specifika kravfokus Strid ström av krav, prioritering, releaseplanering Konfliktlösning, validering, modeller Utvecklare - Produkt Långsiktig investering Kortsiktig bindning Validering Sent, t.ex. på mässor Kontinuerlig Kravstandard Ovanligare Vanligare Explicit process Ovanligare Vanligare Iterativa tekniker Vanligare Ovanligare Domänexpertis Ovanligare okänd mark Vanligare Fritt efter [Pär Carlshamre, Dissertation No. 726, Linköpings Univ. 2001]
Modell av Moore Exempel på modell för marknadsdriven produktledning Ur produktutvecklarens synvinkel 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) Anger vad systemet ska göra (input/ output) Kvalitetskrav (NFR) Sätter begränsningar på systemet (eller utvecklingsprocessen) Kan ofta slå tvärs över många funktioner Styr valet av arkitektur
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 Svåra avvägningar mellan kvalitetskrav Diskussion Vilka kvalitetsegenskaper värdesätter du hos en ordbehandlare? Kvalitetsaspekter ofta motverkande. Vanliga exempel: Ökad prestanda -> minskad underhållsbarhet Ökad säkerhet -> minskad användbarhet Kräver noggrant övervägda avvägningar!
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.
Fig 6.3A Open metric and open target Distanskurs i multimedia Ett etablerat företag har beslutat utvidga sin verksamhet till att också omfatta distansutbildning via Internet. Det ska utvecklas en interaktiv distanskurs i multimedia. Kursen ska i första hand finnas i webbform på företagets egen webbserver. Målgruppen för kursen är: Tjänstemän inom den offentliga sektorn. Kursen bör innehålla följande: Bildbehandling: En orientering inom området t.ex. olika filformat, skillnad bitmaps/vektorgrafik. Ev tutorial Design: Orientering om grundläggande design och bildkomposition. Ev tutorial Interaktiva media: En orientering inom området. Flash, interaktiv 3D. Ev tutorial Ljud: En orientering inom området. Filformat, sampling. Ev tutorial Kursens form: Distanskursen ska ha en form som i största möjliga mån engagerar och aktiverar kursdeltagare Physical limits Best available is 4 minutes? Nobody strives for 2 minutes Open target but how important? Open target + expectations Supplier uses another approach? Open metric R1: Product shall detect speed violation and take photo within 0.5 seconds. R2: Product shall compute a room occupation forecast within 2 minutes. R3: Product shall compute a room occupation forecast within 4 minutes. R4: Product shall compute a room occupation forecast within minutes. R5: Product shall compute a room occupation forecast within minutes. (Customer expects one minute.) R6: Forecast shall be computed with exponential trend smoothing and seasonal adjustments. R7: The supplier shall specify the forecast accuracy for hotels similar to ours. Fig 6.3C Cost/benefit of response time Fig 6.4 Capacity and accuracy requirements $ or ratio 2 1 1 2 3 4 min Response time Capacity requirements: R1: The product shall use < 16 MB of memory even if more is available. R2: Number of simultaneous users < 2000 R3: Database volume: #guests < 10,000 growing 20% per year #rooms < 1,000 R4: Guest screen shall be able to show at least 200 rooms booked/occupied per day, e.g. for a company event with a single customer. Accuracy requirements: R5: The name field shall have 150 chars. R6: Bookings shall be possible at least two years ahead. R7: Sensor data shall be stored with 14 bit accuracy, expanding to 18 bits in two years. R8: The product shall correctly recognize spoken letters and digits with factory background noise % of the time. Tape B contains a sample recorded in the factory.
Fig 6.5A Performance requirements Performance requirements: R1: Product shall be able to process 100 payment transactions per second in peak load. R2: Product shall be able to process one alarm in 1 second, 1000 alarms in 5 seconds. R3: In standard work load, CPU usage shall be less than 50% leaving 50% for background jobs. R4: Scrolling one page up or down in a 200 page document shall take at most 1 s. Searching for a specific keyword shall take at most 5 s. R5: When moving to the next field, typing must be possible within 0.2 s. When switching to the next screen, typing must be possible within 1.3 s. Showing simple report screens, less than 20 s. (Valid for 95% of the cases in standard load) R6: A simple report shall take less than 20 s for 95% of the cases. None shall take above 80s. (UNREALISTIC) Cover all product functions? Användbarhet 1) Relevans. Stöder arbetsuppgifter? 2) Effektivitet. Snabbt och problemfritt? 3) Tillgänglighet. Lätt hitta nödvändig information? 4) Lärbarhet. Enkelt att lära sig? 5) Attityd. Subjektiv tillfredsställelse. Fig 6.6D Defects & usability factors Fig 6.6A Usability Defect correction Program errors Usability problems Expected Surprising? Inspection OK Inspection low hit-rate Detect in test stage Detect in design stage Mostly simple Often redesign Test equipment OK Subjects hard to find Usability Fit for use = tasks covered + Ease of use = Ease of learning Task efficiency Ease of remembering Subjective satisfaction Understandability Functional requirements Usability factors Usability requirements? R1: System shall be easy to use?? R2: 4 out of 5 new users can book a guest in 5 minutes, check in in 10 minutes,... New user means... Training... Achieving usability Prototypes (mockups) before programming. Usability test the prototype. Redesign or revise the prototype. Easier programming. High customer satisfaction. Defect types Program error: Not as intended by the programmer. Missing functionality: Unsupported task or variant. Usability problem: User cannot figure out...
Fig 6.6B Usability problems Fig 6.6C Usability test & heuristic evaluation Examples of usability problems P1: User takes long time to start search. Doesn t notice Use F10. Tries many other ways first. P2: Believes task completed and result saved. Should have used Update before closing. P3: Cannot figure out which discount code to give customer. Knows which field to use. P4: Crazy to go through 6 screens to fill 10 fields. Problem classification Task failure: Task not completed - or believes it is completed. Critical problem: Task failure or complaints that it is cumbersome. Medium problem: Finds out solution after lengthy attempts. Minor problem: Finds out solution after short attempts Usability test Realistic introduction Realistic tasks Note problems Observe only or Think aloud & ask Heuristic evaluation Expert s predicted problems Inspection/Review Usability test: Cover all tasks? Mockups find same problems as test with final system? Log keeper Heuristic evaluation User Usability test findings Facilitator Real problems Fig 6.7(A) Usability requirements Problem counts R1: At most 1 of 5 novices shall encounter critical problems during tasks Q and R. At most 5 medium problems on list. Task time R2: Novice users shall perform tasks Q and R in 15 minutes. Experienced users tasks Q, R, S in 2 minutes. Keystroke counts R3: Recording breakfast shall be possible with 5 keystrokes per guest. No mouse. Opinion poll R4: 80% of users shall find system easy to learn. 60% shall recommend system to others. Score for understanding R5: Show 5 users 10 common error mesages, e.g. Amount too large. Ask for the cause. 80% of the answers shall be correct. Risk Cust. Suppl Fig 6.8A Threats Wire tapping Wire tapping Product Disk crash Threats Violate Preventions Input, e.g. Examples Mistake Integrity Logical checks Illegal access Authenticity Signature Wire tapping Confidentiality Encryption Storing, e.g. Disk crash Availability RAID disks Program error Integrity Test techniques Virus deletes data Availability Firewall Output, e.g. Transmission Availability Multiple lines Fraud Confidentiality Auditing Virus sends data Authenticity Encryption Curious eyes Payslip From: Soren Lauesen: Software Requirements
Summering Kvalitetskrav O Specificera hur väl systemet utför sina funktioner O Många kvalitetsfaktorer: Prestanda, tillförlitlighet O Öppna eller stängda metrics O Risk för kunder eller leverantör? O Användbarhetsfaktorer Relevans. Stöder arbetsuppgifter? Effektivitet. Snabbt och problemfritt? Tillgänglighet. Lätt hitta nödvändig information? Lärbarhet. Enkelt att lära sig? Attityd. Subjektiv tillfredsställelse.