Föreläsning 4: Marknadsdriven kravhantering. Funktionella krav. Olika typer av krav Funktionella krav (FR) Kvalitetskrav (NFR)

Transkript

1 Föreläsning 4: Marknadsdriven kravhantering Funktionella krav Christin Lindholm Olika typer av krav Funktionella krav (FR) Anger vad et ska göra (input/ output) Kvalitetskrav (NFR) Sätter begränsningar på et (eller utvecklingsprocessen) Kan ofta slå tvärs över många funktioner Styr valet av arkitektur Fig 6.10 Maintainance Corrective maintenance Preventive maintenance Olika typer av kvalitetskrav Perfective maintenance Product New release Maintenance cycle: Report: Record and acknowledge. Analyze: Error, change, usability, mistake? Cost/benefit? Decide: Repair? reject? work-around? next release? train users? Reply: Report decision to source. Test: Test solution. Related defects? Carry out: Install, transfer user data, inform. O Användbarhet O Tillförlitlighet O Prestanda O Underhållbarhet O Säkerhet Skärmbilden ska synas på en meters håll T ex accepterad nertid T ex svarstider Krav på t ex designen T ex inloggning

2 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. Användarcentrerad utveckling Users Award Användarorganisation som arbetar för bättre IT-stöd i arbetslivet. Undersökning visade Sju av tio tillfrågade användare anser att: införandet av et 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 dataet underlättar arbetet eller bidrar till nytta i verksamheten Det blev tvärtom Det skulle ge mer tid till vård Det skulle vara arbetsbesparande 727 användare deltagit i undersökningen Olika yrkeskategorier 90% använt Cosmic Sjukvårdens nya data är fullt av fel och har ställt till stora problem för både personal och patienter

3 Cambio Healthcare s 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 et 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

4 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

5 Inte bara det uppenbara QFD kundcentrerad planering Tillfredställelse Sensationella Normala Uppfyllande Förväntade [Cohen] 17 Bertil, 47 år, mäklare 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 Fru, fyra barn Åker ofta till sommarhuset på landet 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

6 Konsumentprodukter Marknadsdriven kravhantering - en annan sorts elicitiering Marknadsdriven kravhantering några ytterliggare aspekter Modell av Moore 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]

7 Exempel på modell för marknadsdriven produktledning Fiktivt exempel: Operatörskrav till telefontillverkare Målnivå: Domännivå: Produktnivå: Designnivå: * Vi vill öka trafiken i nätet * Vi vill profilera oss som ledande på multimedia Telefonen ska stödja abonnenterna i att utväxla bilder Telefonen ska innehålla en kamera och kunna kommunicera med en hemdator Om man trycker på avtryckaren när linsskyddet är stängt skall bildvisningsläget aktiveras och då ska vår Vykortstjänst TM finnas som knapp i skärmens nedersta vänstra hörn med vår logotyp Ur produktutvecklarens synvinkel Vadå fullständig kravspec? Det är i praktiken omöjligt att specificera allt i minsta detalj! Vad är bra nog? -> Beror på situationen Tips: Fokusera på de krav som innebär störst risk för Missförstånd bland intressenter Att slutresultatet ej blir önskvärt/ stödjer behoven Konceptstudier, förstudier, möjlighetsstudier etc. för att minska risker hoppa mellan abstraktionsnivåer Kravstilar för Datakrav (anses ofta som en sorts funktionella krav): beskriver format för indata och utdata anger vad för information et ska lagra (Andra) Funktionella krav: beskriver mappning mellan indata och utdata beskriver hur information ska behandlas [Lau:2-5]

8 Helikoptervy över tekniker & stilar för funktionella krav Datakravstilar: ü Datamodell ( =E/R-diagr.) ü Dataordlista ü Reguljära uttryck ü Virtuella fönster Funktionella kravstilar: ü Kontextdiagram ü Händelse- & Funktionslistor ü Produktegenskapskrav ü Skärmbilder & Prototyper ü Uppgiftsbeskrivningar ü Egenskaper från uppgifter ü Uppgifter och stöd ü (Levande) Scenarier ü Högnivåuppgifter ü Användningsfall ü Uppgifter med data ü Dataflödesdiagram ü Standardkrav ü Krav på utvecklingsprocessen Funktionella detaljer: ü Enkla och sammansatta funktioner ü Tabeller & Beslutstabeller ü Textuella processbeskrivningar ü Tillståndsdiagram ü Övergångsmatriser ü Aktivitetsdiagram ü Klassdiagram ü Samarbetsdiagram ü Sekvensdiagram Speciella gränssnitt ü Rapporter ü Plattformskrav ü Produktintegration ü Tekniska gränssnitt Många olika stilar Datakravstilar: Datamodell (E/R-diagr.) Dataordlista Reguljära uttryck Virtuella fönster Läs grå rutan i Lau om alla stilar (så att ni minst vet vad de går ut på), samt för- & nackdelar Funktionella kravstilar: Kontextdiagram Händelse- & Funktionslistor Produktegenskapskrav Skärmbilder & Prototyper Uppgiftsbeskrivningar Egenskaper från uppgifter Uppgifter och stöd Scenarier Uppgifter på affärsnivå Användningsfall Uppgifter med data Dataflödesdiagram Standardkrav Krav på utvecklingsprocessen Fig 2.1 The hotel Fig 2.2A Data model R2: The shall store the following data: One-to-many (1:m) Task list Book guest Check in Checkout Change room Breakfast list & other services Data about Guests Rooms Services name, address1, address2, address3, passport stay#, paymethod, employee room#, #beds, type price1, price2 Guest Stay Room State Room Service date, count name, price Service Type date, #persons, state (booked occupied repair) Each guest connected to zero or more stays Guests Stays Each stay connected to one guest record

9 Fig 2.3 Data dictionary Fig 2.5 Virtual Windows Class: Guest [Notes a, b... refer to guidelines] The guest is the person or company who has to pay the bill. A guest has one or more stay records. A company may have none [b, c]. Customer is a synonym for guest, but in the database we only use guest [a]. The persons staying in the rooms are also called guests, but are not guests in database terms [a]. Examples 1. A guest who stays one night. 2. A company with employees staying now and then, each of them with his own stay record where his name is recorded [d]. 3. A guest with several rooms within the same stay. Attributes name: Text, 50 chars [h] The name stated by the guest [f]. For companies the official name since the bill is sent there [g]. Longer names exist, but better truncate at registration time than at print out time [g, j]. passport: Text, 12 chars [h] Recorded for guests who are obviously foreigners [f, i]. Used for police reports in case the guest doesn t pay [g]... R1: The product shall store data corresponding to the following virtual windows: R2: The final screens shall look like the virtual windows?? From: Soren Lauesen: Software Requirements Stay#: 714 Guest Name: John Simpson Address: 456 Orange Grove Victoria 3745 Payment: Visa Item #pers 7/8 Room 12, sgl /8 Breakf. rest /8 Room 11, dbl /8 Breakf. room /8 Room 11, dbl Breakfast 9/8 In In R# rest room Service charges Breakf. rest. 40 Breakf. room Rooms 7/8 8/8 9/8 10/8 11 Double Bath O B 12 Single Toil 600 O O B B 13 Double Toil B B B Fig 3.1 Human-computer - who does what? Fig 3.2 Context diagram guest s wishes guest name + chosen room# FindFree Room Domain model: parties joined guest s wishes Rooms FindFreeRoom period+room type User free rooms Physical model: work split Product R1: The product shall have the following interfaces: R2??: The reception domain communicates with the surroundings in this way: Receptionist booking, checkout, service note,... Receptionist Hotel confirmation, invoice Guest Reception Hotel Account Telephone Account guest name choice chosen room# Rooms Waiter Guest Accountant

10 Fig 3.3 Event list & function list Domain events (business events) R1: The product shall support the following business events / user activities / tasks: R1.1 Guest books R1.2 Guest checks in R1.3 Guest checks out R1.4 Change room R1.5 Service note arrives... Domain-product: many-to-many Product events R2: The product shall handle the following events / The product shall provide the following functions: User interface: R2.1 Find free room R2.2 Record guest R2.3 Find guest R2.4 Record booking R2.5 Print confirmation R2.6 Record checkin R2.7 Checkout R2.8 Record service Accounting interface: R2.9 Periodic transfer of account data... Fig 3.4 Feature requirements Fig 3.5A Screens & prototypes R1: The product shall be able to record that a room is occupied for repair in a specified period. R2: The product shall be able to show and print a suggestion for staffing during the next two weeks based on historical room occupation. The supplier shall specify the calculation details. R3: The product shall be able to run in a mode where rooms are not booked by room number, but only by room type. Actual room allocation is not done until checkin. R4: The product shall be able to print out a sheet with room allocation for each room booked under one stay. In order to handle group tours with several guests, it is convenient to prepare for arrival by printing out a sheet per guest for the guest to fill in. R1: The product shall use the screen pictures shown in App. xx. R2: The menu points and buttons shall work according to the process description in App. yy. Error messages shall have texts as in... Certificate: The requirements engineer has usability tested this design according to the procedures in App. zz. R3: Novice users shall be able to perform task tt on their own in mm minutes. The customer imagines screens like those in App. xx. Makes sense?

11 Fig 3.5B Screens & prototypes Fig 3.6A Task descriptions Appendix xx. Required screens Appendix yy. Required functions Stay window Book:... Checkin: If stay is booked, record the booked rooms as occupied. If stay is not recorded, Check selected rooms free and guest information complete. Record guest and stay. Record selected rooms as occupied. If stay is checked in,... Work area: 1. Reception Service guests - small and large issues. Normally standing. Frequent interrupts. Often alone, e.g. during night. Users: Reception experience, IT novice. R1: The product shall support tasks 1.1 to 1.5 Missing sub-task? Task: 1.1 Booking Purpose: Reserve room for a guest. Task: 1.2 Checkin Purpose: Give guest a room. Mark it as occupied. Start account. Trigger/ Precondition: A guest arrives Frequency: Average 0.5 checkins/room/day Critical: Group tour with 50 guests. Sub-tasks: 1. Find room 2. Record guest as checked in 3. Deliver key Variants: 1a. Guest has booked in advance 1b. No suitable room 2a. Guest recorded at booking 2b. Regular customer Task: 1.3 Checkout Purpose: Release room, invoice guest.... Fig 3.6B Triggers, options, preconditions Fig 3.7 Features from task descriptions Task: Look at your new s Purpose: Reply, file, forward, delete, handle later. Trigger: A mail arrives. - Someone asks you to look. - You have been in a meeting and are curious about new mail. Frequency:... Task: Change booking Purpose:... Precondition: Guest has booked? Trigger: Guest calls... Sub-tasks: 1. Find booking 2. Modify guest data, e.g. address (optional) 3. Modify room data, e.g. two rooms (optional) 4. Cancel booking (optional) Makes sense? From: Soren Lauesen: Software Requirements Work area: 1. Reception The product is normally operated standing, and there are many interruptions. R1.1 Product shall allow mouse-free operation. R1.2 Product shall support switching between incomplete tasks. The product must support checkin, i.e. the guest must get a room and a key, and accounting must start. R1.3 Product shall find free rooms of various types. R1.4 Product shall record checkin and rooms occupied by that stay. R1.5 Product shall collect pay information for the stay. R1.6 Product shall provide electronic keys. It may take too long time to check in a bus of pre-booked guests if they are checked in one by one. R1.7 Product shall print registration forms in advance for group stays.

12 Fig 3.8A Sub-tasks: 1. Find room. Problem: Guest wants neighbor rooms; price bargain. 2. Record guest as checked in. 3. Deliver key. Problem: Guest forgets to return the key; guest wants two keys. Variants: Tasks & Support Task: 1.2 Checkin Purpose: Give guest a room. Mark it... Frequency:... 1a. Guest has booked in advance. Problem: Guest identification fuzzy. Past: Problems Domain level Example solution: System shows free rooms on floor maps. System shows bargain prices, time and day dependent. (Standard data entry) System prints electronic keys. New key for each customer. System uses closest match algorithm. Future: Computer part Användningsfall och UML Grady Booch (Booch notation) James Rumbaugh (OMT object modeling technique) Ivar Jacobson (use cases) De tre amigos på Rational Andra ursprung till användningsfall: Scenario-based RE: Hsia, Potts, m.fl. Uppgiftsbeskrivningar från användbarhetsteknik. Användningsfall Use case modelling UML use case diagram: Receptionist actor Hotel Booking Checkin Checkout Transfer actor Account Aktör (actor) en kategori av användare, roll Användningsfall (use case) måluppfyllande användningssituation Scenario en specifik realisering Exempel: Bankomat: Ta ut pengar (stoppa in kort, knappa in kod...) Ordbehandling: Kontrollera stavning (välj stycke, välj ordlista...) Bra till vadå?

13 Fördelar med dynamiska modeller av vad användaren gör Lätt att förstå för icke-tekniska intressenter Bra för att modellera funktionella krav Hjälper till att strukturera krav Ger ett dynamiskt perspektiv på kraven Stödjer spårbarhet Bra grund för testfall Fallgropar För mycket detaljer överspecificering För lite detaljer underspecificering Fragmentering av information För tidig design Ej enhetliga beskrivningar o Olika form, detaljnivå, terminologi Inkonsekvenser o Motstridiga användningsfall Begränsad täckning av kraven (ofullständighet) Funktionell nedbrytning -> dålig OO design Begreppsförvirring Scenario= (1) En specifik realisering av ett användningsfall; en instans av ett användningsfall (2) En rik beskrivning av en specifik händelse; en liten novell med massor av detaljer (kallas av [Lauesen] för vivid scenario ) (3) Alla typer av exempelbaserade kravbeskrivningar, tex användningsfall á la UML (4) Möjliga framtida händelseförlopp (denna betydelse gäller ofta inom riskhantering) Dessutom finns det många olika sätt att beskriva användningsfall utöver Jacobson Fig 3.9 Vivid scenario Scenario: The evening duty Doug Larsson had studied all afternoon and was a bit exhausted when arriving 6 pm to start his turn in the reception. The first task was to prepare the arrival of the bus of tourists expected 7 pm. He printed out all the checkin sheets and put them on the desk with the appropriate room key on each sheet. In the middle of that a family arrived asking for rooms. They tried to bargain and Doug always felt uneasy about that. Should he give them a discount? Fortunately Jane came out from the back office and told them with her persuading smile that she could offer 10% discount on the children s room. They accepted, and Doug was left to assign them their rooms. They wanted an adjoining room for the kids, and as usual he couldn t remember which rooms were neighbors. Around 10 pm, everything was quiet, and he tried to do some of his homework, but immediately became sleepy. Too bad - he wasn t allowed to sleep at work until 1 AM. Fortunately the office computer allowed him to surf the net. That kept him awake and even helped him with some of his homework.

14 Fig 3.10 Good tasks Fig 3.11 High-level tasks Good tasks: Closed: goal reached, pleasant feeling Session: Small, related tasks in one description Don t program Examples: 1 Manage rooms? Frequent 2 Book a guest? mistake 3 Enter guest name? 4 Check in a bus of tourists 5 Stay at the hotel? 6 Change the guest s address etc? 7 Change booking? 8 Cancel entire booking? Got them all? All events covered? Critical tasks covered? At least as good as before? CRUD check How to deal with that? Task: 1. A stay at the hotel Actor: The guest Purpose:... Sub-tasks: 1. Select a hotel. Problem: We aren t visible enough. 2. Booking. Problem: Language and time zones. Guest wants two neighbor rooms 3. Check in. Problem: Guests want two keys 4. Receive service 5. Check out Problem: Long queue in the morning 6. Reimburse expenses Problem: Private services on the bill Example solution:? Web-booking. Choose rooms on web at a fee. Electronic keys. Use electronic key for selfcheckout. Split into two invoices, e.g. through room TV. Fig 3.13 Tasks with Data Fig 3.15 Standards as requirements Task: 1.2 Checkin Purpose: Give guest a room. Mark it as occupied. Start account. Trigger: Guest arrives Frequency: Average 0.5 checkins/room/day Critical: Group tour with 50 guests. Sub-tasks: Visible data Virt. windows 1. Find room Free rooms of kind x, price Rooms. Crit: kind, dates 1a. No suitable room All free rooms, Rooms. Crit: dates price, discount 1b. Guest booked Guest and stay details Stay. Crit: name Record guest Guest detail, chosen room Stay, Rooms as checked in 2a. Guest recorded Guest and stay details Stay at booking 2b. Regular customer Guest detail, chosen room Rooms, Stay. Crit: name Deliver key Room numbers Stay R1: Data transfer to the account package shall be done through a file with the format described in WonderAccount Interface Guide xx.yy. The account numbers shall be... R2: The user interface shall follow MS Windows Style Guide, xx.yy. The MS Word user interface should be used as a model where appropriate. R3: Shall run under MS-Windows release xx.yy. Supplier shall port product to new releases within months. R4: Shall follow good accounting practice. The supplier shall obtain the necessary certification. R5: The supplier shall update the payroll computations in accordance with new union agreements within one month after release of the agreement.

15 Fig 3.16 Development process as requirement R1: System development shall use iterative development based on prototypes as described in App. xx. Generates new requirements? R2: Supplier shall deliver additional screens with a complexity like screen S3 at a price of $ per screen. R3: All developers shall spend at least two days working with the users on their daily tasks. R4: A special review shall be conducted at the end of each development activity to verify that all requirements and goals are duly considered. The customer s representative shall participate in the review. Pla$formskrav Krav på vad produkten ska köra på nu och i framtiden o Hantera både nuvarande och planerade plattformar o Produkt och kontraktssituation påverkar de tekniska detaljerna Kan ge hög komplexitet R5: Customer and supplier shall meet at least two hours bi-weekly to review requests for change and decide what to do, based on cost/ benefit estimates of the changes. Fig 5.2 Platform requirements Fig 4.1 Complex and simple functions We have a platform R1: Product shall run on Pentíum PC s with 128 MB. Many older PC s still used, so tasks 2.1 to 2.5 must be supported on with 64 MB. R2: Our IT staff have expertice in Oracle. Product must use same database platform. R3: Product shall run on MS Windows release xx.yy. Supplier shall for 3 years port his product to new releases within months from release date. We want a new platform anyway R4: Customer expects to switch to client-server running OS zz. Supplier shall specify server memory and server speed needed to obtain capacity and response time for Rxx. We want software and hardware (maybe) R5: Supplier shall deliver hardware + software. Supplier shall upgrade if capacity becomes inadequate for the load specified in xx. R6: Product shall run on Pentium PC s with 128 MB. As an option, total delivery may include the PC s and hardware support. Simple program Interaction complexity Hard to program Domain obvious FindFreeRoom PrintInvoice Checkin if booked if non-booked if add room Fastest truck route Voice recognition? Suitable choices? Domain non-obvious Discount calculation Business rules Tax calculation Payroll Optimize roster Voice recognition? Possible requirement styles: A. (Leave to intuition) B. Natural language or tables C. Process description (algorithm) D. Performance specification E. Refer to laws and agreements

16 Fig 5.3A Who can integrate? Fig 5.4 Main contractor Customer??? Hotel Product supplier Account Customer s IT dept?? Main contractor Embedded 3rd party product Joint design work The optimal split. Exists? Willing? Cost vs. market DB sys Hotel Main contractor Account Telephone Sub-contractor Visible 3rd party product Tekniska gränssni$ Fig 5.5 Technical interfaces Hotel Account Krav på interaktionen mellan olika o Många olika sätt att specificera tekniska gränssnitt Kapacitet, prestanda. Använda prototyper Testa kommunicationen tidigt Communication channel Physical channel: File, TCP/IP, object calls... Message formats: Data descr, call params Protocol: State diagram, sequence diagram formal data descr, SDL... Semantics: about what? E/R, tasks, activity diagrams Verify early: Functional prototypes

17 Summering Goda kandidater för att använda i projektet: Data dictionary Virtual windows Context diagrams Screens & prototypes Feature requirements Tasks & Support Standards as requirements Development process requirements Att göra härnäst Övning 2 imorgon Övningen 3 på fredag Nästa vecka Föreläsning 5 Validering Övningen 4 Inför labb Förberedelse uppgift ligger på hemsidan Redovisas på labb Får inte göra labben om den inte är gjord Labb i sal C451 Grupp 2: den 4/10 kl Grupp 1: den 4/10 kl