Anskaffelse og kravspecifikation SR1_Intro Soren Lauesen, IT-University of Copenhagen E-mail: slauesen@itu.dk http://www.itu.dk/people/slauesen

SR1: Introduktion og begreber Kilder Soren Lauesen: Software requirements - Styles and techniques. Addison-Wesley, 2002. Many slides have been translated to Danish and/or modified and expanded. Søren Lauesen: Vejledning til kravskabelon SL-07. Samfundslitteratur, 2007. © 2002, Pearson Education retains the copyright to the slides from the book, but allows restricted copying for teaching purposes only. It is a condition that the source and copyright notice is preserved on all the material.

3. SR1.1 Hvad bruges en kravspecifikation til? Interessenter Underforståede behov & krav Behov “Elicitation” Analyse Kontrakt Kravspec Validering Design Sporbarhed: Forlæns . . . Baglæns . . . Kravstyring: Ændringer . . . Program Verificering Test Drift & vedl.h.

Projekttype Kunde Leverandør 4. SR1.2 Projekttyper Projekttype Kunde Leverandør In-house Afdeling IT afdeling Produktudvikling Marketing Udvikl. afd. Efter regning Virksomhed SW hus Standard/ramme Virksomhed IT virksomhed Udbud Virksomhed IT virksomhed Fastpris-projekt Virksomhed SW hus Underleverandør Leverandør IT virksomhed Ukendt In-house? Standard/ramme?

5. SR1.3 Hvad skal med i kravspecifikationen? Bruger grupper Datakrav: Hvad skal registreres? Platform: HW, OS, DB 30% 15% System Kvalitetskrav: Hvor hurtigt? Hvor brugervenligt? Hvor let at vedligeholde? . . . Eksterne systemer: Eksisterende og nye Grænseflader Funktionskrav, brugergrænseflade: ? Funktioner: Skal kunne vise ... Man skal kunne vælge ... ? Skærmbilleder og hvad hver knap gør ? Arbejdsopgaver der skal støttes (een af de mange slags use cases) Funktionskrav, eksterne systemer: Skal være integreret med ... Tredjepart skal kunne integrere med ... Hjælp til læseren: Forretningsmæssige mål Baggrund ...

6. Ekstra. Kravskabelon SL-07 A. Baggrund og vision, vejledning . . . B. Overordnede behov B1. Forretningsmæssige mål B2. Proof of concept C. Arbejdsopgaver systemet skal støtte C1. Indskriv patient C2. Klinisk session . . . D. Data systemet skal anvende D1. Diagnoser D2. Diagnosetyper . . . D10. Data i eksisterende systemer E. Andre funktionelle krav E1. Komplekse beregninger og regler E2. Udskrifter og rapporter E3. Udbygning af systemet F. Integration med eksterne systemer G. Teknisk it-arkitektur G1. Brug af eksisterende HW og SW G2. Nyt hardware og software H. Sikkerhed H1. Adgangsret for brugere H2. Sikkerhedsadministration H3. Sikring mod tab af data H4. Sikring mod utilsigtet brugeradfærd H5. Sikring mod trusler I. Brugervenlighed og design I1. Indlæring og effektivitet i daglig brug I2. Tilgængelighed og Look-and-Feel J. Andre krav og leverancer J1. Andre standarder der skal følges J2. Uddannelse J3. Dokumentation J4. Datakonvertering J5. Installation K. Kundens leverancer L. Drift, support og vedligehold L1. Svartider L2. Tilgængelighed L3. Datalagring L4. Support L5. Vedligehold

7. Ekstra. Traditionelle krav - løn og vagtplan på hospital Krav 47: Det skal være muligt at knytte en kode omkring vagttype (forvagt, bagvagt mv.) til den enkelte medarbejder. Krav 144: Leverandøren skal opdatere systemet så det følger nye overenskomster senest en måned efter frigivelsen. Krav 475: Systemet skal kunne beregne regnskabsmæssige konsekvenser af en given vagtplan - i timer og i kroner. Krav 479: Systemet skal advisere hvis en vagtplan indebærer samlet anvendelse af en vikar ud over tre måneder. Krav 669: Systemet skal give forståelige meddelelser i klar tekst ved fejl og vejlede i hvad brugeren bør gøre. Erfaringer: Kravene opfyldes, men arbejdsopgaverne støttes dårligt. De forretningsmæssige mål nås ikke. For dyrt - ingen frihed til leverandøren.

8. Ekstra: Skriv det som use cases? Use case 475: Beregn regnskabsmæssig konsekvens af vagtplan Trigger: Brugeren vil beregne konsekvensen Precondition: Brugeren er logget på 1. Systemet viser en liste af vagtplaner 2. Brugeren vælger en vagtplan 3. Brugeren vælger "Beregn konsekvens" 4. Systemet beregner konsekvensen 5. Systemet viser konsekvensen Exception: Ingen vagtplaner i listen Hvad skal det bruges til? Computer-centric use case Ingen værditilvækst med sådan en use case

9. SR13. Bedre krav: Støt arbejdsopgave C1.1, C1.2 . . . C2: Lav vagtplan Hyppighed: Hver 14. dag. I nogle afdelinger . . . Svært: Ferieperioder. Kunden: Hjælp - vi har købt det gale system Delopgaver og varianter: 1. Dan ny vagtplan. 2. Registrer ferie. To slags ferie . . . 3. Bemand vagter. Tjek rette kompetencer, ferie, overenskomster og undgå tillæg. 3a. Vikarer endnu ikke i systemet. 3b. Skaf medarb. fra anden afdeling. 4. Send planen til kommentering. 5. Ret planen og frigiv den. Eksempler / løsning: Automatisk ud fra sidste plan . . . Systemet kontrollerer feriereglerne. Systemet har en tidshorisont på flere år. Systemet foreslår bemanding af ubemandede vagter. Advarer om brudte regler og unødige tillæg. Støtter "puslespillet" med undo og flere forsøgsudgaver. Viser ledige fra andre afdelinger. En udskrift af planen er nok. Nuv. problem: Små lapper med ønsker mange måneder frem. Nuv. problem: Svært at gøre manuelt. Fejl og for mange tillæg. Udføres af menneske plus computer Eksempel på computers del - ikke krav

10. Ekstra: Verifikation af krav - vurdering af løsning Samlet point: 2 (som i dag) C2: Lav vagtplan Hyppighed: Hver 14. dag. I nogle afdelinger . . . Svært: Ferieperioder. Subtask og varianter: 1. Dan ny vagtplan. 2. Registrer ferie. To slags ferie . . . 3. Bemand vagter. Tjek rette kompetencer, ferie, overenskomster og undgå tillæg. 3a. Vikarer endnu ikke i systemet. 3b. Skaf medarb. fra anden afdeling. 4. Send planen til kommentering. 5. Parker planen eller frigiv den. Eksempler / løsning: Automatisk ud fra sidste plan . . . Systemet kontrollerer feriereglerne. Kun et år ud i fremtiden. Systemet foreslår bemanding af ubemandede vagter. Tillægsberegning batch - 24 timer. Flere udgaver besværligt. Kan vise ledige fra andre hospitaler. Nuv. problem: Små lapper med ønsker mange måneder frem. Nuv. problem: Svært at gøre manuelt. Fejl og for mange tillæg.

11. SR10.7A Forretningsmæssige mål og hvordan de opnås 1.1 Månedlig timeregnskab til pers.afd. Bruger: Medarbejder i afdelingen Bruger: Planlægger i afdelingen 2.1 Registrer faktisk arbejdstid 3.3 Registrer nye medarbejdere 2.3 Sygdom hos medarbejder Bruger: Personaleafdeling 3.2 Ændringer af lønsedler 3.1 Kontroller vagtplaner 1.2 Lav vagtplan 2.2 Byt vagter Forretnings- mæssige mål Arbejds opgaver Personaleafdeling: Automatiser nogle opgaver Fjern fejlkilder Overhold 120-dags reglen Mindre trivielt arb. og stress Hospitalsafdeling: Mindre overarbejdsbet. mv. Hurtigere vagtplanlægning Bedre plankvalitet

12. SR1.5A Domain and product level (context diagram) Clients “Business” domain Actors? Platform Product User activities Control computers Domain I/O Product Elevators Product-level requirements: The product shall compute: The cost of a roster . . . Domain-level requirements: The product shall support the following user activities: Make a roster . . .

13. SR3.5B Design-level requirements R4: The product shall have these screen pictures:

14. Ekstra: Fredericia Skibsværft - reparationsværft Mange underleverandører. Taber ordrer fordi prisen er for høj. Taber penge fordi prisen er for lav. Stress ved fakturering - kunden mister 500.000 DKK per dag. Forældet IT system - kan ikke vedligeholdes. Kan ikke sende tegninger mv.

15. SR1.6A Reparations-skibsværft. Bedste alternativ? R1. Vores forkalkulationer skal ramme indenfor 5% R2. Systemet skal registrere og bruge erfaringsdata ved arbejdsopgaverne: - Omkostningsregistrering - Tilbudsberegning R3. Systemet skal have en registre- ringsfunktion og en genfindings- funktion for erfaringsdata R4. Systemet skal have skærmbilleder som vist i bilag xx Krav på mål- sætnings-niveau Krav på domæne-niveau produkt-niveau design-niveau Det rigtige valg afhænger af leverandørens rolle, fx: - ERP leverandør - SW-hus uden forretningsviden - PriceWaterhouseCoopers

16. SR1.6B Ask “why” (or "when) Neural diagnostics System shall have mini keyboard with start/stop button, . . . Why? Possible to operate it with “left hand”. Both hands must be at the patient. Electrodes, bandages, painful . . .

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

18. SR1.7A Typical project models Traditional: Product-level reqs Ask users, study documents, . . . extract features/functions. Intro, [business goals] . . . System limits, e.g. context diagram Data reqs, e.g. data model, data descr. Product-level funct. reqs, e.g. features Critical quality reqs Product level skipped ! Two-step approach: Domain-level + design-level All the fast-approach stuff + Design-level reqs, e.g. prototypes, comm.protocols Fast approach: Domain-level Describe user tasks, study documents . . . Intro, [business goals, BPR tasks] . . . System limits, e.g. context diagram Data reqs, e.g. verbal data descr. Domain-level reqs, e.g. Tasks & Support [Trace analysis: goals to tasks] Critical quality reqs

19. SR1.7B Recommended project models Project type: Trad. Domain Two-step In-house ? OK OK Product dev. ? OK Time & mat. ? OK OK COTS business ? OK COTS tools OK Tender COTS ? OK Tender tailor ? OK  OK  Contract COTS ? OK Contract tailor ? OK  OK  Sub-contract OK OK Maintenance OK ? Used, but dubious  Variable price: e.g. $ 3000 per Function Point

20. SR1.7C Contracts and prices Contract type Analysis Design Program Analysis only T&M or Fixed Design & dev. Fixed and/or variable All-in-one T&M or Variable Development Tender: Same supplier?