ETSN15 Kravhantering

Transkript

1 ETSN15 Kravhantering Lecture 2: Elicitation: Lau:8 Specification part 1: Data reqts: Lau:2, Funtional reqts part 1: Lau: Course ombudsman volunteers Instructions on exam problem hand-ins Björn Regnell

2 Different contexts and project types In-house Internutveckling för egna behov Product Development Produktutveckling för öppen marknad, t.ex. inbyggda system, generella appar för en marknad (COTS develpment), etc. Time & Materials Utveckling på löpande räkning, rörligt pris Commercial Off-The-Shelf software purchase (COTS purchase) Inköp av generisk (hyll-) programvara Customization Kundspecifik anpassning av generisk programvara Tender Anbudsförfrågan Customer specific: för upphandling av kundspecifik utveckling Generic (COTS): för upphandling av generisk programvara Contract development Kontraktsbaserad utveckling med fast/rörligt pris Sub-contracting Underleverantörskontrakt med fast/rörligt pris Unknown, pre-study Okänd, förstudie för att utreda lämplig projekttyp Hybrid kombinationer av ovanstående...? The context is critical to the requirements engineering!

3 The goal-design scale: Goal/Domain/Product/Design Why? Who? What? How? Model( Goal("accuracy") has Spec("Our pre-calculations shall hit within 5%"), Feature("quotation") has Spec("Product shall support cost recording and quotation with experience data"), Function("experienceData") has Spec("Product shall have recording and retrieval functions for experience data"), Design("screenX") has Spec("System shall have screen pictures as shown in Fig. X"))

4 Evolving mix of levels of detail & quality in continuous requirements engineering Level of detail, specification quality

5 [cird/{spsi, gprc, fdqt, rrcr}] context who intentions why? requirements what! delivery

6 reqt process box {learn, model, check, decide} [esvs] elicitation learn specification model validation check selection decide

7 Elicitation: [Lau:8] Get out there and dig up reqts! 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] PROVOKING AN UNDERSTANDING

8 Fig 1.6B Ask why 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... From: Soren Lauesen: Software Requirements Pearson / Addison-Wesley 2002

9 Deep domain knowledge is critical to successful requirements engineering!!

10 Fig 1.6C Recommendation: why + how 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 From: Soren Lauesen: Software Requirements Pearson / Addison-Wesley 2002

11 Why+How+Example Model( ) Feature("navigate") has ( ) Why( "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."), Spec( "It shall be possible to perform the commands start, stop,... with both hands at the patient."), Example( "Might be done with mini keyboard (wrist keys), foot pedal, voice recognition, etc.")

12 Discussion Elicitation Why is elicitation so challenging in real projects? Björn Regnell

13 Fig 8.1 Elicitation issues Should be simple. Ask stakeholders what they need! 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 From: Soren Lauesen: Software Requirements Pearson / Addison-Wesley 2002

14 Fig 8.2 Stakeholder analysis (Group) interview Observation Task demo Document studies Questionnaires Brainstorm Focus groups Domain workshops Design workshops Prototyping Pilot experiments Similar companies Ask suppliers Negociation Risk analysis Cost / benefit Goal-domain analysis Domain-reqs analysis Elicitation techniques Present work Present problems Goals & key issues Future system ideas Realistic possibilities Consequences & Commitment Conflict resolution Requirements Priorities Completeness Nuläge Framtid Åtagande&samsyn Krav & deras värde Studier av & med (enskilda) intressenter eller dokument Förberedda gruppaktiviteter Exekvering av system Omvärldsanalys Avvägningar, risker, analys av kopplingar mellan nivåer From: Soren Lauesen: Software Requirements Pearson / Addison-Wesley 2002

15 Stakeholder analysis (intressentanalys) Example: In-house (internprojekt) Sponsors want value for their money Users at different departments Managers at different departments Authorities, security managers, accountants etc. System management and support, Other indirect stakeholders that may provide valuable input Example: product development: Distribution channels and retailers Solution providers building on your product Competitors

16 Interviews in requirements elicitation On or more stakeholders are interviewed by a requirements engineer (aka analyst) Probably the most common elicitation method. Reflect on pros and cons with... Individual or group interviews? Structured: prepared questions and perhaps also response alternatives Semi-structured: some Q prepared, but freedom in order and depth Unstructured: no preconceived closed questions; open questions to start off: What is your view on the system? Intervjuer för att elicitera krav En eller flera intressenter tillfrågas av en kravingenjör. Förmodligen den vanligaste metoden. För och nackdelar med Enskilda eller gruppvisa intervjuer? Strukturerade: förbestämda frågor, ev förbestämda svarsalternativ Semi-strukturerade: vissa frågor är förberett men frihet i ordning och djup Ostrukturerade: inga förberedda frågor alt. några få öppna frågor Berätta om din syn på systemet?

17 Fig 8.4 Focus groups 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 From: Soren Lauesen: Software Requirements Pearson / Addison-Wesley 2002 Concrete example in Lau:10.2

18 Fig 8.5 Business goals Shipyard goals. Business administration A1. Replace outdated platform A2. Integrate order documents and database A3. Use experience data for quotation D A4. Support systematic marketing D A5. Faster capture of cost data Q A6. Speed up invoicing Q P P 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 Noise source location. New product D1. Marketing plan. Demand, competitors... From: Soren Lauesen: Software Requirements Pearson / Addison-Wesley 2002

19 Fig 8.6 Cost/benefit analysis Shipyard NPV Y0 Y1 Y2 Y3 Y4 Hard benefits m$ Avoided losses More orders Hard costs Supplier s price Hardware Staff training Enter exp. data Net value Soft factors Now Future IT flexibility 0 3 Customer comm. 3 4 Stress absence 1 3 Total points 4 10 (Scale 0-5) From: Soren Lauesen: Software Requirements Pearson / Addison-Wesley 2002

20 Fig 8.7A Goal-domain tracing - critical areas Replace IT platform Integrate doc and data Experience data Systematic marketing Capture cost data Speed up invoicing Marketing Quotation Prod.planning Cost registr. Invoicing... Payroll IT operations Usability Response time = This work area / quality factor is critical for this goal Goal requires improvement in this work area or quality area För varje affärsmål: Vilka subdomän säkerställer måluppfyllnad? För varje subdomän: Vad är dess syfte i relation till affärsmålen?

21 Att gå från domän till krav Fig 8.8 Quality-issue analysis Example: Shipyard, usability Issue: Style: Job calculation easy to learn. 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? From: Soren Lauesen: Software Requirements Pearson / Addison-Wesley 2002

22 In practice you need to iterate and work in parallel Specification Elicitation Validation Selection

23 Specifying functional requirements

24 Overview of techniques for functional requirements (Swedish terms) Datakravstilar: Datamodell ( =E/R-diagr.) Dataordlista Reguljära uttryck Virtuella fönster First read the gray box of all styles so that you understand what they are about and their pros and cons. Then read in depth as needed. 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

25 All techniques have + and - depending on the context When is a specific style good? The answer depends on abstraction level project type the stakeholders tool support the amount of requirements Use a well-balanced combination! but how do you know that it all fits together? -> checking consistency is an important part of validation!

26 Data requirements Data model (e.g. E/R-diagrams) Data dictionary Data expressions Virtual windows Example data from the mobile domain: Subscriber data, roaming data, phone book data, image data (when, resolution, name, category), music data (album, artist, genre, name, frequency played, rating), etcetera

27 Data requirements techniques Summary Data model (E/R-diagr.) Block diagram describing data inside and outside the product Precise and insensitive to abstraction level Excellent for experts difficult for users; takes time to learn Easy to verify by experts that the data is handled by the product Difficult to decide how much detail should be included in the model Data dictionary Textual description of data inside and outside the product Structured and systematic descriptions using verbal text Very expressive, can be used for all levels of detail and special cases Easy to validate by experts and non-experts Takes long time to write; when is it good enough? (Start with difficult parts!!) Data expressions (regular expressions) Compact formulas for describing data sequences Useful for composite data and message protocolls Excellent for experts, acceptable for many users No visual overview Virtual windows Simplified screens with graphics and realistic data, but no buttons and menues Excellent for both experts and users Easy to validate and verify Risk of overdoing it and start designing the user interface passport number = letter + {digit}*8 room state = { free booked occupied repair } account data = transfer + {account record}* + done

28 Fig 2.1 The hotel system Task list Book guest Checkin Checkout Change room Breakfast list & other services Data about Guests Rooms Services From: Soren Lauesen: Software Requirements Pearson / Addison-Wesley 2002

29 Fig 2.3 Data dictionary 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: passport: 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]. 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]... From: Soren Lauesen: Software Requirements Pearson / Addison-Wesley 2002

30 Data dictionary example Lau: fig 2.3

31 Fig 2.2A Data model (E/R-diagram) R2: The system 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) From: Soren Lauesen: Software Requirements Pearson / Addison-Wesley 2002 Entities and Relationships One-to-many (1:m) Each guest connected to zero or more stays Guests Stays Each stay connected to one guest record Cardinality of relations

32 Fig 2.4A Data expressions Notation with plus as concatenator booking request = guest data + period + room type guest data = guest name + address + paymethod + [passport number] passport number = letter + {digit}*8 room state = { free booked occupied repair } account data = transfer + {account record}* + done From: Soren Lauesen: Software Requirements Pearson / Addison-Wesley 2002

33 Fig 2.5 Virtual Windows R1: The product shall store data corresponding to the following virtual windows: R2: The final screens shall look like the virtual windows?? 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 From: Soren Lauesen: Software Requirements Pearson / Addison-Wesley 2002 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

34 Course ombudsmen volunteers? A course ombudsman collects experiences and improvement suggestions during the course and gives this feedback to the teachers Any course member are encouraged to talk to the teachers about how the course works! When the Course Experience Questionnaire (CEQ) is ready, the two ombudsmen meets with the course head and discusses the working report and writes a short summary. D och eller C:are och någon/några från annat program? C: Elin Sakurai D:??

35 Functional Requirements Part 1 Summary Context Diagram Diagram of product and its surrounding Defining product scope Very useful! Event- and function lists Lists of events and functions Domain or product level Good as checklists at verification Validation at product level? Receptionist booking, checkout, service note,... Hotel system confirmation, invoice Guest R1: The product shall support the following business events / user activities / tasks: R1.1 Guest books R1.2 Guest checks in R1.3 Account system Telephone system Feature requirements Textual requirement: the product shall High expressive power Acceptable to most stakheolders Can lead to false sense of security How to ensure that goal-level covered? R1: The product shall be able to record that a room is occupied for repair in a specified period. R2: The product shall. R3: The product shall. Screens and Prototypes Screen pictures + what buttons do Excellent as design-level requirements if carefully tested Not good when for COTS-based systems

36 Fig 3.1 Human-computer - who does what? guest s wishes FindFree Room Domain model: parties joined guest name + chosen room# Rooms Physical model: work split guest s wishes FindFreeRoom period+room type guest name User free rooms choice Product From: Soren Lauesen: Software Requirements Pearson / Addison-Wesley 2002 chosen room# Rooms

37 Fig 3.2 Context diagram R1: The product shall have the following interfaces: Receptionist booking, checkout, service note,... Hotel system confirmation, invoice Guest Account system Telephone system R2??: The reception domain communicates with the surroundings in this way: Receptionist Reception Hotel system Account system From: Soren Lauesen: Software Requirements Pearson / Addison-Wesley 2002 Waiter Guest Accountant

38 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... From: Soren Lauesen: Software Requirements Pearson / Addison-Wesley 2002

39 Fig 3.4 Feature requirements 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. Feature = product function + related data 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. From: Soren Lauesen: Software Requirements Pearson / Addison-Wesley 2002

40 What is a feature? Some possible definitions: 1. A textual shall-statement requirement 2. A releasable characteristic of a (softwareintensive) product 3. A (high-level, coherent) bundle of requirements 4. A decision unit that can be in or out of a release plan depending on: What it gives (investment return) What it takes (investment costs) Politics, Beliefs, Loyalties, Preferences...

41 Fig 3.5A 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... 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? From: Soren Lauesen: Software Requirements Pearson / Addison-Wesley 2002

42 Fig 3.5A Screens & prototypes Design("screen1") has Image("screen1.png") 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... 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? From: Soren Lauesen: Software Requirements Pearson / Addison-Wesley 2002

43 Fig 3.5B Screens & prototypes 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,... From: Soren Lauesen: Software Requirements Pearson / Addison-Wesley 2002

44 Del 1 på Tentan: Påstående-anledning-frågor För varje par av påstående/anledning svara med ett av följande alternativ: A: Både påståendet och anledningen är korrekta uttalanden OCH anledningen förklarar påståendet på ett korrekt sätt. B: Både påståendet och anledningen är korrekta uttalanden, men anledningen förklarar inte påståendet. C: Påståendet är korrekt, men anledningen är ett felaktigt uttalande. D: Påståendet är felaktigt, men anledningen är ett korrekt uttalande. E: Både påståendet och anledningen är felaktiga uttalanden. Påstående Anledning Svar Virtuella fönster passar bra för att beskriva icke-funktionella krav. Kontextdiagram är en bra hjälp för att upptäcka saknade gränssnitt och diskutera vad som ska levereras. Virtuella fönster är en bra hjälp vid validering av fullständighet av datakrav. Ett kontextdiagram ger en lättbegriplig översikt av systemets avgränsning och dess aktörer. D A

45 Why should you propose exam problems? Focus on the learning objectives Demands deeper understanding Learning in groups Demands ability to assess different solutions Stimulate literature penetration during the course instead of at the end

46 What is a good exam problem? Relates to one or more of the learning objectives in the course program, Requires deep understanding, Is not easier if you have photographical memory Connects different parts of the theory Plagiarism is not allowed; create new variants, compared to previous exams and hand-ins on the course web Each problem shall have a literature reference and a motivation Your group s two hand-ins shall together give a good coverage of important parts of the course literature

47 Your exam problems should cover these theory parts Hand-in W4 6-8 problems (one per person) that cover: [Lau:1] 1-2 problems [Lau:2] 1-2 problems [Lau:3,4] 2 problems [Lau:8] 2 problems Hand-in W6 6-8 problems (one per person) that cover: [Lau:5,7] 1 problem [Lau:6, QUPER] 2 problems [Lau:9, INSP] 1-2 problems [MDRE+PRIO+RP] 1-2 problems [AGRE+INTDEP] 1 problem Suggestion: Everyone in the project makes an individual proposal for each area above. Then you all meet and discuss which problems are best and select/merge problems. You can also exchange feedback with your customer group.

48 Mall+exempel för inlämning Fråga 12. Virtuella fönster Påstående: Virtuella fönster (eng. virtual windows) passar bra till att beskriva icke-funktionella krav. Anledning: Det är lätt för kunder att med virtuella fönster validera om beskrivningar av data är fullständiga. Rätt svar: D (Påståendet är felaktigt, men anledningen är ett korrekt uttalande) Motivering: Påståendet är falskt eftersom virtuella fönster är till för att beskriva datakrav och passar dåligt för kvalitetskrav. Anledningen är sann eftersom virtuella fönster innehåller konkreta exempel på data och är därmed mer lättbegripliga för icke-datatekniker (jämfört med t.ex. datamodeller i form av E/R-diagram), vilket i sin tur underlättar för kunderna att avgöra om det är rätt krav. Litteraturhänvisning: Lau: 2 sid 66, 69, 54 Inlärningsmål: 2, 3 Huvudansvarig: <En person i gruppen>

49 Hand-in of exam problems (optional) Via to (all of these) Wednesdays W4 and W6 - latest by midnight for a chance of bonus (max 5+5p) One.pdf file per hand-in The file must be named <groupletter>q<1 2>.pdf The must have exactly this form of subject: [ETSN15] Group A, Exam Q1 dat14xyz, elt12abc, ada13ijk, adi13efd,... /* Note: Q1 without space and stil ID of all group members */ <<Attachment: AQ1.pdf>>

50 To Do Read Lau:8, Lau:2, Study all PM from start ups and make a complete priority order Discuss in each project your ambitions and how you would like to work, solve conflicts, etc. Lecture 3 on Monday with project mission selection. Each project must be represented. Tutorial on reqt and Scala next Thursday Preparations: download and run "hello reqt" See instructions at