Anskaffelse og kravspecifikation

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

1 Anskaffelse og kravspecifikation
SR6_Quality

2 SR6: Kvalitetskrav Kilder
SR: Soren Lauesen: Software requirements - Styles and techniques. Addison-Wesley, 2002. UID: Soren Lauesen: User interface design - A software engineering perspective. Addison-Wesley, Fra kapitel 5. SL-07: Søren Lauesen: Vejledning til kravskabelon SL-07. Samfundslitteratur, 2007. Ekstra: Nye slides som ikke har noget sidestykke i bøgerne. Mange slides er vist i dansk oversættelse. © 2002, 2005, Pearson Education retains the copyright to the slides from the books, 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. SR6.1 Quality factors McCall ISO 9126 Use as check lists
US Airforce 1980 Operation: Integrity Correctness !! Reliability Usability Efficiency Revision: Maintainability Testability Flexibility Transition: Portability Interoperability Reusability !! ISO 9126 Functionality Accuracy Security Interoperability Suitability !! Compliance !! Reliability Maturity Fault tolerance !! Recoverability !! Usability Efficiency Maintainability Testability Changeability Analysability !! Stability !! Portability Adaptability Installability !! Conformance !! Replaceability !! Use as check lists

4 4. SR6.2 Kvalitetsmatrix (ud fra McCall's faktorer)
Glem det Mindre Som vi Kritisk Vigtig plejer vigtig 4. SR6.2 Kvalitetsmatrix (ud fra McCall's faktorer) Kvalitets- faktorer for hotelsystem Årsag: 1. Svært at køre hotellet når systemet er nede. Check ind er fx umuligt når man ikke kan se værelsets status. 2. Vi går mest efter små hoteller. De har utrænede vikarer. 3. Kunderne har mange slags regnskabssystemer. Vigtigt med smertefri integration. 4. Integration med regneark, etc. ligegyldig. Den indbyggede statistik burde være nok. 5. Skal være meget lettere at installere end eksisterende systemer. Ideelt skal en receptionist kunne gøre det selv. Drift Sikkerhed x Fejlfrihed x Oppetid 1 Brugervenlighed 2 Svartid mv. x Ændring Retbarhed x Testbarhed x Udvidelighed x Overførsel Flytbarhed x Integration 3 4 Genbrugelighed x Installerbarhed 5

5 Efficiency Response time Capacity Accuracy . . .

6 6. (SR6.3A+6.5A) Svartidskrav R10: Når man går fra et felt til det næste, skal man kunne taste indenfor 0,2 s. R11: Når man går fra et skærmbillede til det næste, skal man kunne taste indenfor 1,3 s. R12: Visning af simple rapporter på skærmen skal ske indenfor 20 s. Ellers nedsættes tastetiden Mental skiftetid Ellers skifter man task Skal gælde i 95% af tilfældene ved spidsbelastning, dvs.: 20 brugere arbejder med sagsbehandling (arbejdsopgave T12) og 100 brugere med kundesupport (arbejdsopgave T10) R20: Visning af simple rapporter på skærmen skal ske indenfor 20 s i 95% af tilfældene. Det må aldrig tage over 80 s. Urealistisk Processtyring - spidsbelastning R30: Systemet skal kunne behandle én alarm på 1 sekund, 1000 alarmer på 5 sekunder.

7 7. (SR6.3A) Åbent mål (target)
Bedst mulig er 40 s? R2: Systemet skal beregne en belægningsprognose indenfor 20 s. Ingen prøver 20 s R3: Systemet skal beregne en belægningsprognose indenfor 40 s. Åbent mål men hvor vigtigt? R4: Systemet skal beregne en belægningsprognose indenfor ___ s. R5: Systemet skal beregne en belægningsprognose indenfor ___ s. (Kunden forventer 20 s.) Åbent mål + forventning Krav til svartider Når man går fra et felt til det næste skal brugerens tastehastighed ikke nedsættes. Visning af simple rapporter skal ske inden brugeren taber tålmodigheden. Eksempel på løsning Man kan taste inden ___s. (Kunden forventer 0,2 s) Rapporten skal være synlig inden ___s. (Forventer 20 s) Formulering i kravskabelon SL-07:

8 8. SR6.3C Cost/benefit of response time
$ or ratio 2 Benefit/cost Benefit (saved time) 1 System cost min Response time

9 9. Extra: Queues and response time
Computer idle Computer busy Busy + queue My request I need 8 seconds service Computer idle Busy 3 more seconds Busy plus one in queue Waiting time 0 s 3 s 3 + 8 s Service time 8 s Response time 11 s 19 s Computer load: 20% p = 80% p ≈ 16% p ≈ 3% Computer load: 80% p = 20% p ≈ 16% p ≈ 13%

10 10. SR6.5B Response times, M/M/1
Service time: Exponential distribution Response factor 99% 80% 95% 90% Average System load Example: Service time: Time to process one request Average service time: 8 s (exp. distr.) Average interarrival time: 10 s (exp. distr.) System load: 8/10 = 0.8 Average response time: 5  service time = 40 s 90% responses within: 12  service time = 96 s

11 11. SR6.5C Response times, M/D/1
Service time: Constant Response factor 99% 90% 95% 80% Average System load Example: Service time: Time to process one request Average service time: 8 s (constant) Average interarrival time: 10 s (exp. distr.) System load: 8/10 = 0.8 Average response time: 3  service time = 24 s 90% responses within: 6  service time = 48 s From: Soren Lauesen: Software Requirements © Pearson / Addison-Wesley 2002

12 12. SR6.4 Capacity and accuracy requirements
Capacity requirements: R1: The product shall use < 16 MB of memory even if more is available. R2: Number of simultaneous users < 2000 R3: Database volume: #guests < 10,000 growing 20% per year #rooms < 1,000 R4: Guest screen shall be able to show at least 200 rooms booked/occu-pied per day, e.g. for a company event with a single “customer”. Accuracy requirements: R5: The name field shall have 150 chars. R6: Bookings shall be possible at least two years ahead. R7: Sensor data shall be stored with 14 bit accuracy, expanding to 18 bits in two years. R8: The product shall correctly recognize spoken letters and digits with factory background noise ___ % of the time. Tape B contains a sample recorded in the factory.

13 Usability: Let at lære, effektivt at bruge, let at huske
subjektiv tilfredshed, forstå hvad der sker

14 14. SR6.6B Usability / brugervenligheds problemer
Eksempler: Systemet gør som programmøren har tænkt, men brugeren: P1. Kan ikke finde ud af at starte søgningen. Finder endelig ud af at bruge F10. P2. Tror han har fuldført opgaven, men glemte at klikke på Opdatér. P3. Ser rabatkode-feltet, men kan ikke finde ud af den kode han skal bruge. P4. Siger det er tåbeligt at skulle bruge 6 skærme til at udfylde 10 felter. P5. Vil udskrive en liste af rabatkoder, men det kan systemet ikke. Alvorlighed: 1 Manglende funktion (strengt taget ikke brugervenlighed) 2 Task failure 3 Irriterende, besværligt 4 Mellem-problem (lykkes efter længere tid) 5 Lille problem (lykkes efter kort tid) Kritisk problem = Manglende funktion, task failure, irriterende - oplevet af mange brugere

15 Bør gøres inden programmering - skærmbilleder på papir
15. SR6.6C Usability test - tænke-højt forsøg Formål: Finde usability problemer Jeg prøver det her fordi ... Brugeren bemærker ikke ... Forsøgsleder Stiller opgaverne Lytter - spørger evt. forsigtigt Log-fører Lytter Registrerer problemer Typisk bruger Bør gøres inden programmering - skærmbilleder på papir

16 16. Ekstra: Usability test - tænke-højt forsøg med Mockup
Formål: Finde usability problemer Typisk bruger Log-fører Lytter Registrerer problemer Jeg prøver det her fordi ... Brugeren bemærker ikke ... Forsøgsleder Stiller opgaverne Skifter "billeder" Udfylder svarfelter Ret og redesign Test igen Erfaringer, fx Bruel & Kjær: Ca. 3 iterationer. Tager 1-3 uger. Programmeringen bliver lettere og hurtigere. Produktet sælger langt bedre.

17 17. UID1.4 Usability test – check list
Slide 17 Plan Test-users: Test-tasks: Study system yourself Carry out Explain purpose: - Find problems when using the system - System’s fault - not yours Give task - think aloud, please Observe, listen, note down (test log) Ask cautiously: - what are you looking for? - why ? Help users out when they are surely lost Test report List the usability problems - within 12 hours 17

18 18. UID13.5B Test tasks - hidden help?
Slide 18 18. UID13.5B Test tasks - hidden help? Version A: John Simpson wants to check in. Find him on the FindGuest screen. Double click to open his Stay screen. Version B: John Simpson wants to check in. He has stay number 710. Version C: John Simpson arrives 23rd October. He says there should be two rooms for him. If asked: He cannot remember his booking number (or stay number). He lives 456 Orange Grove, Victoria Australia (can’t remember zip code) He leaves 26th October. 18

19 19. UID13.7B Log from usability test
Slide 19 19. UID13.7B Log from usability test 19

20 Slide 20 20. UID13.7C Test report 20

21 21. SR6.7 Usability-krav - 1 Risk Kunde Lev. Problemtælling
Detaljer: En begynder har fået 5 min instruktion . . . Opg. Q: John Simpson ringer og vil bestille et værelse . . . Kunde Lev. Problemtælling R1: Højst 1 af 5 begyndere må møde kritiske problemer under opgave Q og R. Højst 5 mellem-problemer på listen. Tidtagning R2: Begyndere skal kunne udføre opgave Q og R på i alt 15 min. Erfarne brugere opgave Q, R og S på i alt 2 min. Tastetrykstælling R3: Morgenmad skal kunne registreres med 5 tastetryk pr. værelse. Ingen brug af mus. Meningsmåling R4: 80% af brugerne skal synes systemet er let at lære. 60% vil anbefale det til andre. Forståelighedsmåling R5: Vis 5 brugere 10 fejlmeddelelser, fx Beløb for stort. Spørg om årsagen. 80% af svarene skal være mindst 8 på 13-skalaen.

22 22. SR6.7 Usability-krav - 2 Risk Kunde Lev. Design-niveau krav
R6: Systemet skal have de skærmbilleder der er vist i bilag xx, og knapperne skal virke som beskrevet i bilag yy. Produkt-niveau krav R7: For alle felter med en kode, skal brugeren kunne vælge koden fra en drop-down liste. Overholdelse af GUI standard R8: Systemet skal overholde GUI standarden zz. Desuden må menuerne højst have tre niveauer. Krav til udviklingsprocessen R9: Leverandøren skal teste 3 iterationer af brugergrænsefladen (papir-prototype) for at fjerne de værste problemer. Hvis kunden ikke er tilfreds efter tredje iteration, kan han opsige kontrakten.

23 23. UID1.6H Den bedste kravtype - afhænger af . . .
Tidlig udvikling Købe et system Sen udvikling Forstå hvad der sker Effektivt at bruge Subjektiv tilfreds Let at huske Let at lære Tidtagning Problemtælling Tastetrykstælling Meningsmåling Forståelighedsmåling GUI standard God Nyttig Kun indikationer ? ?

24 24. SL-07: I1. Indlæring og effektivitet i daglig brug

25 Security: Trusler og beskyttelse, Identifikation, Rettigheder

26 26. SR6.8A Sikkerhed og trusler
Wire tapping Nysgerrige øjne System Lønseddel Wire tapping Disk crash Trusler Ødelægger Forebyggelse Input, fx Fx Fejltagelse Integritet Logisk kontrol Ulovlig brug Ægthed Password . . . Wire tapping Fortrolighed Kryptering CIA + A: Confidentiality = fortrolighed Integrity = integritet Availability = tilgængelighed + Authenticity = ægthed Lagring/proces Disk crash Tilgængelighed Dublerede diske Programfejl Integritet Testmetoder Virus sletter data Tilgængelighed Antivirus . . . Output, fx Kabelbrud Tilgængelighed Multiple linier Bedrageri Fortrolighed Revision Virus sender data Ægthed Kryptering . . . From: Soren Lauesen: Software Requirements © Pearson / Addison-Wesley 2002

27 27. SR6.8B Risikovurdering - hotelsystem
Antagelser: Tabe databasen med alle bookinger: Tabe computer- adgang 1 dag: On-line booking uden dækning: Bedrager der fjerner fakturagrundlag Adm. rod når fakturaer ikke printes 2.000 Beløb i kr. Gange pr. Tab Tab år pr. gang pr. år Trussel Input Fup-booking Lagring Disk crash Comp. crash Sabotage Bedrageri Virus Output Printerfejl

28 28. SR6.9A Sikkerhedskrav vedr. trusler
R1: Beskyt mod tab af databasen. Estimeret tab skal være < 1 pr. 50 år. R2: Beskyt mod disk crash. Estimeret tab skal være < 1 pr. 100 år. R3: Systemet skal bruge dublerede diske (RAID disks). R4: Systemet skal beskytte mod virus der sletter/ødelægger filer. Antal angreb der ikke undgås < ______. R5: Systemet skal have antivirus og firewall mod virus. R6: Systemet skal følge god regnskabspraksis. Leverandøren skal sørge for certificering. R7: Systemet skal forhindre at brugere sletter fakturaer før de overføres til regnskabssystemet. R8: Leverandøren skal som en option tilbyde at systemet tjekker creditkort og tilbageholder beløb. R9: Leverandøren skal vedlægge en risikovurdering og foreslå beskyttelsesforanstaltninger. From: Soren Lauesen: Software Requirements © Pearson / Addison-Wesley 2002

29 29. SL-07:H1 Login - hvad er behovet egentlig?
Delopgaver vedr. brugeres adgang: Eksempler på løsning: Kode: 1. Identificer brugeren. Hver bruger har et brugernavn og et password. Gerne også en alternativ form, fx stemme . . . 1p. Problem: Brugeren har været væk . . . En anden kan bruge rettighederne. Systemet timer ud efter 5 min. 1q. Problem: Hvis systemet timer ud er det besværligt at logge på igen. Systemet kræver kun passw. Timeout er stedafhængig. 2. Kontrollér at bruger har de krævede rettigheder. (Se liste nedenfor). 2p. Problem: I dag har brugerne et passw til hvert system. Tit på opslagstavlen ! Kun ét brugernavn og passw. pr. bruger (single sign-on). Rettigheder 1. Ret til at ordinere medicin på afdeling M. 2. Ret til at se patientdata på afdeling M. 3. Ret til at registrere klinisk data (ydelser og diagnoser) på afdeling M. . . . En tilsynsførende på afdeling M kan fx have rettighed 2 og 3.

30 30. SL-07:H2 Sikkerhedsadministration
Sikkerhedsadministrationens arbejde omfatter nedenstående delopgaver. Vanskeligt: Når 120 nye medarbejdere er ansat og skal have rettigheder fra dag 1. Delopgaver vedr. sikkerhedsadministration: Eksempler på løsning: Kode: 1. Tildel eller fjern rettigheder for en bruger. 1a. Brugeren skal oprettes. 1p. Problem: En lang række brugere skal oprettes, fx lige inden månedsstart. Automatisk overførsel af data fra personalesystemet. 1q. Problem: En hasteindkaldt vikar er endnu ikke i personalesystemet, men skal have adgangsret. Mulighed for midlertidig oprettelse udenom sikkerheds-administrationen. 1r. Problem: Sikkerhedsadministrationen skal holde styr på sammenhængen mellem 4000 brugere og 300 rettigheder. Hver bruger tildeles en eller flere roller, fx læge i afdeling M og tilsynsførende i afdeling N. 1s. Problem: Sikkerhedsadministrationen glemmer at oprette og fjerne rettigheder på de rigtige tidspunkter, fx . . . Rettigheder kan defineres så de gælder for en periode, fx fra den dag personen ansættes. 2. Opret nye rolletyper med nye kombina-tioner af rettigheder. 3. Få oversigt over hvem der har ret til . . .

31 31. Ekstra: Adgangsrettigheder, hotelsystem
Rettigheder man kan have: CRUD = Create, Read, Update, Delete Roller Entitet Receptionist Shift manager Administrator Gæst CRU R D (periodisk) Ophold Vær.tilstand CRUD (ej særrabat) U (særrabat) Værelse CRUD Service Service type Krav 1 : Hver rolle har kun de rettigheder der fremgår af tabellen. Krav 2: En bruger kan have en eller flere af disse roller og har dermed alle de rettigheder som disse roller giver. Eksempler på løsning: a: Rettighederne kontrolleres i database-systemet. b: Brugerens skærmbilleder viser kun de funktioner han har ret til at bruge.

32 Maintenance

33 33. SR6.10 Maintenance Product Maintenance cycle: Corrective
Preventive maintenance Product Perfective maintenance New release Maintenance cycle: Report: Record and acknowledge. Analyze: Error, change, usability, mistake? Cost/benefit? Decide: Repair? reject? work-around? next release? train users? Reply: Report decision to source. Test: Test solution. Related defects? Carry out: Install, transfer user data, inform. Don't just prioritize

34 34. SR6.11A Maintenance requirements
Risk Cust. Suppl Maintenance performance R1: Supplier’s hotline shall analyze 95% of reports within 2 work hours. Urgent defects (no work around) shall be repaired within 30 work hours in 95% of the cases. R2: When reparing a defect, related non-repaired defects shall be less than 0.5 in average. R3: For a period of two years, supplier shall enhance the product at a cost of ___ per Function Point. Support features R4: Installation of a new version shall leave all database contents and personal settings unchanged. R5: Supplier shall station a qualified developer at the customer’s site. R6: Supplier shall deposit code and full documentation of every release and correction at ____________.

35 35. SR6.11B Maintainability requirements
Risk Cust. Suppl Development process requirements R7: Every program module must be assessed for maintainability according to procedure xx. 70% must obtain “highly maintainable” and none “poor”. R8: Development must use regression test allowing full re-testing in 12 hours. Program complexity requirements R9: The cyclomatic complexity of code may not exceed 7. No method in any object may exceed 200 lines of code. Product feature requirements R10: Product shall log all actions and provide remote diagnostic functions. R11: Product shall provide facilities for tracing any database field to places where it is used.

36 36. Ekstra: Tre af kravenes dimensioner
Kravområde Dialog-funktion Data Integration Platform Svartid Sikkerhed Brugervenlighed Love & regler Support Vedligehold Forretn. mål Domæne Produkt Design Proces Kravniveau Ja-nej Talskala Point (fx 5-trinskala) Kan ikke vurderes Målemetode