In 140 Forelesning Nr 7 Sommerville kap 5

Presentasjon om: "In 140 Forelesning Nr 7 Sommerville kap 5"— Utskrift av presentasjonen:

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

2 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

3 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

4 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

5 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

6 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

7 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

8 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.

9 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

10 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

11 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

12

13 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.

14 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

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

16 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

17 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

18 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

19 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

20 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

21 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

22 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

23

24 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

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

26 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

27 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

28 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

29 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