In 140 Forelesning Nr 7 Sommerville kap 5 Programvarekrav In 140 Forelesning Nr 7 Sommerville kap 5

Mål Forstå ideen bak brukerkrav og systemkrav og hvorfor de krever hver sin skrivemåte Forstå forskjellen mellom funksjonelle og ikkefunksjonelle krav Forstå to teknikker for å uttrykke systemkrav Strukturert naturlig språk Programmeringsspråkbasert beskrivelse Forstå hvordan kravspesifikasjonen kan organiseres i et kravspesifikasjonsdokument

Introduksjon Ofte kompliserte problem Vanskelig å stille klare krav til programvaren Begrepsforvirring – kravspesifikasjon Fra kunden: Generell og abstrakt binder ikke løsning Fra leverandøren:Konkret beskrivelse av hva han vil levere forpliktende og validerbar Derfor bør vi tydeliggjøre med to begrep Brukerkravspesifikasjon Systemkravspesifikasjon Programvareutformingsspesifikasjon

Kravspesifikasjonene Brukerkrav Naturlig språk og diagrammer Tjenester og rammer Systemkrav (Funksjonelle krav) Detaljert beskrivelse av tjenester og rammer Presist Grunnlag for kontrakt (Programvareutformingsspesifikasjon) Abstrakt utformingsbeskrivelse Mer detaljert enn systemkrav Overgang til utforming

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

Hvem leser spesifikasjonene? Kundens ledere Sluttbrukere Kundens systemutviklere Kontraktøres ledere Systemarkitetker Brukerkrav Sluttbruekere Kundens systemutviklere Systemarkitekter Programvareutviklere Systemkrav Programvare-utformings-spesifikasjon (Kundens systemutviklere) Systemarkitekter Programvareutviklere

Funksjonelle og ikke 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

Funksjonelle krav 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. Systemet skal beregne 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 ettervert som de oppstår med dato, klokkeslett og detektorens navn og plassering.

Funksjonelle krav - Bibliotekssystemeksempel 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 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

Ikke funksjonelle krav Systemegenskaper pålitelighet svartid lagringsbehov Rammer Begensninger ved IOenheter Krav til datarepresentasjon ved systemgrensesnitt Ikkefunksjonelle krav ofte kritisk Klassifisering Produkktkrav Organisatoriske krav Eksterne krav

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 verisfiserbart 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 ikkefunksjonelle krav Egenskap Mål Hastighet Utførte transaksjoner per sekund, Behandlede hits/s Bruker/hendelsesresponstid, Skjermoppfriskningstid Størrelse kB, 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

Ikkefunksjonelle 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?

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

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

Rutenett For å lette posisjonering av enheter på et diagram, kan brukeren slå på et rutenett i cm eller tommer via et valg på kontrollpanelet. Ved starten er rutenettet avslått. Rutenettet kan slås av og på når som helst under en editeringssesjon og man kan velge mellom cm og tommer når som helst. Rutenettopsjon blir også plassert i tilpass størrelse visnig, men antall rutenettlinjer vil bli redusert for å unngå å fylle det mindre arealet med rutenettlinjer. Blanding av bruker og systemkrav Varierende detaljeringsgrad

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

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 vokabulær For stor fleksibilitet

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 Design Description Language Grafiske beskrivelser Matematisk spesifikasjon

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

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

Kravspesifikasjonsdokumentet Offisiell dokumentasjon av kravene Inneholder brukerkrav og systemkrav Lesere er ledelsen i bestillerorganisasjonen prosjektleder systemutviklere testutviklere vedlikeholdere

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 feilhendelser håndteres

IEEE/ANSI 830 - 1993 Introduksjon Generell beskrivelse Formål for kravspesifikasjonen Produktets formål Definisjoner, akronymer og forkortelser Referanser Oversikt over resten av dokumentet Generell beskrivelse 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. Tillegg Indeks

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 ikkefunksjonelle krav. Beskrives med tekst, kart og annen forståelig skrivemåte

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