Kravspesifikasjon

1. Kravspesifikasjon • Kravspesifikasjon: • Pensum definert gjennom forelesningene (Powerpoint filer) • Mye overlapp med IT-strategi delen • Vi har tidligere sett på hvordan organisasjoner kan få maksimalt ut av alle sine IT systemer, her ser vi på kravene til ett system • Denne forelesningen kan også fungere som en oppsummering av mye av det vi tidligere har snakket om • Referansebok: • Del I av Kotonya, G. & Sommerville, I., Requirements Engineering, Wiley, 1997. Kravspesifikasjon

2. Bakgrunn • IT prosjekter har vært plaget av: • Budsjettoverskridelser • Tidsoverskridelser • Mange fiaskoer • Uklarhet om mål er oppnådd • Ofte legger en skylden på uklare kravspesifikasjoner • Med kravspesifikasjonen ønsker en: • Bedre styring • Fastere former • Kontroll over budsjett og tid • Systemer som dekker kundens behov Kravspesifikasjon

3. Kravspesifikasjon kan være mangt… • Et formelt dokument, en juridisk bindende kontrakt, mellom kunde og utvikler om hva som skal gjøres • En prototype • En liste av mål for systemet, samt en skisse til løsning • Kan starte med en vag ide • ”hei, vi har et problem med å lage en ordreplan” Kravspesifikasjon

4. Her skal vi • I stor grad se på mer formell kravspesifikasjon • Kunnskap om dette er viktig da enkelte organisasjoner krever dette • Men, vi skal også se på andre måter å lage en kravspesifikasjon på • Kravspesifikasjonen blir viktig for store systemer Kravspesifikasjon

5. Forskjellige typer av krav kan inngå: Generelle Funksjonelle Krav til implementasjon Effektivitet Brukervennlighet Kravspesifikasjon

6. Problemer • Upresise mål • Kravspesifikasjonen beskriver ikke brukernes virkelige behov • Spesifikasjonene er inkonsistente og ikke komplette • Spesifikasjonene er for detaljerte (låser utviklerne), mange punkter, svak overordnet forståelse • Misforståelser mellom bruker, de som utvikler spesifikasjonene og utviklerne • Kravspesifikasjonen forutsetter en stabil verden, det har vi sjelden • Kravspesifikasjonen tar ikke hensyn til at visse mål er vanskelig å oppnå • Hva når de egentlige kravene endres over tid? Kravspesifikasjon

7. Kan føre til… • Forsinket leveranse • Fordyret leveranse • Behov for store endringer etter installasjon • Systemet blir benyttet galt, lite eller ikke i det hele tatt • Systemet kan være upålitelig • Kritiske brukere • Meget store vedlikeholdskostnader • Dårlig tilpassning til andre systemer • Systemet blir fort avleggs • Indirekte kostnader (jobben blir ikke gjort) Kravspesifikasjon

8. Ofte • Store kostnader til utvikling og tilpassning • Systemet blir tatt i bruk • Det virker • Men uklart om en har oppnådd noe • F.eks. (fra en vit. artikkel): • It is therefore very unlikely that any ERP implementation can simply be asserted to be a success or a failure • Men det er selvfølgelig systemer som er en åpenbar suksess eller en åpenbar fiasko Kravspesifikasjon

9. Kravspesifikasjonsprosessen Hvordan man håper at denne skal gå! Kravspesifikasjon

10. Aktiviteter Kravspesifikasjon

11. Kravspesifikasjonsdokumentet inneholder: Kravspesifikasjon

12. IEEE/ANSI 830-1993 (standard): • Introduction • Purpose • Scope of the product • Definitions • References • Overview of document • General description • Product perspective • Product functions • User characteristics • General constraints • Assumptions and dependencies • Specific requirements • functional, non-functional, interface, performance, database and network requirements, etc. • Index Kravspesifikasjon

13. Hvem bruker kravspes. dokumentet? Kravspesifikasjon

14. Guidelines: Kravspesifikasjon

15. Prosessen Kravspesifikasjon

16. Data Kravspesifikasjon

17. Aktivitetsmodell elicitation – å få fram, synliggjøre Kravspesifikasjon

18. Tradisjonell modell Waterfall model Kravspesifikasjon

19. Mer moderne Kravspesifikasjon

20. Utvikling, først når vi vet hva vi skal lage: Denne fasen er lite formalisert, åpen, med mange usikkerhetet Denne fasen bør være formalisert, entydig og sikker Utvikling av systemet (detaljspesifikasjon, programmering…) Kravspesifikasjon

21. Hvem er involvert? Kravspesifikasjon

22. Roller Kravspesifikasjon

23. Verktøy for å understøtte kravspesifikasjonsprosessen: Kravspesifikasjon

24. CMM – Capability Maturity Model SEI, Software Engineering Institute i Pittsburgh bruker disse 5 nivåene. Kravspesifikasjon

25. Nivåer av utvikling mht softwareutvikling: • Initial: • Udisiplinerte prosesser, individer bestemmer hvordan ting skal gjøres og hvilke teknikker som skal brukes • Repeatable level: • Grunnleggende prosesser for budsjettering og planlegging av utviklingsprosesser er beskrevet og kan repeteres • Defined level: • Dokumentasjon, standardisering • Managed level: • Kvalitetskontroll • Optimizing level: • Kontinuerlig prosess for forbedring, objektive målinger Kravspesifikasjon

26. ”in” å karakterisere organisasjoner på denne måten • Mest anvendelig for store softwarehus • Har mange prosjekter • Ofte store prosjekter • Mange prosjektdeltagere • Formalisering er nødvendig for å få oversikt og kontroll Kravspesifikasjon

27. Problemer med modellen • Mange softwareutviklere bruker en ad hoc modell (nivå 1) med stor suksess • Eksempler: Microsoft, Google, Facebook, Apple • Men dette kan sies å falle innenfor kreativ softwareutvikling, mens “maturity” modellen kanskje er ment for mer rutinepreget virksomhet?

28. Forenklet modell for kravspesifikasjon Kravspesifikasjon

29. Best practices Kravspesifikasjon

30. Requirement Elicitation Kravspesifikasjon

31. Fire dimensjoner • Application domain understanding • Forstå institusjonen, området der systemet skal anvendes. Hvem er brukerne, hva er brukernes bakgrunn. Hvilke holdninger eksisterer… • Problem understanding • Hva er målene for systemet, hvilke problemer skal vi løse… • Business context • Systemet skal (som oftest) bidra til utvikling av organisasjonen, hvordan passer systemet inn med andre, med overordnede strategier • Stakeholder needs and constraints • Hva er deres motivasjon, hva ønsker de å oppnå Kravspesifikasjon

32. Problemer • Application domain understanding • Informasjon om dette er ikke samlet på ett sted, mange kilder, også muntlige, eksplisitt og implisitt • Problem understanding • De har et problem, men akkurat hva dette går ut på og hvordan det skal løses må vi ofte finne ut selv. De vi skal arbeide med er ofte opptatt… • Business context • Hvordan fungerer organisasjonen, er overordnede mål og strategier uttalte? • Stakeholder needs and constraints • Stakeholders kan ha sine (ofte gode) personlige motivasjoner i et prosjekt, hva er disse? Kravspesifikasjon

33. ”Elicitation” og analyse Kravspesifikasjon

34. 4 kritiske aktiviteter: • Mål • Beskriv målene for systemet, oversikt over problemet, hvorfor et nytt system kan være nødvendig, begrensninger som budsjett… • Bakgrunnskunnskap • Organisasjon, anvendelsesområde, andre systemer… • Organisering • Organiser data og informasjon samlet inn til nå, prioriter mål • Brukerkrav • Hva er brukernes krav til det nye systemet Kravspesifikasjon

35. Mål • Skal fortelle oss hva vi skal oppnå, hensikten (”rationale”) • Disse kan brukes når vi må ta avgjørelser underveis (f.eks. for å velge mellom brukervennlighet og effektivitet) • Målene blir viktige når systemet skal evalueres Kravspesifikasjon

36. Oversikt Kravspesifikasjon

37. Analyse /forhandlinger Kravspesifikasjon

38. Teknikker • Samle bakgrunnsstoff (strategiplaner, årsrapporter….) • Intervjuer • Scenarioer • ”Soft system methodology” (SSM) • Syv faser (se neste slide) Kravspesifikasjon

39. SSM – 7 faser: Kravspesifikasjon

40. Kravspesifikasjon

41. Etnografisk undersøkelse Observasjon av brukerne i arbeid, intervjuer, video, ”de-briefing” hvor vi trekker ut verdifull informasjon Kravspesifikasjon

42. Prototyping • Alternativer: • Bruk og kast • Evolusjonær prototyping (mer aktuell nå med bedre verktøy) • Mange fordeler: • Kan vise hvordan systemet vil bli, inklusiv ”look and feel” • Håndfast • Lettere for brukerne å forholde seg til en prototype enn en spesifikasjon, mer og bedre tilbakemeldinger • Hurtigere utvikling • Understøtter utvikling i faser • Gir utviklerne tidlige kunnskaper om metoder, tidsbruk m.m. Kravspesifikasjon

43. Prototype • Av hele systemet, prototypen kan da bli systemet (ref. Oshaug) • Av deler av systemet: • Brukergrensesnitt • Komplekse tekniske løsinger • Tidsaspekt • Det er smart å konsentrere seg om ukjente deler først. • Prototyper kan hjelpe oss her. Kravspesifikasjon

44. Analyse av kravspesifikasjon, sjekkliste Kravspesifikasjon

45. Validering • Sjekker for: • Kompletthet • Konsistens • Nøyaktighet • Avsluttende fase i arbeidet Kravspesifikasjon

46. Input & Output Kravspesifikasjon

47. Reviews Reviews (gjennomgang), teknikk for å verifisere kravspesifikasjonen Kravspesifikasjon

48. Sjekkliste Kravspesifikasjon

49. Prototyping • Validering gjennom prototyping: • Velg testpersoner • Utvikle testscenario • Utfør scenario • Mange krav kan best testes gjennom prototype: • Opplæring • Brukervennlighet • Effektivitet (delvis) Kravspesifikasjon

50. Prosess Kravspesifikasjon