Programvarekrav In 140 Sommerville kap 5. Introduksjon Ofte kompliserte situasjoner Vanskelig å stille enkle og klare krav til programvaren Kravspesifikasjonen.

Presentasjon om: "Programvarekrav In 140 Sommerville kap 5. Introduksjon Ofte kompliserte situasjoner Vanskelig å stille enkle og klare krav til programvaren Kravspesifikasjonen."— Utskrift av presentasjonen:

1 Programvarekrav In 140 Sommerville kap 5

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

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

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

5 Hvem leser spesifikasjonene? Brukerkrav Systemkrav Programvare- utforming (Kundens systemutviklere) Systemarkitekter Programvareutviklere Sluttbrukere Kundens systemutviklere Systemarkitekter Programvareutviklere Kundens ledere Sluttbrukere Kundens systemutviklere Kontraktørens ledere Systemarkitekter

6 Brukerkrav Kravene skal være forståelige for brukere uten teknisk kunnskap Holde seg til ytre beskrivelse Ikke implementeringsdetaljer Naturlig språk – problemer –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 Begrunnelser er viktig

7 Retningslinjer ved skriving av brukerkrav 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

8 Systemkrav 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 Bruk av naturlig språk –Krever felles vokabular –For stor fleksibilitet

9 Funksjonelle og ikke funksjonelle krav Funksjonelle krav –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 Ikke funksjonelle krav =Rammer –Tid –Utviklingsprosess –Standarder –Kvalitet Krav som gjelder for anvendelsesområdet –Kan være funksjonelle og ikke funksjonelle

10 Funksjonelle krav Brukerkrav: 1. Systemet skal samle inn og lagre statistiske data om tilstanden i anlegget. Systemkrav 1. 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. 2. Systemet skal lagre løpende gjennomsnitt av verdiene. 3. En melding på skjermen skal vise hva som er problemet 4. Ved flere samtidige alarmer, skal de høyest prioriterte vises først 5. Alarmene skrives ut etter hvert som de oppstår med dato, klokkeslett og detektorens navn og plassering.

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

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

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

14 Ikke-funksjonelle krav 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.

15 Måltall (Metrics) for ikke-funksjonelle krav EgenskapMål HastighetUtførte transaksjoner per sekund, Behandlede hits/s Bruker/hendelsesresponstid, Skjermoppfriskningstid StørrelsekB, MB Brukbarhet (Usability) Treningstid, Antall hjelpesider Gjennomsnittlig betjeningstid per transaksjon PålitelighetMTBF Gjennomsnittstid mellom svikt Oppetid RobusthetMTTR,Gjenstarttid etter svikt Andel av hendelser som fører til svikt PortabilitetAndel av målavhengige setninger Antall mål

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

17 Krav for anvendelsesområdet (Domain requirements) 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 Utelatt informasjon

18 Alternativer til naturlig språk 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 Matematisk spesifikasjon

19 Kravspesifikasjon med PDL(Program description language) 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 Fordel hvis leseren kjenner språket –Klarere, lettere å forstå, lettere overgang til implementering, mindre mulighet for feiltolkning Ulemper –Ikke egnet i alle situasjoner –Krever kjennskap til programmeringsspråk –Kan bli brukt feil: dvs som utformingsspesifikasjon Har sin plass i kombinasjon med strukturert språk

20

21 Grensesnittspesifikasjon Nesten alle systemer skal brukes sammen med eksisterende systemer Grensesnittspesifikasjonen tidlig inn Tre sider av grensesnittet spesifiseres: –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

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

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

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

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

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