Inför labb. Föreläsning 5 Funktionella krav forts Validering. Övningarna. Fortsättning. Christin Lindholm

Transkript

1 Föreläsning 5 Funktionella krav forts Validering Christin Lindholm Inför labb Förberedelseuppgift ligger på hemsidan Redovisas på labb Får inte göra labben om den inte är gjord Labb den 12 oktober kl i sal C452 Övningarna Eliciterat information Intressentanalys/Målgrupp/Användare Funktionella krav Kvalitetskrav Risker Validera Prioritera Fortsättning Uppdatera information efterhand under projektets gång Handledning 6 november utkast kravspec Inlämning senast 5 november kl Handledning 17 december färdig kravspec Inlämning senast 13 december kl Övrig handledning

2 Inlämning Färdig kravspecifikation skickas in via mail till senast den 20/12 kl Mapp lämnas in senast den 20/12 kl (vån C6) Material från övningarna med kompletteringar Övrigt material om så önskas 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 Konceptstudier, förstudier, möjlighetsstudier etc. för att minska risker hoppa mellan abstraktionsnivåer Krav på olika nivå Goal-level requirement Mål-nivå krav Bakomliggande syfte, affärsmål, användarnytta, effekt, vinst Domain-level requirement Domän-nivå krav Sammanhang, omgivning, hur användarna och produkten samverkar för att ge nytta Product-level requirement Produkt-nivå krav Externt observerbara funktioner och egenskaper Design-level requirement Design-nivå krav Specifik utformning av produktens innehåll

3 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,...

4 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 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 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.

5 Användningsfall och UML UML use case diagram: Hotel Grady Booch (Booch notation) James Rumbaugh (OMT object modeling technique) Ivar Jacobson (use cases) De tre amigos på Rational Andra ursprung till användningsfall: Receptionist actor Booking Checkin Checkout Transfer actor Account 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) 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å? 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

6 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?

7 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 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 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.

8 Fig 5.2 Platform requirements Plattformskrav Krav på vad produkten ska köra på nu och i framtiden Hantera både nuvarande och planerade plattformar Produkt och kontraktssituation påverkar de tekniska detaljerna Kan ge hög komplexitet 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. Fig 4.1 Complex and simple functions Fig 5.3A Who can integrate? Domain obvious Domain non-obvious Simple program FindFreeRoom PrintInvoice Discount calculation Business rules Customer??? Customer s IT dept Interaction complexity Checkin if booked if non-booked if add room Tax calculation Payroll Hotel Account? Hard to program Fastest truck route Voice recognition? Optimize roster Voice recognition? Main contractor Suitable choices? 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 Product supplier?

9 Fig 5.4 Main contractor Embedded 3rd party product DB sys Hotel Account Visible 3rd party product Tekniska gränssnitt Krav på interaktionen mellan olika Många olika sätt att specificera tekniska gränssnitt Main contractor Telephone Kapacitet, prestanda. Joint design work The optimal split. Exists? Willing? Cost vs. market Sub-contractor Använda prototyper Testa kommunicationen tidigt Fig 5.5 Technical interfaces Hotel Account Antal krav 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 Skala Antal krav Litet 10 Medium 100 Stor 1000 Mycket stor

10 Exempel på kravattribut för krav i en kravdatabas Helikoptervy över tekniker & stilar för funktionella krav Attribute State ID Source Description Priority Motivation Specification Decomposition Estimation Schedule Design Test Release Ver Value Unique identity Who issued it? Short textual description Importance cathegory (1,2,3) Rationale: Why is it important? Links to Use Case, Textual spec, Prototype Parent-of / Child-of links to other req s Effort estimation in hours Selected for this release, must /wish-lists Links to design documents Links to test documents Released in this version Assigned in State New New New Approved Approved Evaluated Evaluated Evaluated Planned Implemented Verified Released 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 Uppföljning genom förädlingskedja för produktkrav Laxtrappan Verifierat Lanserat Spårbarhet (Traceability) Ändringar i intressenternas behov, önskemål och tekniska antaganden kan kräva radikal omvärdering av kravens relevans. Ansvar för kravuppfyllelse behöver kopplas till komponenter så att ansvarighet och påverkansanalys kan utrönas Godkänt Värderat Planerat Implementerat Dubblett Källa Framåt till krav Bakåt från krav Requirements document Req A1: Printing Dependecy Req F8: Color Framåt från krav Bakåt till krav package samples.simple; public class Hello1 { public void printhello() { System.out.println( "Hello!" ); } } Design/ Kod/Test Nytt Otydligt Omöjligt Hur intressenterna medverkat till kraven är viktig information vid validering. Kravuppfyllelse behöver verifieras och design utan krav ( gold-plating ) behöver undvikas.

11 Validering - Verifiering Fig 7. Inception Requirements in product life cycle Elicitation Validering - kontroll gentemot egentlig avsikt - Är det rätt? - Uppfyller vi kundens behov och förväntningar? Formulation Checking Tender Writing proposal Verifiering - kontroll gentemot specifikation - Är et rätt? - Har vi gjort det vi sa vi skulle göra? Design & program Contract Comparing proposals Accept test Next release Reqs management & release planning Validering av krav Syfte Att säkerställa att vi har eliciterat och dokumenterat rätt krav Kommer vi att bygga rätt med dessa krav? Metoder Granskningar Tester Modellbaserad simulering Härledning med matematiska modeller Diskussion Vad finns på önskelistan för kvalitetsegenskaper hos en kravspecifikationen? Men man kan inte få allt

12 Fig 9.1 Quality criteria for a specification Fig 9. Checking and validation Classic: A good requirement spec is: Correct Each requirement reflects a need. Complete All necessary requirements included. Unambiguous All parties agree on meaning. Consistent All parts match, e.g. E/R and event list. Ranked for importance and stability Priority and expected changes per requirement. Modifiable Easy to change, maintaining consistency. Verifiable Possible to see whether requirement is met. Traceable To goals/purposes, to design/code. Additional: Traceable from goals to requirements. Understandable by customer and developer. Korrekt Fullständig Otvetydig Motsägelsefri Rankad Modifierbar Verifierbar Spårbar bakåt/framåt Begriplig Motiverad Koncis Välorganiserad From: Soren Lauesen: Software Requirements Goals E/R Tasks Guest Event list Check that all parts match & everything is included Validate that stakeholders are happy (customer, user, developer) Where are the major risks? Quality product = meeting the spec? Correct Each requirement reflects a need. Complete I vilka moment måste All necessary requirements included. man involvera kunden/ Unambiguous användaren? All parties agree on meaning. Consistent All parts match, e.g. E/R and event list. Ranked for importance and stability Priority and expected changes per requirement. Modifiable Easy to change, maintaining consistency. Verifiable Possible to see whether requirement is met. Traceable To goals/purposes, to design/code. Jävla skit Hej! Systemet har nu blivit uppdaterat + bilaga Jonas Söderström