Programvarekrav In 140 Sommerville kap 5 Introduksjon Ofte

  • Slides: 26
Download presentation
Programvarekrav In 140 Sommerville kap 5

Programvarekrav In 140 Sommerville kap 5

Introduksjon Ofte kompliserte situasjoner n Vanskelig å stille enkle og klare krav til programvaren

Introduksjon Ofte kompliserte situasjoner n Vanskelig å stille enkle og klare krav til programvaren n Kravspesifikasjonen n – Generell og abstrakt, binder ikke løsning – Konkret beskrivelse av hva han vil levere forpliktende og validerbar – Avhengig av systemutviklingsmodell n Bør være klar på hva vi mener om kravspesifikasjon – Grunnlag for kontrakt

Kravspesifikasjonene n Brukerkrav – Naturlig språk og diagrammer – Tjenester og rammer n Systemkrav

Kravspesifikasjonene n Brukerkrav – Naturlig språk og diagrammer – Tjenester og rammer n Systemkrav – Detaljert beskrivelse av tjenester og rammer – Presist – Grunnlag for kontrakt n Spesifikasjon av programutforming – Abstrakt beskrivelse av utforming – Mer detaljert enn systemkrav – Overgang til utforming

Eksempel Brukerkravspesifikasjon 1 Programvaren må gi muligheter for å presentere og gi tilgang til

Eksempel Brukerkravspesifikasjon 1 Programvaren må gi muligheter for å presentere og gi tilgang til filer som er lagd av andre verktøy Systemkravspesifikasjon 1. 1 1. 2 1. 3 1. 4 1. 5 Brukeren skal utstyres med muligheter til å definere filtypen til eksterne filer Hver ekstern filtype kan ha et tilhørende verktøy som kan brukes på fila Hver ekstern filtype kan bli vist med et ikon i brukerens skjermbilde Brukeren skal kunne velge hvilken ikon som skal knyttes til hver ekstern filtype Når brukeren klikker på ikonet knyttet til en ekstern fil, skal virkningen være å bruke verktøyet på fila

Hvem leser spesifikasjonene? Brukerkrav Kundens ledere Sluttbrukere Kundens systemutviklere Kontraktørens ledere Systemarkitekter Systemkrav Sluttbrukere

Hvem leser spesifikasjonene? Brukerkrav Kundens ledere Sluttbrukere Kundens systemutviklere Kontraktørens ledere Systemarkitekter Systemkrav Sluttbrukere Kundens systemutviklere Systemarkitekter Programvareutviklere Programvareutforming (Kundens systemutviklere) Systemarkitekter Programvareutviklere

Brukerkrav Kravene skal være forståelige for brukere uten teknisk kunnskap n Holde seg til

Brukerkrav Kravene skal være forståelige for brukere uten teknisk kunnskap n Holde seg til ytre beskrivelse n Ikke implementeringsdetaljer n Naturlig språk – problemer n – Presist og utvetydig kan lett bli ordrikt og tunglest – Lett å blande funksjonelle og ikke funksjonelle krav, systemmål og utformingsavgjørelser – Flere krav kan lett bli uttrykt som en. For mye informasjon binder systemutvikleren n Begrunnelser er viktig n

Retningslinjer ved skriving av brukerkrav n Lag og følg et standardformat – Eksempel: Startkravet

Retningslinjer ved skriving av brukerkrav n Lag og følg et standardformat – Eksempel: Startkravet i feit skrift, alltid begrunnelse og referanse til kravspek – Konsistent språkbruk – Skal og bør – Kursiv på viktige deler av kravspesifikasjonen – Unngå teknisk språkbruk

Systemkrav n n n Mer detaljert enn brukerkrav Kan være grunnlag for kontrakt Komplett

Systemkrav n n n Mer detaljert enn brukerkrav Kan være grunnlag for kontrakt Komplett og konsistent Startsted for utviklingsarbeidet. Hva skal systemet gjøre – ikke hvordan det skal bygges. – Startarkitektur kan være nødvendig – Systemet skal fungere sammen med andre system n Bruk av naturlig språk – Krever felles vokabular – For stor fleksibilitet

Funksjonelle og ikke funksjonelle krav n Funksjonelle krav – – n Ikke funksjonelle krav

Funksjonelle og ikke funksjonelle krav n Funksjonelle krav – – n Ikke funksjonelle krav =Rammer – – n Hva skal systemet utføre Hvordan skal det reagere på forskjellige inndata Hvordan skal det håndtere forskjellige situasjoner Hva skal systemet ikke gjøre Tid Utviklingsprosess Standarder Kvalitet Krav som gjelder for anvendelsesområdet – Kan være funksjonelle og ikke funksjonelle

Funksjonelle krav n 1. 2. 3. 4. 5. Brukerkrav: Systemet skal samle inn og

Funksjonelle krav n 1. 2. 3. 4. 5. Brukerkrav: Systemet skal samle inn og lagre statistiske data om tilstanden i anlegget. Systemkrav For hver detektor skal brukeren kunne slå av og på datalogging. Brukeren bestemmer også tid mellom målinger og antall målinger som skal lagres. Systemet skal lagre løpende gjennomsnitt av verdiene. En melding på skjermen skal vise hva som er problemet Ved flere samtidige alarmer, skal de høyest prioriterte vises først Alarmene skrives ut etter hvert som de oppstår med dato, klokkeslett og detektorens navn og plassering.

Funksjonelle krav Bibliotekssystemeksempel 1. 2. 3. Brukeren skal ha mulighet til å søke i

Funksjonelle krav Bibliotekssystemeksempel 1. 2. 3. Brukeren skal ha mulighet til å søke i alle eller et utvalg av databaser Systemet skal inneholde leseprogramvare som kan brukes til å lese dokumenter fra dokumentdatabasen Hver ordre skal tildeles et unikt ordrenummer (order_id) som brukeren kan kopiere til sin kontos lagerområde

Funksjonelle krav n Kan skrives med varierende detaljering n Mange problemer med uklar formulering

Funksjonelle krav n Kan skrives med varierende detaljering n Mange problemer med uklar formulering – Tidspressede utviklere velger minste motstands vei. => Misfornøyde kunder og senere endringer, dyre endringer. n Funksjonell kravspesifikasjon bør være komplett og konsistent – Brukere har ulike synsvinkler

Ikke-funksjonelle krav n Systemegenskaper – pålitelighet – svartid – lagringsbehov n Rammer – Lover

Ikke-funksjonelle krav n Systemegenskaper – pålitelighet – svartid – lagringsbehov n Rammer – Lover og regler – Begrensninger ved IO-enheter – Krav til datarepresentasjon ved systemgrensesnitt Ikke funksjonelle krav ofte kritisk n Klassifisering n – Produktkrav – Organisatoriske krav – Eksterne krav

Ikke-funksjonelle krav n Kan være vanskelige å verifisere – Generelle mål vs målbare krav

Ikke-funksjonelle krav n Kan være vanskelige å verifisere – Generelle mål vs målbare krav – Kan gi grunnlag for krangel Eksempel krav til brukbarhet (usability) Som mål: Systemet skal være lett å bruke for erfarne operatører og skal organiseres slik at det blir minst mulig feilbetjening Som verifiserbart krav: Erfarne operatører skal kunne bruke systemet etter to timers opplæring og etter dette skal de ikke gjøre mer enn gjennomsnittlig to feilbetjeninger per dag.

Måltall (Metrics) for ikke-funksjonelle krav Egenskap Mål Hastighet Utførte transaksjoner per sekund, Behandlede hits/s

Måltall (Metrics) for ikke-funksjonelle krav Egenskap Mål Hastighet Utførte transaksjoner per sekund, Behandlede hits/s Bruker/hendelsesresponstid, Skjermoppfriskningstid Størrelse k. B, MB Brukbarhet (Usability) Treningstid, Antall hjelpesider Gjennomsnittlig betjeningstid per transaksjon Pålitelighet MTBF Gjennomsnittstid mellom svikt Oppetid Robusthet MTTR, Gjenstarttid etter svikt Andel av hendelser som fører til svikt Portabilitet Andel av målavhengige setninger Antall mål

Ikke-funksjonelle krav Måltallene kan testes under systemtest n Ikke alltid så lett i praksis

Ikke-funksjonelle krav Måltallene kan testes under systemtest n Ikke alltid så lett i praksis n – Kunden klarer ikke å oversette krav til måltall – Noen krav er vanskelige å måle • Vedlikeholdbarhet – Kan være kostbart n Konsekvensen er en blanding av mål og verifiserbare krav – Nyttig, men kan feiltolkes Kan komme i konflikt med hverandre eller funksjonelle krav n Bør de skilles fra funksjoneller settes i sammenheng? n

Krav for anvendelsesområdet (Domain requirements) n Krav som er spesielle for anvendelsesområdet – Lover

Krav for anvendelsesområdet (Domain requirements) n Krav som er spesielle for anvendelsesområdet – Lover og regler – En bokført transaksjon skal ikke kunne slettes – Opptatt oksygen beregnes som (Oi-Ou)*F/M Fagterminologi n Utelatt informasjon n

Alternativer til naturlig språk n Strukturert naturlig språk – Begrenset naturlig språk – Skjemabasert

Alternativer til naturlig språk n Strukturert naturlig språk – Begrenset naturlig språk – Skjemabasert • • Objektsentrert, Funksjonssentrert eller Hendelsessentrert Beskrivelse av funksjon eller entitet Beskrivelse av inndata og kilde Beskrivelse av utdata og sluk Beskrivelse av tjenester som brukes. Pre og post betingelser Sideeffekter Grafiske beskrivelser n Matematisk spesifikasjon n

Kravspesifikasjon med PDL(Program description language) n n n Beskrivelsesspråk laget på grunnlag av et

Kravspesifikasjon med PDL(Program description language) n n n Beskrivelsesspråk laget på grunnlag av et programmeringsspråk. Nøyaktig beskrivelse av hendelsesforløp og reaksjoner Kan sjekkes automatisk Kan være for nær implementering Anbefales når: – Anvendelsen består av sekvenser av enklere handlinger der bestemt rekkefølge er nødvendig – Ved spesifikasjon av grensesnitt mellom subsystemer n Fordel hvis leseren kjenner språket – Klarere, lettere å forstå, lettere overgang til implementering, mindre mulighet for feiltolkning n Ulemper – Ikke egnet i alle situasjoner – Krever kjennskap til programmeringsspråk – Kan bli brukt feil: dvs som utformingsspesifikasjon n Har sin plass i kombinasjon med strukturert språk

Grensesnittspesifikasjon Nesten alle systemer skal brukes sammen med eksisterende systemer n Grensesnittspesifikasjonen tidlig inn

Grensesnittspesifikasjon Nesten alle systemer skal brukes sammen med eksisterende systemer n Grensesnittspesifikasjonen tidlig inn n Tre sider av grensesnittet spesifiseres: n – Prosedyrer • Når eksisterende system har mange tjenester som kalles gjennom prosedyrer (API er) • Kan beskrives med PDL – Datastrukturer • Kan beskrives med javabasert PDL eller ER-diagram – Datarepresentasjon • Noen detaljer kan ikke beskrives i Java

Kravspesifikasjonsdokumentet n Offisiell dokumentasjon av kravene n Inneholder brukerkrav og systemkrav n Lesere er

Kravspesifikasjonsdokumentet n Offisiell dokumentasjon av kravene n Inneholder brukerkrav og systemkrav n Lesere er – Representanter fra bestillerorganisasjonen – prosjektleder – systemutviklere – testutviklere – vedlikeholdere

Krav til kravspesifikasjonen (Henninger 1980) n Bare ytre oppførsel n Rammer for implementering n

Krav til kravspesifikasjonen (Henninger 1980) n Bare ytre oppførsel n Rammer for implementering n Lett å forandre n Egne seg som oppslagsbok for vedlikehold n Bør vise omtanke for livssyklusen n Bør vise hvordan feilsituasjoner håndteres

IEEE/ANSI 830 - 1993 1. Introduksjon 1. 2. 3. 4. 5. 2. Generell beskrivelse

IEEE/ANSI 830 - 1993 1. Introduksjon 1. 2. 3. 4. 5. 2. Generell beskrivelse 1. 2. 3. 4. 5. 3. Formål for kravspesifikasjonen Produktets formål Definisjoner, akronymer og forkortelser Referanser Oversikt over resten av dokumentet Produktperspektiv Produktfunksjoner Brukeregenskaper Generelle rammer Forutsetninger og avhengigheter Bestemte krav med Funksjonelle, ikke funksjonelle og grensesnittkrav. Størst, men ikke spesifisert pga store forskjeller i bransjen. 4. 5. Tillegg Indeks

Mulig standard basert på IEEE 830 n Forord Definere lesere og versjonshistorie n Introduksjon

Mulig standard basert på IEEE 830 n Forord Definere lesere og versjonshistorie n Introduksjon Behovet, funksjoner, andre systemer, plass i organisasjonens forretning n Ordliste Forklaring av alle tekniske begrep. Noen av leserne er ikke teknisk kyndige. n Brukerkravspesifikasjon Tjenester, funksjonelle og ikke-funksjonelle krav. Beskrives med tekst, kart og annen forståelig skrivemåte

Mulig standard basert på IEEE 830 forts. n Systemarkitektur Oversikt med fordeling av funksjoner

Mulig standard basert på IEEE 830 forts. n Systemarkitektur Oversikt med fordeling av funksjoner på moduler n Systemkravspesifikasjon Funksjonelle og ikke funksjonelle krav mer detaljert. (Grensesnitt til andre systemer) n Systemmodeller Dataflytmodeller, Objektmodeller og datamodeller viser systemet og forholdet til omgivelsene n Systemevolusjon Forutsetninger og forutsette forandringer n Tillegg Mer spesifikk informasjon: Kan være Maskinvarespesifikasjon databaser. . . n Indeks