PV7040 - Programvarukonstruktion Föreläsning 4

F4: Omfattning Kapitel 5 Mindre noggrann läsning: inget

Syfte med föreläsningen Att introducera kravbegrepp Att beskriva funktionella och kvalitativa krav (icke-funktionella) Att visa en möjlig lösning på hur man kan organisera krav i ett dokument

Kravhantering (Requirements Engineering) Den process som definierar krav och begränsningar kunden ställer på systemet som skall utvecklas Kraven är i sig själva beskrivningar av systemtjänster och begräsningar som framkommer under kravhanteringen

Vad är ett krav? En beskrivning som kan variera i abstraktionsnivå och omfattning Från enklare skönlitterära beskrivningar Till matematiska beskrivningsmodeller Krav kan därför fungera på flera olika sätt bl.a.; De kan fungerar som bas för en upphandling och skall därför vara öppen för tolkning De kan fungera som ett kontrakt och skall därför vara definierade i detalj

Exempel (Davis) “If a company wishes to let a contract for a large software development project, it must define its needs in a sufficiently abstract way that a solution is not pre-defined. The requirements must be written so that several contractors can bid for the contract, offering, perhaps, different ways of meeting the client organisation’s needs. Once a contract has been awarded, the contractor must write a system definition for the client in more detail so that the client understands and can validate what the software will do. Both of these documents may be called the requirements document for the system.”

Olika typer av krav Användarkrav Beskrivningar i naturligt språk och diagram över tjänsterna systemet skall erbjuda och dess begränsningar. Främst skriven för kunden. Systemkrav Ett strukturerat dokument som beskriver systemfunktionerna detaljerat. Främst skriven för att verka som ett kontrakt mellan kund och utvecklare. Programvaruspecifikation (Software specification) En detaljerad beskrivning som kan verka som bas för design eller implementering. Skriven för utvecklare.

Definition och specifikation, exempel

Kravdokumentets läsare

Funktionella och kvalitativa krav Funktionella krav Beskrivningar av systemtjänster Hur systemet skall agera på viss indata Hur systemet skall agera i en viss situation Kvalitativa krav (icke-funktionella krav) Begränsningar på tjänster och funktioner som systemet erbjuder såsom Prestanda Domänkrav Krav som kommer ifrån systemdomänen och speglar systemdomänens egenskaper

Funktionella krav Beskriver funktionaliteten eller tjänster i systemet Beror på Typ av programvara Förväntade användare Typ av system där programvara används Funktionella användarkrav bör vara högnivå beskrivningar av vad systemet skall göra Funktionella systemkrav skall beskriva systemets funktioner i detalj

Exempel på funktionella krav Användaren skall kunna söka efter information i hela eller delar av databasen Systemet skall erbjuda lämpliga vyer till användaren som skall läsa dokument i dokumentförvaringen Varje order skall tilldelas ett unikt nummer (ORDER_ID) vilket användaren skall kunna kopiera till kontots permanenta lagringsutrymme

Kravs otydlighet (imprecision) Problem uppkommer när kraven inte är precist uttryckta Tvetydiga krav kan tolkas på olika sätt av utvecklare och användare Studera uttrycket ”lämpliga vyer” i föregående exempel Användarens tolkning – varje dokument skall läsas i den bläddrare som har bäst egenskaper för att visa dokumentet Utvecklarens tolkning – erbjuda en bläddrare som visar innehållet i varje dokument

Färdiga krav och konsekvens i krav Krav skall i princip vara både färdiga och konsekventa Färdiga De skall tillgodose alla beskrivningar som behövs Konsekventa Det får inte finnas några konflikter eller motsägelser i beskrivningarna av systemtjänster

Kvalitativa krav (icke-funktionella krav) Definierar systemegenskaper och begränsningar såsom tillförlitlighet, svarstider och utrymmeskrav Begränsningar är t.ex. I/O- enheters kapacitet Krav på utvecklingsprocessen kan också uttryckas som kvalitativa krav t.ex. krav på användning av ett specifikt CASE-verktyg eller programmeringsspråk Kvalitativa krav kan vara viktigare än funktionella krav – om inte de kvalitativa kraven uppfylls kan systemet vara värdelöst

Indelning av kvalitativa krav (icke-funktionella krav) Produktkrav Krav som specificerar att den levererade produkten måste uppträda på ett visst sätt, t.ex. tillförlitlighet Organisatoriska krav Krav som är konsekvensen av organisations politik och procedurer såsom använda process- standarder eller krav på implementation Externa krav Krav som kommer ur systemets omvärld såsom lagstiftning eller interoperabilitet mellan systemet och omvärlden

Kvalitativa krav – olika typer

Exempel på kvalitativa krav Produktkrav 4.1.1. All nödvändig kommunikation mellan APSE och användaren skall kunna uttryckas med symboler ur Adas teckentabell Organisatoriska krav 9.3.2. Systemets utvecklingsprocess och dokument skall uppfylla IEEE830 standarden Externa krav 7.6.5. Systemet skall inte vidarebefordra information om våra kunder till användaren förutom namn och referensnummer

Mål och krav Kvalitativa krav kan vara svåra att precisera exakt och otydliga krav kan vara svåra att verifiera Mål är det generella syftet med varje användning av systemet Verifierbara kvalitativa krav – ett uttryck som kan testas med någon form av mätning Mål är god hjälp för utvecklaren när denne skall förstå användares intentioner Det kan finnas flera typer av mål, affärsmål, systemmål eller funktionsmål

Exempel Ett systemmål: Systemet skall vara enkelt att använda av erfarna kontrollanter och skall vara organiserat så att användarfel minimeras Ett verifierbart kvalitativt krav: Erfarna kontrollanter skall kunna använda alla systemfunktioner efter två timmars utbildning. Efter denna utbildning skall medeltalet fel inte överstiga 2 per dag för erfarna kontrollanter

Mätning av krav

Krav påverkar andra krav Det kan finnas konflikter mellan kvalitativa krav och de är vanliga i komplexa system Exempel (Rymdfärjan-systemet): För att ha så låg vikt som möjligt skall det enskilda antalet chip minimeras För att ha så låg strömförbrukning krävs det att lågenergichip används Om man använder lågenergichip så krävs det fler chip. Vilket är det viktigaste kravet?

Domänkrav Krav som kan härledas till applikationsdomänen och beskriver systemegenskaper och förmågor som återspelas och återspeglar domänen Kan vara ny funktionalitet, begränsningar på existerande krav eller definiera nya operationer i systemet Om domänkrav inte tillgodoses kan systemet vara utan värde

Bibliotekssystemets domänkrav Det skall finnas ett standard användargränssnitt till alla databaser. Användargränssnittet skall baseras på Z39.50 standarden. Eftersom det kan finnas upphovsrättsliga krav måste vissa dokument skrivas ut så fort de ankommit. Beroende på användarens krav så skall dokumentet skrivas ut lokalt eller via nätverkskrivare.

Tåg säkerhetssystemet Inbromsningen av tåg skall beräknas enligt följande: Dtrain = Dcontrol + Dgradient Där Dgradient är 9.81m/s2 * compensated gradient / alpha och värdet är känt för olika typer av tåg

Problem med domänspecifika problem Förståelse Kraven är uttryckta på ett sådant sätt eller med ett sådant språk att endast individer i domänen kan förstå det Kraven kan inte förstå av utvecklare Tysta krav Domänspecialisterna glömmer bort självklara krav

Användarkrav Beskrivning av funktionella eller kvalitativa krav på så sätt att de är förståliga av systemanvändarna som inte har detaljerad teknisk kunskap Beskrivs med naturligt språk, tabeller och diagram

Problem med naturligt språk Avsaknad av precision Det är svårt att precist uttrycka kravet utan att det blir svårt att läsa Förvirring med funktionella och kvalitativa krav De båda grupperna tenderar att blandas ihop Kravstapling Många krav klumpas ihop med varandra

Krav för databas 4.4.4. The database shall support the generation and control of configuration objects; that is, objects which are themselves groupings of other objects in the database. The configuration control facilities shall allow access to the objects in a version group by the use of an incomplete name.

Krav för editorgrid 5.1.1. Grid facilities To assist in the positioning of entities on a diagram, the user may turn on a grid in either centimetres or inches, via an option on the control panel. Initially, the grid is off. The grid may be turned on and off at any time during an editing session and can be toggled between inches and centimetres at any time. A grid option will be provided on the reduce-to-fit view but the number of grid lines shown will be reduced to avoid filling the smaller diagram with grid lines.

Kravproblem Databaskravet inkluderar både konceptuell och detaljerad information Beskriver konceptet med konfigurations kontrollfunktioner Inkluderar detaljen om att objekt kan nås genom att använda ett ofullständigt namn Editorkravet blandar tre olika typer av krav Konceptuellt funktionellt krav (behovet av en grid) Kvalitativt krav (grid units) Kvalitativt användarkrav (grid switching)

Strukturerad presentation

Detaljerat användarkrav

Riktlinjer för att skriva krav Skapa ett standardformat och följ detta för alla krav Använd språket på en konsekvent sätt. Använd t.ex. ”skall” för obligatoriska krav och ”kan” för önskade krav. Använd fet eller kursiv stil för att identifiera nyckelpunkter i texten Undvik datorfackspråk Skriv dokumentet för den som skall läsa det Dokumentet skall läsas fler gånger än vad det skrivs – lägg ner tid på att göra det bra

Systemkrav Mer detaljerad specifikation av användarkraven Skall tjäna som bas för designen av systemet Kan till viss del användas som kontrakt Systemkrav kan beskrivas som modeller (se kap. 7)

Krav och design I teorin skall kraven uttrycka vad systemet skall göra och designen uttrycka hur systemet gör det I praktiken kan kraven och designen vara odelbar En systemarkitektur kan vara designad för att följa strukturen hos kraven Systemet kan interagera med system som därmed påverkar designen Kravet på en viss design kan komma ifrån domänen

Problem med naturligt språk Tvetydighet Läsarna och skribenten av kravet måste tolka orden på samma sätt. Naturligt språk är generellt sett tvetydigt och därför är det svårt att undvika För flexibelt Samma sak kan uttryckas på många olika sätt i specifikationen Ej anpassat Naturligt språk och dess språkstrukturer är inte lämpat för att uttrycka krav

Övning Blunda, sträck ut din arm ifrån kroppen och lägg din fingerspets på nästippen

Alternativ till naturligt språk

Structured language specification En begränsad form av det naturliga språket som kan användas för att uttrycka krav Tar bort delar av problemen med tvetydighet och flexibilitet Skapar en likformighet Vanligtvis lättast att göra med hjälp av formulär

Formulärbaserade specifikationer Definition av funktion eller enhet Beskrivning av indata och var de kommer ifrån Beskrivning av utdata och var de skall hamna Indikation av enheter som behövs Om möjligt beskrivs Förutsättningar Följder Biverkningar

Exempel

PDL-baserad kravdefinition Krav kan definieras med ett programmeringsspråks- liknande språk Har större flexibilitet att uttrycka saker Lämpligt att använda när En funktion specificeras som en serie med händelser där den inbördes ordningen är av stor betydelse Man skall specificera gränssnitt mellan maskinvara och programvara Nackdelar: PDL kan kanske inte beskriva domänspecifika koncept Specifikationen är mer en design än en specifikation

Delar av en specifikation för en bankomat

Nackdelar med PDL PDL behöver inte vara tillräckligt uttrycksfullt för att beskriva systemfunktionalitet på ett begripligt sätt Beskrivningen är förstålig endast av folk som kan programmera Kravet tolkas som design när det bara skall bringa förståelse för systemet

Beskrivning av gränssnitt De flesta system måste köras med andra system och kontaktytor (gränssnitt) måste definieras och specificeras som en del av kraven Tre typer kan behövas specificeras Procedur gränssnitt Datastrukturer som överförs Data representation Formella notationer är effektiva sätt att specificera gränssnitt

PDL beskrivning av gränssnitt

Kravdokumentet De flesta kravdokument är den officiella beskrivningen av vad som krävs av systemutvecklarna Bör inkludera både en definition och en specifikation av kraven Är inte ett designdokument. Skall främst vara en mängd VAD systemet skall göra och inte HUR det skall göras

Användare av specifikationen

Krav på kravdokumentet Specificerar externa systems uppträdande Specificerar implementationsbegränsningar Lätt att ändra En bas för underhåll av programvaran

IEEE-standard på kravdokument Omfattar följande delar av dokumentet Introduktion Generell beskrivning Bilagor Index

Kravdokumentets struktur Introduktion Ordlista Definition av användarkrav Systemarkitektur Systemets kravspecifikation System modeller System evolution Bilagor Index

Instuderingsfrågor 5.6 Beskriv tre olika typer av icke-funktionella krav som kan förekomma i ett system. Ge exempel på alla tre typerna. 5.7 Skriv ett antal (4 st) icke-funktionella krav för biljettsystemet (se fråga 5.2), specificera ut den förväntade tillförlitligheten och svarstider.