1 / 29

Kravanalyse og spesifikasjon

Kravanalyse og spesifikasjon. Logisk beskrivelse av systemet (modeller, spesifikasjoner) Pris Konsekvenser. Mål Rammer Plan Organisasjon. Kravanalyse og spesifikasjon. Design og koding. JA. Skal vi bygge dette systemet. Ja, med modifikasjoner. NEI - STOPP. Spesifikasjon av krav.

gomer
Download Presentation

Kravanalyse og spesifikasjon

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Kravanalyse og spesifikasjon Logisk beskrivelse av systemet (modeller, spesifikasjoner) Pris Konsekvenser Mål Rammer Plan Organisasjon Kravanalyse og spesifikasjon Design og koding JA Skal vi bygge dette systemet Ja, med modifikasjoner NEI - STOPP

  2. Spesifikasjon av krav • Hvorfor er kravspesifisering så vanskelig? • Overordnede prinsipper • Ulike metoder • Tradisjonelle • JAD • Prototyping

  3. Analysefasene - Kravspesifikasjon

  4. Utfordringen • Stabile brukerkrav • Hindre ”requirement creep” • Spesifikasjoner som kan verifiseres og valideres • Korrekte spesifikasjoner

  5. Beskrive: • modeller • protoyper • prosa • formelle spesifikasjoner • Finne: • intervjuer • lese dokumentasjon • prototyping • intensive arbeidsmøter Krav • Validere: • formelle gjennomganger • demo prototyper

  6. ”Vi må ha et nytt fakturasystem!” • Problemstilling • Mye manuelt arbeid, data må hentes fra bestillingssystemet og legges inn på nytt i faktura systemet • Dårlig brukergrensesnitt, ”går ned” ofte • Dårlige feilmeldinger • Fakturaene kontrolleres og godkjennes av flere instanser – når det oppdages feil - retur til saksbehandler som sjekker opp og retter feil før de sendes på ny runde • Konsekvens • Det påløper ofte renter på for sen betaling • Mye overtid

  7. Utdyping av problemet • Behandling av en faktura er beregnet til NOK1500 • Svært mange fakturaer er på småbeløp –> 100-1000 NOK • Det blir ofte bestilt samme vare fra samme firma flere ganger på samme dag, hver slik bestilling resulterer i en egen faktura • Samme vare bestilles fra flere forskjellige firma • Alle fakturaer uansett beløp kontrolleres like grundig av like mange personer

  8. Oppgave – forbind alle punktene med 4 rette linjer UTEN å løfte pennen fra papiret

  9. Modeller og spesifikasjoner Systemkrav Brukerkrav

  10. Brukerkrav • Hva er målet? • Utvikle en ide til en presis og komplett definisjon av brukers krav • kravene er grunnlag for det systemet som skal utvikles • hvis de spesifiserte kravene ikke stemmer med brukers ”virkelige” krav utvikler vi ”feil” system • Hva er utfordringene? • bruker vet ikke alltid hva han vil ha • bruker og systemutvikler snakker ikke samme språk og misforstår hverandre eller bruker blir overkjørt av systemutviklers ekspertise • det beslutningsgrunnlaget som systemutvikler legger fram er for abstrakt til å se konsekvensene av • Hva er ofte resultatet • ustabile brukerkrav • ”requirement creep” • feil system

  11. Krav til brukerstøtte og til forvaltning er med i brukerkravene Servicenivå, SLA Bruker har ”full kontroll” over spesifikasjon Spesifikasjonen er så stabil og så komplett som mulig Det utarbeide et formelt kravdokument som gir en presis og konsistent beskrivelse av alle kjente brukerkrav Kravdokumentet gjennomgås av representanter for: brukere driftspersonell utviklere ledere Kravdokumentet vedlikeholdes Brukerkrav - essensielt

  12. Brukermedvirkning er essensielts

  13. Systemkrav - spesifikasjon • En logisk beskrivelse • Skal være bygd opp rundt en logisk modell av systemet • skal dekke alle brukerkravene (vis knytning) • Skal inneholde krav til forvaltning og brukerstøtte • Skal IKKE inneholde implementasjonsavhengige detaljer • Hva ikke hvordan • Flere formelle ”dokumenter” • Ulike aspekter i ulike dokumenter • Bruk en mal!!

  14. Systemkrav • Detaljerte, tekniske spesifikasjoner som omfatter: • automatiserte funksjoner, funksjonslogikk, inndata og utdata • manuelle rutiner • skjermbilder • Grensesnitt mot andre systemer • Logisk datamodell og beskrivelse av alle dataelementer • spesifikasjon av egenskaper • spesifikasjon av krav til sikkerhet • Spesifikasjonen skal være så detaljert at vi kan gi den til en annen gruppe og forvente at de lager ”riktig” system

  15. Systemkrav - eliminasjon av feil: • Systemkravene skal gjennomgås av: • Brukere ? • Databaseeksperter • Utviklere • Driftspersonell • Bruk formelle inspeksjoner

  16. Hvilke ”dokumenter”? • Tore: • Funksjonelle krav • Egenskapskrav • Software Quality: • Brukerkrav • Systemkrav • Caper Jones • Logisk datamodell og dataspesifikasjoner • Eksterne grensesnitt • Funksjonelle krav • Prinsipp: • Èn sak i et dokument • Vedlikeholdes og versjonskontrolleres som en enhet

  17. Vesentlige spørsmål • Et komplett, stabilt sett eller litt om gangen? • Skal vi være kreative eller formelle?

  18. Hva er JAD? • Hva og hvorfor? • Hvem deltar? • Gjennomføring • Planlegging • Selve møtet • etterarbeid • Utstyr • Teknikker og verktøy • Regler • Kritiske suksessfaktorer

  19. Et intensivt arbeidsmøte?

  20. Et annet

  21. JAD - idedugnad

  22. JAD - kommunikasjon

  23. - Om prototyping • Hva er prototyping? • Bruk og kast • Evolusjonær prototyp • Hva prototypes? • Brukergrensesnitt • Generelt: Liten bit system som skal testes ut

  24. Arbeidsgang Intervjuer, lesning, møte Modellering, tekstlig beskrivelse Kommentering fra brukerne Lag prototyp Gjennomgang med brukerne!!!!

  25. Eksempel på spørsmål til brukerne • Beskriv hvilke arbeidsoppgaver du • Beskriv for hver arbeidsoppgave i hvilken rekkefølge du vil gjøre oppgaver og hvilke skjermbilder du vil bruke? • For hvert skjermbilde, hva vil du legge inn av data i hvilken rekkefølge? • For hvert skjermbilde: • hvor vil du ha rullegardin-menyer? • hvor vil du ha standardverdier, hvilke? • liker du farger, lay-out? • Hva gjør du hvis det skjer (spesifiserte)feil?

  26. There is no such thing as a free lunch • Husk å dokumentere mål og hensikt og kriterier for å måle om hensikten er oppnådd • Lage en plan! • Analyser og dokumenter resultatene! • Det finnes ingen ”korrekt” måte å prototype på • Ikke la en prototyp som er beregnet som et raskt eksperiment utvikle seg til et ferdig system! • En prototyp som skal utvikle seg til et ferdig system, har samme krav til kvalitet, dokumentasjon, v&v etc. som et ”vanlig” system • Prototyping er vanedannende – uten skikkelig planlegging og styring kan dette bli dyrt!

  27. Tracking av brukerkrav • ”every major feature in a delivered software application can be tracked back to a specific user requirement” • Allikevel ikke vanlig – gjennomført av <25%

  28. Endringskontroll • Beste praksis: • Utpek en ”endringskontrollgruppe” som skal behandle forslag til endringer • Formaliser innlevering av endringsforslag – må dokumenteres og begrunnes • Vurder bruk av verktøy for administrasjon av endingsforslag • Bruk JAD-sesjoner for behandling av endringsforslag • Bruk FP for å dokumentere konsekvensen av endringer • Dokumenter resultatet av behandlingen • Planlegg videreutvikling av systemet over flere år NB!!!!!!

More Related