PV Programvarukonstruktion

En presentation över ämnet: "PV Programvarukonstruktion"— Presentationens avskrift:

1 PV7040 - Programvarukonstruktion
Föreläsning 4

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

3 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

4 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

5 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

6 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.”

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

8 Definition och specifikation, exempel

9 Kravdokumentets läsare

10 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

11 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

12 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

13 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

14 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

15 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

16 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

17 Kvalitativa krav – olika typer

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

19 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

20 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

21 Mätning av krav

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

23 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

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

25 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

26 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

27 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

28 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

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

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

31 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)

32 Strukturerad presentation

33 Detaljerat användarkrav

34 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

35 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)

36 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

37 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

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

39 Alternativ till naturligt språk

40 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

41 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

42 Exempel

43 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

44 Delar av en specifikation för en bankomat

45 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

46 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

47 PDL beskrivning av gränssnitt

48 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

49 Användare av specifikationen

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

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

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

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