Plancher til Anskaffelse og kravspecifikation, Forår 2007 Lauesen: Software requirements - Styles and techniques 7. Requirements in the product life cycle De fleste af plancherne stammer fra lærebogen. Hvis der findes en dansk udgave af planchen, er det den der er vist. Står planchens nummer i parentes, er planchen en tilføjelse til lærebogen. Enkelte plancher stammer fra Kravskabelon SL-07.

Fig 7.1 Requirements in product life cycle Inception Elicitation Formulation Checking Contract Design & program Accept test Reqs management & release planning Validation Verification Tender Writing proposal Comparing proposals Next release Who does what? Customer or supplier?

(Fig 7.5A) What to answer Req 1: yes; Req 2: yes... [Does the supplier know what he says yes to?] Piles of screens and technical descriptions? [How does it relate to me?] Show how you meet the requirements (e.g. simple screen outlines) [He is willing to cooperate] Sell your track record (“How we solved this customer problem... “) [He will help us out] Show that you understand his problem (go behind the requirements) [He understands - probably the others don’t] Show how to deal with it [He is willing to help - even if he misunderstood a bit] Show how to exceed the expectations [Wow!]

Fig 7.5(B) Supplier’s proposal Sub-tasks: 1.Find room. Problem: Guest wants neighboor rooms; price bargain. 2.Record guest as checked in. 3.Deliver key. Problem: Guests forget to return the key; want two keys. Variants: 1a.Guest has booked in advance. Problem: Guest identification fuzzy. Proposal: Floor map developed as an option. See outline on page xx. See room screen p. yy. See guest screen and check-in screen, p. zz We provide no support for electronic keys. Planned for release 5 in 1.5 years. User may search for any field using wild- carding. Task:1.2 Checkin Purpose:Give guest a room... Frequency:...

(Fig 7.5C) Go behind the requirements - find goals and tasks Meet the customer - preferably before the tender Ask - even if the other bidders listen Find a domain expert somewhere else Use the network of colleagues Spy - study the users anonymously, or use a student

(Fig 7.5D) Guard yourself State assumptions (sparingly) Offer as an option (where you know your price is high) Ignore the problem (we take the battle later - if the customer notices at all) Risk assessment (each requirement plus... ) Example: R26: The response time shall be at most 0.5 seconds on average when moving from one screen to the next. Never above 2 seconds. (200 simultaneous users) Supplier A: No problem, our response times are of that magnitude. Supplier B: We find a way out later, probably the customer doesn’t notice. Supplier C: Assumption: 2 seconds in 95% of the cases is sufficient. Supplier D: We offer 5 times the usual HW speed to meet the requirement. Supplier E: We offer 2 seconds in 95% of the cases. Option A: 2 seconds in 99%. Price: xxx $. Option B: 2 seconds always. Price:... (and explain why).

Fig 7.4 Customer’s rating Sub-tasks: 1.Find room. Problem: Guest wants neighbor rooms; price bargain. 2.Record guest as checked in. 3.Deliver key. Problem: Guests forget to return the key; want two keys. Variants: 1a.Guest has booked in advance. Problem: Guest identification fuzzy. Assessment: Floor map developed as an option. Very convenient display of bargain prices. If guest is not booked, cumbersome to switch to that task. No support for electronic keys. Tests show no tolerance for spelling errors. Very long search time for names. Task:1.2 CheckinProposal B Purpose:Give guest a room...Rating: 3 Frequency:... From: Soren Lauesen: Software Requirements © Pearson / Addison-Wesley 2002

Fig 7.3 Comparing proposals Hotel system evaluationProposals 0 (bad) - 5 (excellent)ABC Normal requirements345 Weakest requirements320 Total product points665 If stakeholders don’t agree? Ideal evaluationProposals ABC Business value (NPV) Supplier’s price Internal investment costs Net value From: Soren Lauesen: Software Requirements © Pearson / Addison-Wesley 2002 Priorities and weights? Understands our problem135 Track record414 Solidity544 Total points Base price Option 1: Floor map106- Option 2:...8-8

Kravskabelon B2. Tidligt bevis kræves Risikable krav: -Effektiv støtte til grundlæggende arbejdsopgaver -Rimelig svartid med det planlagte antal brugere -Rimelig brugervenlighed -Mulighed for egen / 3. parts udvidelse af systemet Kunden betragter disse kriterier som afgørende for langtids-succes med systemet. De betragtes også som de mest risikable områder. Mangler på disse områder kan næppe udbedres sent i projektet. Risiko-reduktion: Fx sætte testsystem op med simuleret belastning. Usability test. Få 3. part til at teste udvidelighed. Leverandøren skal såvidt muligt demonstrere at disse kriterier er opfyldt med det eksisterende system. Det kan ske under præsentationsmødet. Om nødvendigt må leverandøren demonstrere det inden for de første __ uger efter kontraktens underskrift (... plus hævebeføjelse)

Kravskabelon B3. Tildelingskriterier Valget af leverandør sker ud fra: -Forretningsmæssig værdi af løsningen (point for hvert forretningsmæssigt mål) -Risiko (tidligt bevis, referencer, modenhed, mv.) -Leveringstid -Pris Intet er sikkert. Multi-kriterie beslutning ! Kunden vælger den leverandør der ud fra en helhedsbetragtning giver mest værdi til prisen. Vægtning? Prioriterede kriterier? Minimax?

(Fig 7.6B) Design and program R1:System shall store data according to this data model... R2:Product shall have screens and menus as shown in... R3:Product shall record that a room is under repair... R4:Product shall support check-in according to task description... R5:At most 1 of 5 novices shall have critical usability problems during check-in. R6:Storing a booking shall take less than 1 second average. R7:Pre-calculation of repair orders shall hit within 5% of actual costs. Verify?Tracing? DirectReview by translationdevelopers DirectInspection translationand review A bit complexInspection and review ComplexEasy: walk through task Very hard.Usability test Early prototype Complex unlessTest setup and as usualsimulations Translate toFeasibility and domain reqsdata analysis at elicitation

Analyse Design Program (Fig 7.6C) Kilder til test cases Brugere Designspec Kode Domænekrav Tester's tricks Test cases: Brugertest... Beta test Støt opg. 1-8 Højst 5 kritiske problemer Skærmbilleder:... Knapper:... Branch test, tom løkke Dato tom, navn ok Dato ok, navn tom Grænsetest, ulovlig værdi Værelse 1000 Værelse a7% Udfør opgave usability test Check ind fra gaden Check ind booket Inspicer skærme prøv funktioner Find gæst, mange match Find gæst, ingen match

R1:Systemet skal opbevare data svarende til datamodellen... R2:Systemet skal have skærm- billeder og menuer som i... R3:Systemet skal kunne registrere at et værelse repareres... R4:Systemet skal støtte arbejds- opgaverne check ind... R5:Højst 1 af 5 begyndere må møde kritiske problemer under check ind. R6:Skift til næste skærm må højst tage 1,3 s i 95% af tilfældene. R7:Forkalkulation af reparations- ordrer skal ramme indenfor 5% af faktiske omkostninger. Overtagelsesprøve Indirekte gennem skærmbilleder (eller inspektion af databasen?) Inspektion og funktionstest, grænsetest, ulovlige værdier, etc. Ekspertbrugere prøver det (grænsetest, ulovlige værdier, etc.?) Usability test med det rigtige system Testopsætning og simulation + driftsprøve efter overtagelse Målinger et halvt år efter (Forhåbentlig huskede vi at samle data op før og efter) (Fig 7.6D) Kravtyper og test

Installationsprøve: Systemtest: Anvendelsesprøve: (Deployment test) Overtagelsesprøve: (Acceptance test) Driftsprøve: (Operational test) Hardware, software, eksterne produkter. Test grundlæggende funktioner. Test alle krav. (Undtagen dem der vedrører drift) Stress-test, specielle tilfælde, etc. (Der bruges specielt opsat databaseindhold) Produktionsdata (datakonvertering). Test med rigtige opgaver og rigtige brugere. = System test + Deployment test. Test resterende krav, fx svartider i drift, oppetid, hot-line... (Fig 7.7A) Afprøvning

(Fig 7.7B) Anskaffelsesplan - et simpelt eksempel IT-afdeling Finde kravene Tjek krav Udbud Leverandørvalg Kontraktunderskrift Tidligt bevis Udvikling / tilpasning Installationsprøve Systemtest Datakonvertering Dokumentation Kurser Anvendelsesprøve Support og hotline Driftsprøve Eftervurdering Vedligehold Garantiperiode udløber Kontrakten udløber Organisation Informanter Valider krav Vurdering af tilbud Usability test Informanter Annoncering Datavalidering Dokumentation Kurser og træning Dataskabelse Annoncering Daglig drift Kunne det betale sig? Leverandør Tilbud Informanter Kontraktunderskrift Tidligt bevis Udvikling / tilpasning Installationsprøve Systemtest Datakonvertering Dokumentation Kurser Anvendelsesprøve Support og hotline Driftsprøve Vedligehold

(Fig 7.7C) Drivkræfter og show-stoppere (Kotter) Hvor er vi? (skala 0-5) 3/1027/10... Følelse af nødvendighed (stop selvtilfredsheden) Stærk, styrende koalition Klar vision Kommunikeret vision Forhindringer fjernet Kortsigtede gevinster synlige Fortsæt efter første sejr Kulturændring

Fig 7.10 Requirements tracing Goals & demands Reqspec Design Program Operation Goal-domain tracing (8.7) Domain-reqs tracing (8.8) Reviews and tests (9.3) Direct implementation (7.6) Verification (7.6) Embedded trace inf (7.6) System & accept test (7.7) Consistency checks (9.2) Validation Verification From: Soren Lauesen: Software Requirements © Pearson / Addison-Wesley 2002