Programvarekrav In 140 Sommerville kap 5 Introduksjon Ofte
- Slides: 26
Programvarekrav In 140 Sommerville kap 5
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 – 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 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 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 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 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 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 =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 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 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 – 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 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 – 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 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 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 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 • • 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 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 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 – Representanter fra bestillerorganisasjonen – prosjektleder – systemutviklere – testutviklere – vedlikeholdere
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 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 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 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
- Hva betyr introduksjon
- Kap kap kape voda
- Kap 140 autopilot ils approach
- Kap 140 autopilot
- Elaine sommerville
- Sommerville
- Sommerville
- Sommerville software engineering slides
- Sommerville
- Inżynieria oprogramowania ian sommerville
- Sommerville
- Sommerville 2007
- Simple aspect example
- Sommerville
- Engineering software products ian sommerville
- Sommerville
- Damian sommerville
- Sommerville
- Kap josua hutapea
- Kap tools
- Sawadee krap meaning
- Kp fastigheter
- Kap modell
- Kap kut
- Modelo kap educacion para la salud
- Kemikalier
- Kovalent binding