Olika typer av krav ETS672 Requirements Engineering Lecture 4: Functional Requirements Christin Lindholm 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 Olika typer av kvalitetskrav O Användbarhet O Tillförlitlighet O Prestanda Skärmbilden ska synas på en meters håll T ex accepterad nertid T ex svarstider 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. O Underhållbarhet O Säkerhet Krav på t ex designen T ex inloggning Användarcentrerad utveckling
Fiktivt exempel: Operatörskrav till telefontillverkare Vadå fullständig kravspec? Det är i praktiken omöjligt att specificera allt i minsta detalj! 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 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 Fig 6.8A Threats Fig 6.9 Security requirements Wire tapping Product Curious eyes Payslip R1: Safeguard against loss of database. Estimated losses to be < 1 per 50 years. R2: Safeguard against disk crashes. Estimated losses to be < 1 per 100 years. R3: Product shall use duplicated disks (RAID disks). Wire tapping Disk crash R4: Product shall safeguard against viruses that delete files. Remaining risk to be <. R5: Product shall include firewalls for virus detection. 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 From: Soren Lauesen: Software Requirements R6: Product shall follow good accounting practices. Supplier shall obtain certification. R7: Product shall prevent users deleting invoices before transfer to the account. R8: The supplier shall as an option offer features for checking and reserving deposits made by credit cards. R9: The supplier must enclose a risk assessment and suggest optional safeguards.
Fig 6.10 Maintainance Fig 6.11A Maintainability requirements Risk Corrective maintenance Perfective maintenance Product New release Preventive maintenance 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. Maintenance performance R1: Supplier s hotline shall analyze 95% of reports within 2 work hours. Urgent defects (no work around) shall be repaired within 30 work hours in 95% of the cases. R2: When reparing a defect, related non-repaired defects shall be less than 0.5 in average. R3: For a period of two years, supplier shall enhance the product at a cost of per Function Point. Support features R4: Installation of a new version shall leave all database contents and personal settings unchanged. R5: Supplier shall station a qualified developer at the customer s site. R6: Supplier shall deposit code and full documentation of every release and correction at. Cust. Suppl 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] 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 Fig 2.1 The hotel Datakravstilar: Funktionella kravstilar: Datamodell (E/R-diagr.) Kontextdiagram Dataordlista Händelse- & Funktionslistor 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 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 Task list Book guest Check in Checkout Change room Breakfast list & other services Data about Guests Rooms Services Fig 2.2A Data model Fig 2.3 Data dictionary R2: The shall store the following data: 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) One-to-many (1:m) Each guest connected to zero or more stays Guests Stays Each stay connected to one guest record 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]
Fig 2.5 Virtual Windows Fig 3.1 Human-computer - who does what? 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 1 600 8/8 Breakf. rest 1 40 8/8 Room 11, dbl 2 800 9/8 Breakf. room 2 120 9/8 Room 11, dbl 2 800 Breakfast 9/8 In In R# rest room 11 2 12 1 13 1 1 Service charges Breakf. rest. 40 Breakf. room 60 Rooms 7/8 8/8 9/8 10/8 11 Double Bath 800 600 O B 12 Single Toil 600 O O B B 13 Double Toil 600 500 B B B guest s wishes guest name + chosen room# FindFree Room guest s wishes Domain model: parties joined Rooms guest name FindFreeRoom period+room type User chosen room# free rooms choice Physical model: work split Product Rooms Fig 3.2 Context diagram R1: The product shall have the following interfaces: Receptionist booking, checkout, service note, Hotel confirmation, invoice Guest Account Telephone Biljettautomat Ett där du ska kunna hitta den snabbaste vägen från gata A i stad x till gata B i stad Y R2??: The reception domain communicates with the surroundings in this way: Receptionist Reception Hotel Account boka biljetter betala biljetter skriva ut biljetter Kopplas till boknings på webben Waiter Guest Accountant
Fig 3.3 Event list & function list Fig 3.4 Feature requirements 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 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. Fig 3.5A Screens & prototypes Fig 3.5B Screens & prototypes 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? 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,
Fig 3.6A Task descriptions Fig 3.6B Triggers, options, preconditions 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. Task: Look at your new e-mails 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 Fig 3.7 Features from task descriptions Fig 3.8A Tasks & Support 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. Task: 1.2 Checkin Purpose: Give guest a room. Mark it Frequency: 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: 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 UML use case diagram: Hotel Grady Booch (Booch notation) James Rumbaugh (OMT object modeling technique) De tre amigos på Rational Ivar Jacobson (use cases) Receptionist actor Booking Checkin Checkout Transfer actor Account Andra ursprung till användningsfall: Scenario-based RE: Hsia, Potts, m.fl. Uppgiftsbeskrivningar från användbarhetsteknik Användningsfall Use case modelling Aktör (actor) en kategori av användare, roll Användningsfall (use case) Scenario måluppfyllande användningssituation en specifik realisering Exempel: Bankomat: Ta ut pengar (stoppa in kort, knappa in kod...) Ordbehandling: Kontrollera stavning (välj stycke, välj ordlista...) 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 Bra till vadå?
Fallgropar För mycket detaljer överspecificering För lite detaljer underspecificering Fragmentering av information För tidig design Ej enhetliga beskrivningar Olika form, detaljnivå, terminologi Inkonsekvenser 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 Fig 3.10 Good tasks 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. Good tasks: Closed: goal reached, pleasant feeling Session: Small, related tasks in one description Don t program 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. 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?
Fig 3.11 High-level tasks Fig 3.13 Tasks with Data 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. 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... 2. 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... 3. Deliver key Room numbers Stay Fig 3.15 Standards as requirements Fig 3.16 Development process as requirement 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. 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. 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 80486 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 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
Fig 5.5 Technical interfaces Hotel Account Summering Goda kandidater för att använda i projektet: 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 Data dictionary Virtual windows Context diagrams Screens & prototypes Feature requirements Tasks & Support Standards as requirements Development process requirements Att göra härnäst Inför labb Övning 2 i eftermiddag och imorgon Övningen 3 imorgon och på onsdag Nästa vecka Föreläsning 5 Validering Övningen 4 Förberedelse uppgift ligger på hemsidan Redovisas på labb Får inte göra labben om den inte är gjord Labb i sal C452 Grupp 1: den 30/9 kl. 13-15 Grupp 2: den 3/10 kl. 15-17