Anskaffelse og kravspecifikation SR1_Intro Soren Lauesen, IT-University of Copenhagen

Præsentationer af emnet: "Anskaffelse og kravspecifikation SR1_Intro Soren Lauesen, IT-University of Copenhagen"— Præsentationens transcript:

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

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

4 System Platform: HW, OS, DB Eksterne systemer: Eksisterende og nye 4. SR1.3 Kontekstdiagram - hvad skal leveres? Bruger grupper Kvalitetskrav: Hvor hurtigt? Hvor brugervenligt? Hvor let at vedligeholde?... Grænseflader Datakrav: Hvad skal registreres? 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... 30% 15% Hjælp til læseren: Forretningsmæssige mål Baggrund...

5 5. Ekstra. Kravskabelon SL-07 A. Baggrund og vision, vejledning... B. Overordnede behov B1. Forretningsmæssige mål B2. Proof of concept B3. B4. Tildelingskriterier (kun på engelsk) 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

6 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. IEEE 830 6. Ekstra. Traditionelle krav - løn og vagtplan på hospital

7 7. Ekstra: Skriv krav 475 som use case? 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 Hovsa-trigger. Hvad bruges det til og hvornår? Trivielle detaljer - forført af skabelonen. Ingen værditilvækst. Selvopfunden dialog. Leverandør B må vrages. Use cases kan ikke fange problemer med ukendt løsning – men her er de forretningskritiske behov ofte. Er use cases krav? Skrives, men bruges ikke

8 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. C2: Lav vagtplan Hyppighed:Hver 14. dag. I nogle afdelinger... Start:Når der er fred i vagten. Slut:Når der bliver travlt. Eksempler på 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. Udføres af menneske plus computer Eksempel på computers del - ikke krav 2p. Nuv. problem: Små lapper med ønsker mange måneder frem. 3p. Nuv. problem: Svært at gøre manuelt. Fejl og for mange tillæg. Kunden: Hjælp - vi har købt det gale system 8. SR13. Bedre krav: Støt arbejdsopgave C1, C2...

9 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. 9. Ekstra: Leverandørsvar (typisk, men ikke eksemplarisk) C2: Lav vagtplan Hyppighed:Hver 14. dag. I nogle afdelinger... Start:Når der er fred i vagten. Slut:Når der bliver travlt. Tilbudt løsning: Automatisk ud fra sidste plan. OK. Systemet kontrollerer feriereglerne. Op til to år frem. Støttes. Se skærmbilleder i... Ledige også fra andre hospitaler. En udskrift af planen er nok. 2p. Nuv. problem: Små lapper med ønsker mange måneder frem. 3p. Nuv. problem: Svært at gøre manuelt. Fejl og for mange tillæg.

10 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. C2: Lav vagtplan Hyppighed:Hver 14. dag. I nogle afdelinger... Svært:Ferieperioder. 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. Samlet point: 0 (som i dag) 10. Ekstra: Verifikation af krav - vurdering af løsning

11 11. SR10.7A Forretningsmæssige mål og hvordan de opnås Bruger: Planlægger i afdelingen 1.1Månedlig timeregnskab til pers.afd. 1.2Lav vagtplan Bruger: Medarbejder i afdelingen 2.1Registrer faktisk arbejdstid 2.2Byt vagter 2.3Sygdom hos medarbejder Bruger: Personaleafdeling 3.1Kontroller vagtplaner 3.2Ændringer af lønsedler 3.3Registrer nye medarbejdere 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 Product Platform Control computers 12. SR1.5A Domain and product level (context diagram) User activities Domain I/O Product I/O Domain Clients “Business” domain Actors? 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 13. SR3.5B Design-level requirements R4:The product shall have these screen pictures:

14 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 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 Krav på produkt-niveau Krav på design-niveau Det rigtige valg afhænger af leverandørens rolle, fx: -ERP leverandør -SW-hus uden forretningsviden -PriceWaterhouseCoopers

16 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”. Why? Both hands must be at the patient. Why? Electrodes, bandages, painful...

17 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 18. SR1.2 Projekttyper Projekttype KundeLeverandør In-houseAfdelingIT afdeling ProduktudviklingMarketingUdvikl. afd. Efter regningVirksomhedSW hus Standard/rammeVirksomhedIT virksomhed UdbudVirksomhedIT virksomhed Fastpris-projektVirksomhedSW hus UnderleverandørLeverandørIT virksomhed UkendtIn-house? Standard/ramme?

19 19. 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 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 Two-step approach: Domain-level + design-level All the fast-approach stuff + Design-level reqs, e.g. prototypes, comm.protocols Product level skipped !

20 20. SR1.7B Recommended project models Project type:Trad.DomainTwo-step In-house?OKOK Product dev.?OK Time & mat.?OKOK COTS business?OK COTS toolsOK Tender COTS?OK Tender tailor?OK  OK  Contract COTS?OK Contract tailor?OK  OK  Sub-contractOKOK MaintenanceOK  Variable price: e.g. $ 3000 per Function Point ? Used, but dubious Project model

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