Præsentation er lastning. Vent venligst

Præsentation er lastning. Vent venligst

Anskaffelse og kravspecifikation

Lignende præsentationer


Præsentationer af emnet: "Anskaffelse og kravspecifikation"— Præsentationens transcript:

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

2 SR1: Introduktion og begreber
Kilder Soren Lauesen: Software requirements - Styles and techniques. Addison-Wesley, 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 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.

4 4. SR1.3 Kontekstdiagram - hvad skal leveres?
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 ...

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 6. 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. IEEE 830 Erfaringer: Kravene opfyldes, men arbejdsopgaverne støttes dårligt. De forretningsmæssige mål nås ikke. For dyrt - ingen frihed til leverandøren.

7 7. Ekstra: Skriv det som use cases?
Hvad bruges det til og hvornår? 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 Selvopfunden dialog. Skadelig her. Trivielle detaljer - forført af skabelonen. Ingen værditilvækst.

8 8. SR13. Bedre krav: Støt arbejdsopgave C1, C2 . . .
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. Parker planen eller 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

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

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

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

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

13 13. 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 DKK per dag. Forældet IT system - kan ikke vedligeholdes. Kan ikke sende tegninger mv.

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

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

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

17 Projekttype Kunde Leverandør
17. 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?

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


Download ppt "Anskaffelse og kravspecifikation"

Lignende præsentationer


Annoncer fra Google