1. Anskaffelse og kravspecifikation SR9_Checking

2. SR9: Checking and validation Kilder SR: Soren Lauesen: Software requirements - Styles and techniques. Addison-Wesley, 2002. UID: Soren Lauesen: User interface design - A software engineering perspective. Addison- Wesley, 2005. Fra kapitel 5. SL-07: Søren Lauesen: Vejledning til kravskabelon SL-07. Samfundslitteratur, 2007. Ekstra: Nye slides som ikke har noget sidestykke i bøgerne. Mange slides er vist i dansk oversættelse. © 2002, 2005, Pearson Education retains the copyright to the slides from the books, but allows restricted copying for teaching purposes only. It is a condition that the source and copyright notice is preserved on all the material.

3. 3. SR9. Checking and validation Guest Event list Goals Tasks E/R 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? From: Soren Lauesen: Software Requirements © Pearson / Addison-Wesley 2002

4. 4. SR9.1 Quality criteria for a specification IEEE 830: A good requirement spec is: Correct Each requirement reflects a need. From: Soren Lauesen: Software Requirements © Pearson / Addison-Wesley 2002 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

5. 5. SR9.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...) From: Soren Lauesen: Software Requirements © Pearson / Addison-Wesley 2002 SL-07 ?

6. 6. SR9.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 From: Soren Lauesen: Software Requirements © Pearson / Addison-Wesley 2002

7. 7. SR9.2C Consistency checks Guest Event list 1. 2.... Tasks E/R model Function list 1. 2.... CRUD Event check Event check Support? Data exists? Data exists? Virtual windows From: Soren Lauesen: Software Requirements © Pearson / Addison-Wesley 2002

8. BookC E OC O E O CheckinBooked RE E O O E O CheckinNonbkdC E OC O E O Checkout E E O R E ChangeRoom R R O E O RecordService OC R PriceChangeC EDOC EDO Missing? D DC?ED? ED 8. SR9.2D CREDO matrix Create, Read, Edit, Delete, Overview Guest Stay Room RoomState Service ServiceType Entity Task From: Soren Lauesen: Software Requirements © Pearson / Addison-Wesley 2002 Classic name: CRUD

9. 9. SR9.3 Checks against surroundings 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. 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? Just before signing? From: Soren Lauesen: Software Requirements © Pearson / Addison-Wesley 2002

10. 10. SR9.4 Check list at work From: Soren Lauesen: Software Requirements © Pearson / Addison-Wesley 2002

12. Kravområde Dialog-funktion Data Integration Platform Svartid Sikkerhed Brugervenlighed Love & regler Support Vedligehold 12. Ekstra: Tre af kravenes dimensioner Forretn. mål Domæne Produkt Design Proces Kravniveau Ja-nej Talskala Point (fx 5-trinskala) Kan ikke vurderes Målemetode