ETS672 Requirements Engineering L5: Validation

ETS672 Requirements Engineering L5: Validation Christin Lindholm Helikoptervy över tekniker & stilar för funktionella krav Datakravstilar:! Datamodell ( =E/R-diagr.)! Dataordlista! Reguljära uttryck! Virtuella fönster Funktionella kravstilar:! Kontextdiagram! Händelse- & Funktionslistor! Produktegenskapskrav! Skärmbilder & Prototyper! Uppgiftsbeskrivningar! Egenskaper från uppgifter! Uppgifter och stöd! (Levande) Scenarier! Högnivåuppgifter! Användningsfall! Uppgifter med data! Dataflödesdiagram! Standardkrav! Krav på utvecklingsprocessen Funktionella detaljer:! Enkla och sammansatta funktioner! Tabeller & Beslutstabeller! Textuella processbeskrivningar! Tillståndsdiagram! Övergångsmatriser! Aktivitetsdiagram! Klassdiagram! Samarbetsdiagram! Sekvensdiagram Speciella gränssnitt! Rapporter! Plattformskrav! Produktintegration! Tekniska gränssnitt Vadå fullständig kravspec? Det är i praktiken omöjligt att specificera allt i minsta detalj! Uppföljning genom förädlingskedja för produktkrav Laxtrappan Verifierat Lanserat Vad är bra nog? -> Beror på situationen Implementerat Tips: Fokusera på de krav som innebär störst risk för Missförstånd bland intressenter Att slutresultatet ej blir önskvärt Värderat Planerat Konceptstudier, förstudier, möjlighetsstudier etc. för att minska risker hoppa mellan abstraktionsnivåer Nytt Godkänt Otydligt Dubblett Omöjligt

Spårbarhet (Traceability) Ändringar i intressenternas behov, önskemål och tekniska antaganden kan kräva radikal omvärdering av kravens relevans. Källa Framåt till krav Bakåt från krav Hur intressenterna medverkat till kraven är viktig information vid validering. Requirements document Req A1: Printing Dependecy Req F8: Color Ansvar för kravuppfyllelse behöver kopplas till systemkomponenter så att ansvarighet och påverkansanalys kan utrönas Framåt från krav Bakåt till krav package samples.simple; Kravuppfyllelse behöver verifieras och design utan krav ( gold-plating ) behöver undvikas. public class Hello1 { public void printhello() { System.out.println( "Hello!" ); } } Design/! Kod/Test Övningarna Eliciterat information Intressentanalys/Målgrupp/Användare Funktionella krav Kvalitetskrav Risker Validera Prioritera Fortsättning Uppdatera information efterhand Handledning i november. Bestäm datum på övning 5 Handledning i december Bestäm datum på handledningen i november Inlämning Färdig kravspecifikation skickas in via mail till christin.lindholm@cs.lth.se senast den 18/12 kl. 24.00 Mapp lämnas in senast den 18/12 kl.12.00 (vån C6) Material från övningarna med kompletteringar Övrigt material om så önskas

Validering - Verifiering Fig 7. Inception Requirements in product life cycle Elicitation Validering - kontroll gentemot egentlig avsikt - Är det rätt system? - Uppfyller vi kundens behov och förväntningar? Formulation Checking Tender Writing proposal Verifiering - kontroll gentemot specifikation - Är systemet rätt? - Har vi gjort det vi sa vi skulle göra? Design & program Contract Comparing proposals Accept test Next release Reqs management & release planning Validering av krav Syfte Att säkerställa att vi har eliciterat och dokumenterat rätt krav Kommer vi att bygga rätt system med dessa krav? Metoder Granskningar Tester Modellbaserad simulering Härledning med matematiska modeller Diskussion Vad finns på önskelistan för kvalitetsegenskaper hos en kravspecifikationen? Men man kan inte få allt

Fig 9.1 Quality criteria for a specification Classic: A good requirement spec is: Correct Each requirement reflects a need. Complete All necessary requirements included. Unambiguous All parties agree on meaning. Consistent All parts match, e.g. E/R and event list. Ranked for importance and stability Priority and expected changes per requirement. Modifiable Easy to change, maintaining consistency. Verifiable Possible to see whether requirement is met. Traceable To goals/purposes, to design/code. Additional: Traceable from goals to requirements. Understandable by customer and developer. From: Soren Lauesen: Software Requirements Exempel på kravattribut för krav i en kravdatabas Attribute State ID Source Description Priority Motivation Specification Decomposition Estimation Schedule Design Test Release Ver Value Unique identity Who issued it? Short textual description Importance cathegory (1,2,3) Rationale: Why is it important? Links to Use Case, Textual spec, Prototype Parent-of / Child-of links to other req s Effort estimation in hours Selected for this release, must /wish-lists Links to design documents Links to test documents Released in this version Assigned in State New New New Approved Approved Evaluated Evaluated Evaluated Planned Implemented Verified Released Fig 9. Checking and validation Goals E/R Tasks Guest Event list Check that all parts match & everything is included Validate that stakeholders are happy (customer, user, developer) Where are the major risks? Quality product = meeting the spec? Correct Each requirement reflects a need. Complete I vilka moment måste All necessary requirements included. man involvera kunden/ Unambiguous användaren? All parties agree on meaning. Consistent All parts match, e.g. E/R and event list. Ranked for importance and stability Priority and expected changes per requirement. Modifiable Easy to change, maintaining consistency. Verifiable Possible to see whether requirement is met. Traceable To goals/purposes, to design/code.

Jävla skitsystem Hej! Systemet har nu blivit uppdaterat + bilaga Jonas Söderström Granskningar Inspections Först beskrivna av M.E. Fagan, IBM, tidigt 70-tal En systematisk utvärderingsteknik där dokument undersöks manuellt av andra än författaren för att detektera defekter Generella mål med granskningar: Detektera defekter Sprida kunskap inom projektet Fatta beslut baserat på granskningsdata Dra lärdomar av granskningsdata Granskningsprocessen Olika sätt att detektera fel (reading techniques) Planning Overview meeting Preparation Inspection meeting Root-cause analysis Correction Roller: Moderator Författare Granskare Sekreterare Follow-up Ad hoc Efter bästa förmåga (inga riktlinjer) Checklista En lista med frågor styr läsningen Perspektivbaserad Olika perspektiv kombineras tex användare, designers, testare Användningsbaserad Prioriterade användningsfall Request List of defects Defect summary Report

Kravvalidering genom olika tester Olika sorters validering genom tester: Manuell simulering baserad på scenarios Pappersprototyper Exekverbara prototyper Pilottester Viktiga steg: Välj adekvat sätt att testa, testmiljö etc Välj vem som ska utföra testen Ta fram testfall Kör testfallen Dokumentera problem Modellbaserad simulering Matematisk härledning Formal Model Checking Identifiera intressant kvalitetsegenskap att simulera (tex prestanda) Implementera en exekverbar modell av systemet (tex en kömodell) Definiera inparametrar och mätetal Kör simuleringar och samla mätdata Analysera resultat och dra slutsatser (tex vad som är realistiska prestandakrav) Används ofta tex i analys av realtidssystem Skapa en formell, matematisk modell av systemet i en formalism med härledningsregler Använd axiom och härledningsregler i den valda formalismen och bevisa intressanta egenskaper hos systemet (t.ex. att vissa oönskade tillstånd aldrig kan uppkomma) Används mest för säkerhetskritiska system

Fig 9.2A Contents check Does the spec contain: Customer, sponsor, background Business goals + evidence of tracing Data requirements (database, i/o formats, comm.state, initialize) System boundaries & interfaces Domain-level reqs (events & tasks) Product-level reqs (events & features) Design-level reqs (prototype or comm. protocol) Specification of non-trivial functions Stress cases & special events & task failures Quality reqs (performance, usability, security ) Other deliverables (documentation, training ) Glossary (definition of domain terms ) Fig 9.2B Structure check Does the spec contain: Number or Id for each requirement Verifiable requirements Purpose of each requirement Examples of ways to meet requirement Plain-text explanation of diagrams, etc. Importance and stability for each requirement Cross refs rather than duplicate information Index An electronic version Fig 9.2C Consistency checks Fig 9.2D CRUD matrix Virtual windows Guest Support? Tasks Create, Read, Update, Delete + Overview Entity Task Guest Stay Room RoomState Service ServiceType Data exists? E/R model CRUD Event check Event list 1. 2. Event check Book C U O C O U O CheckinBooked RU U O O U O CheckinNonbkd C U O C O U O Checkout U U O R U ChangeRoom R R O U O RecordService O C R Function list 1. 2. PriceChange CUDO CUDO Missing? D D C?UD? UD

Fig 9.3 Checks against surroundings Fig 9.4(A) Check list at work Reviews Review: Developers and customer review all parts. Goal-means analysis: Goals and critical issues covered? Requirements justified? Risk assessment: Customer assesses his risk. Developers assess their risk. High-risk areas improved. Just before signing? Tests Simulation and walk-through Follow task descriptions. Correct? Supported? Prototype test (experiment with prototypes): Requirements meaningful and realistic? Prototype used as requirement? Pilot test (install and operate parts of system): Cost/benefit? Requirements meaningful and realistic? Project: Noise Source Location, NSL vers. X Date, who: 99-03-15, JPV Contents check Observations - found & missing Problem? Customer & sponsor Missing, OK Data: Database contents Class model as intermediate work product Initial data & states Missing Seems innocent, but caused many problems particularly when screen windows were opened. Functional reqs: Limits & interfaces Product-level events and functions Special cases: Stress cases Power failure, HW failure, config. Mostly as features Missing Problem. Front-end caused many problems Project: N oise Source Location, NSL vers. X D ate, w ho: 99-03-15, JPV Contents check (2) Observations - found & m issing Problem? Quality reqs: Performance Capacity, accuracy Missing, also in parts not shown here. Missing, also in parts not shown here. Problem. Response time became importa nt. Problem. Data vo lume, etc. became important. U sability Missing Would have been useful Interoperability Missing External dataformats, robot role, etc. caused problems Other deliverables: D ocume ntation Missing Structure check Observations - found & m issing Problem? ID for each req. OK Purpose of each re quireme nt Good. Domain described. Consistency checks Observations - found & m issing Problem? CRUD check: Create, read, update, delete all data? Have been made Unimportant. Company standards exist. Validering när det gäller kraven i ert projekt Hur säkerställer ni att ni har eliciterat och dokumenterat rätt krav? Vilka metoder ska ni använda? Vilka risker finns när det gäller kraven? Tests Observations - found & m issing Problem? Prototype test Not done, nor during development. Should have been done. Caused many problems later.

Summering Validation = check that stakeholders are happy, Är det rätt system? Uppfyller vi kundens behov och förväntningar? Kvalitetskriterier: Korrekt, Komplett, Otvetydig, Konsistent, Prioriterad, Modifierbar, Verifierbar, Spårbar Innehåll, Struktur, CRUD+O Granskningar, Prototyper, Simuleringar, Hårdvarukrav Kravspecifikation Termometer Baserad på mikroprocesser (MC68HC11) Hårdvarukrav Funktionella krav 1. Den skall kunna mäta temperaturen på minst tre olika ställen Kommentar: mäta temperaturen är en för vag beskrivning. Måste bestämma mätnoggrannhet, mätområde och mätintervall för att kunna välja rätt komponenter och programmera processorn på riktigt sätt 2. Aktuell temperatur skall visas på en display, man skall kunna byta givare med tryckknappar. Kommentarer: Två krav i ett. Display vagt. Hur ska produkten användas? Inomhus? Utomhus? Bildskärm? Hur aktuell ska temperaturen vara? Hur ofta uppdateras på skärmen? Tryckknappar Hur många? Beror på användningsområde

3. Temperaturen skall lagras i ett minne, minst 75 (ca ett dygn) mätdata skall kunna lagras. Kommentar: Ska värdena ligga kvar om spänningen försvinner? Ca 3 mätningar i timmen, ok? 4. Mätdata skall kunna hämtas från termometern via porten på datorn. Kommentar: Seriell eller parallell? USB? Hur ska protokollet implementeras? Tänk på Specificera funktionskraven och inte vilka komponenter som ska användas. O Var konkret i kraven ex: O Mätnoggrannhet 0,5 grader O Display 5 siffror O Siffror 1 cm höga På gång Föreläsning nästa vecka Övning nästa vecka Förbered inför labben O Använd öppna krav