IBC EUROFORUM Test i kravspecifikationsfasen Otto Vinter Seniorkonsulent DELTA IT-processer Tel: , Fax:

Hvorfor teste i kravspecifikationsfasen ? Kravspecifikationsfejl fundet efter frigivelsen af produktet koster op til 1000 gange mere end hvis de findes under udarbejdelsen af kravene –B. Boehm 1976 Kun 16% af alle projekter overholdt tid, budget og opfyldt alle krav. 43% af resten havde problemer relateret til kravspecifikationsprocessen –Standish Chaos Report % af DELTAs anbefalinger ved assessments vedrører mangler i virksomhedernes kravspecifikationsproces

Analyser af fejlrapporter hos Brüel & Kjær viste, at 51% af de rapporterede fejl kan henføres til problemer med kravspecifikationen 64% af de kravrelaterede fejl var Usability problemer 28% skyldtes samspillet med software fra eksterne leverandører Kun 22% af problemerne var egentlige funktionalitetsproblemer Med støtte fra EU: PRIDE Final Report: Hvorfor teste i kravspecifikationsfasen ?

Tidlig test er med til at sikre –at det er det rigtige produkt der udvikles –mindske risikoen for fejl under udviklingen –øge muligheden for at overholde tidsplanen, fordi der er færre ting der skal laves om. Tidlig test kræver at –kravspecifikationsprocesserne er tilstrækkeligt modne –der anvendes effektive kravspecifikationsteknikker

Process ManagementProject ManagementEngineeringSupport Organizational Process Performance Quantitative Project Management 4 Organizational Innovation and Deployment Causal Analysis and Resolution 5 Project Planning Project Monitoring and Control Supplier Agreement Management Requirements Management Configuration Management Process and Product Quality Assurance Measurement and Analysis 2 GG 2 Institutionalize a Managed Process Organizational Process Focus Organizational Process Definition Organizational Training Integrated Project Management for IPPD Risk Management Integrated Teaming Integrated Supplier Management Requirements Development Technical Solution Product Integration Verification Validation Organizational Environ- ment for Integration Decision Analysis and Resolution 3 GG 3 Institutionalize a Defined Process

Verifikation vs. Validering Validering –Laver vi det rigtige produkt? –Dvs. tilfredsstiller vi behovet i brugssituationen? Verifikation –Laver vi produktet rigtigt? –Er det der står i kravspecifikationen er korrekt og konsistent

Requirements Development (RD) Formål Producere og analysere kundens krav og kravene til produkter og produktkomponenter. Specifikke mål –SG 1 Develop Customer Requirements Interessenternes behov, forventninger, begrænsninger og grænseflader indsamles og beskrives som kundekrav. –SG 2 Develop Product Requirements Kundekravene raffineres og udbygges for at frembringe krav til produkter og produktkomponenter. –SG 3 Analyze and Validate Requirements Kravene analyseres og valideres, og en beskrivelse af den krævede funktionalitet udarbejdes.

Validation (VAL) Formål Demonstrere at et produkt eller en produktkomponent tilfredsstiller den tiltænkte anvendelse, når den placeres i det tiltænkte miljø. Specifikke mål –SG 1 Prepare for Validation Forberedelse af validering udføres. –SG 2 Validate Product or Product Components Produkter eller produktkomponenter valideres for at sikre at de er anvendelige i deres tiltænkte brugsmiljø.

Verification (VER) Formål Sikre at udvalgte arbejdsprodukter møder de specificerede krav til disse. Specifikke mål –SG 1 Prepare for Verification Forberedelse af verifikation udføres. –SG 2 Perform Peer Reviews “Peer review” udføres for udvalgte arbejdsprodukter. –SG 3 Verify Selected Work Products Udvalgte arbejdsprodukter verificeres mod de specificerede krav til dem.

Defect Analysis Technique Interview sessions –1-2 developers and 1-2 process consultants –app. 5 minutes / bug Bug Categorisation –based on a bug taxonomy by Boris Beizer: Boris Beizer: Software Testing Techniques, Van Nostrand Reinhold, –comprehensive set of bug categories and statistics Capture Subjective Information on the Bugs –where and how the bug occurred –complexity of bug (correction cost) –what could prevent the bug

Effective Requirements Techniques (PRIDE) Requirements Elicitation and Validation –Scenarios Relate demands to use situations. Describe tasks for each scenario. –Usability Test, Daily Tasks, Navigational Prototype Check that the users are able to use the system for daily tasks, based on a navigational prototype of the user interface. Verification of Requirements Specification –Let Product Expert Review Screens Let a product expert check for deviations from earlier product styles. –External Software Stress Test Test that the external software fulfills the expectations in the requirements, with special emphasis on extreme cases. –Orthogonality Check Check of requirements specification to see whether an operation or feature can be applied whenever it is useful. –Performance Specifications Check of requirements specification to see whether it contains performance goals for the requirements. Details in the PRIDE final report:

Results: Improved Product & Process Product was selling steadily more than twice as many copies –compared to a similar product developed for a similar domain by the same team Usability is exceptional in the market –Users’ interaction with the product was totally changed as a result of the early usability tests Almost three times increase in productivity for the development of the user interface –72% reduction in usability issues per new screen –27% reduction in problem reports

Resultater med Scenarier, Prototyping og Usability tests Scenarier, prototyping og usability tests er –effektive teknikker til at skabe bedre produkter, –identificerer de rigtige behov, –muliggør bedre videnoverførsel fra kunden til udviklingsprojektet, –skaber bedre samspil internt i udviklingsprojektet. Tilstrækkelig moden Requirements Definition proces –Kravspecifikationsprocessen var ikke længere et problem ved det næste BOOTSTRAP assessment

Kontakt Otto Vinter Project Manager, M.Sc. IT Processer Venlighedsvej 4 DK Hørsholm Denmark Tel. (+45) Mobil (+45) Fax (+45) DELTA

Requirements Techniques Introduced Scenarios (Use Situations) –Relate demands to use situations. Describe the essential tasks for each scenario. –Write down short descriptions for each known use situation. Explain the work environment, purpose of the work, and the people working. –List the essential tasks for each use situation. Tasks should have a goal, a beginning, and a termination. Usability Test with Navigational Prototype –Check that the users are able to learn and use the system for daily tasks with a prototype of the user interface. –Navigational means: screens have static content; menu points and buttons automatically change to another screen. –The technique tests the prototype with users simulating daily tasks, revises the design, tests it again, and so on until the result is acceptable.

Scenario Template Title 1. User – who, background, experience, domain knowledge 2. Time and Place – setting, environment, conditions, constraints 3. Purpose – goal of the user, problems to solve, accomplishments 4. Narration – the story: meeting the goal, events, decisions, actions 5. Exceptions – variants, special cases, not the “sunny day” scenario 6. Tasks – specific jobs, goal related, strong closure concept 7. Our System – interfaces, interactions, goal support

Usability Test Environment PC V Experiment Leader User Log Keeper Tape Recorder Microphone

Resultater med Scenarier, Prototyping og Usability tests Identificere de rigtige behov –Udviklerne kommer i forbindelse med kunder og brugere –Nedskrivning af brugssituationer dokumenterer behovene –Behovene valideres gennem usability tests på tidlige prototyper –Valideringen gennem usability tests giver en bedre prioritering af behovene Bedre videnoverførsel fra kunde/bruger til projekt –Udviklerne skal selv skrive scenarier og gennemføre usability tests –”Tænke højt” princippet under usability tests afslører det brede spektrum af domæneviden

Resultater med Scenarier, Prototyping og Usability tests Bedre samspil i udviklingsprojektet internt –Fælles sprog og fælles forståelse –Bedre udnyttelse af interne eksperter –Oplæring af nye medarbejdere –Forbedret salgs/markedsføringsdokumentation og test Teknikkerne er effektive –Teknikkerne medfører ikke flere krav kun øget detaljering –Teknikkerne koster ikke mere tid totalt på projektet, kun fordelingen ændres –Effekten opnås kun gennem hård projektstyring og processtøtte Teknikkerne giver bedre produkter –Bedre understøttelse af brugerens reelle behov –Forbedret brugerinteraktion –Færre fejl

ISO 9001 Specification Phase Project & Product Specification Requirement Specification Architectural Design NPI-plan Development Tasks Marketing Plan Quality Assurance Plan Schedule f. Dev’t Phase Updated Communic. Plan Total Financial Estimate Risk Analysis/Prev. Actions Commercial Technical/Skill Organisational/Teamwork Review Reports Check List f. Req. Phase Approved Pre-project Phase 0 Development & Stabilization Phase 2 Operations & Maintenance Phase 3 Complete Specifications Documentation Check List Architectural Design Build Scenario Build Mock-up Usability test Built & Trained Team Team Roles Skills Profile Educational Requirements Vision/Scope Document List of Partners Major Mile Stones defined Plan for Spec. Phase Specified Tasks Schedule for Spec. Phase Estimated Schedule Dev’t Ph. Communications Plan Updated Risk Analysis Preventive Actions Phase 1 Project Initiation Project Basis Team Building & Training Planning of Specification Phase 3.1 Approval Approved Scope and Plan 3.2 Approval Approved Specifications

Requirements Management (REQM) Formål Styre kravene til projektets produkter og produktdele og identificere inkonsistens imellem disse krav og projektets dokumenter og arbejdsresultater. Specifikke mål –SG 1 Manage Requirements Der er styr på kravene og inkonsistenser med projektplaner og arbejdsresultater identificeres.

Requirements Management (REQM) SG 1 Manage Requirements –SP 1.1 Opnå en fælles forståelse af indholdet i kravene med kravleverandørerne –SP 1.2 Opnå projektdeltagernes accept af kravene –SP 1.3 Styr ændringer til kravene under projektforløbet –SP 1.4 Oprethold sporbarhed begge veje mellem kravene på den ene side og projektets planer og arbejdsprodukter på den anden –SP 1.5 Identificer og håndter uoverensstemmelser mellem projektets planer og arbejdsprodukter – og kravene

Generiske Mål for REQM (modenhedsniveau 2) GG 2: The process is institutionalized as a managed process At requirements management (REQM) processen: –GP 2.1 Er underlagt en fastlagt og vedligeholdt politik –GP 2.2 Er planlagt og udført i overensstemmelse med politikken –GP 2.3 Udføres med tilstrækkelige ressourcer –GP 2.4 Har placeret udførelsesansvar og -myndighed –GP 2.5 Udføres af dertil oplærte personer –GP 2.6 Underkaster arbejdsprodukter tilstrækkelig konfigurationsstyring –GP 2.7 Identificerer og involverer relevante interessenter som planlagt –GP 2.8 Monitorerer og kontrollerer processen ift. planen – og at den korrigeres om nødvendigt –GP 2.9 Bliver objektivt evalueret mht. overholdelse af standarder og procedurer – og at afvigelser håndteres –GP 2.10 Gennemgår aktiviteter, status og resultater med højere niveauer i ledelsen – og at problemer løses

Requirements Development (RD) SG 1 Develop Customer Requirements SP 1.1 Afdæk interessenternes behov, forventninger, rammebetingelser og grænseflader for alle faser af produktets livscyklus. SP 1.2 Beskriv interessenternes behov, forventninger, rammebetingelser og grænseflader som kundekrav.

Requirements Development (RD) SG 2 Develop Product Requirements SP 2.1 Etabler og vedligehold krav til produkter og produkt- komponenter, baseret på kundekravene. SP 2.2 Alloker kravene til hver produktkomponent. SP 2.3 Identificer krav til grænseflader.

Requirements Development (RD) SG 3 Analyze and Validate Requirements SP 3.1 Etabler og vedligehold brugskoncepter (operational concepts) og tilhørende scenarier. SP 3.2 Etabler og vedligehold en definition af den krævede funktionalitet. SP 3.3 Analyser kravene for at sikre at de er nødvendige og tilstrækkelige. SP 3.4 Analyser kravene for at balancere interessenternes behov og rammebetingelser. SP 3.5 Valider kravene for at sikre at det resulterende produkt vil opføre sig som forventet I brugerens miljø, ved brug af flere teknikker når det er relevant.

Verification (VER) SG 1 Prepare for Verification SP 1.1Udvælg de arbejdsprodukter, der skal verificeres, samt verifikationsmetoder der anvendes for hvert af dem. SP 1.2Etabler og vedligehold det miljø, der skal bruges for at understøtte verifikation. SP 1.3Etabler og vedligehold verificeringsprocedurer og –kriterier for de udvalgte arbejdsprodukter.

Verification (VER) SG 2 Perform Peer Reviews SP 2.1Forbered peer review for udvalgte arbejdsprodukter. SP 2.2Gennemfør peer review for udvalgte arbejdsprodukter og identificer observationer fra reviewet. SP 2.3Analyser data omkring forberedelse, gennemførelse og resultater fra peer review.

Verification (VER) SG 3 Verify Selected Work Products SP 3.1Gennemfør verifikation af de udvalgte arbejdsprodukter. SP 3.2Analyser resultater fra alle verifikationsaktiviteter og identificer korrigerende handlinger.

Validation (VAL) SG 1 Prepare for Validation SP 1.1Udvælg de produkter og produktkomponenter, der skal valideres, samt de valideringsmetoder der anvendes for hvert af dem. SP 1.2 Etabler og vedligehold det miljø, der skal bruges for at understøtte validering. SP 1.3Etabler og vedligehold procedurer og kriterier for validering.

Validation (VAL) SG 2 Validate Product or Product Components SP 2.1Udfør validering af de udvalgte produkter og produkt- komponenter. SP 2.2Analyser resultaterne fra valideringsaktiviteterne og identificer relevante observationer.

Let product expert review screens (280) Purpose Let a product expert check screens for deviations from earlier product styles. Procedure The product expert reviews the screens, etc. one by one. He might catch other usability problems as well.

External software stress test (301) Purpose Test that the external software fulfills the expectations in the product requirements, with special emphasis on extreme cases. Procedure Take the requirements one by one. For each requirement that relies on external software for its implementation, test that the software actually provides what is needed, especially in extreme cases.

Orthogonality check (721) Purpose Specific check of requirements specification and object model to see whether an operation or feature can be applied whenever it is useful. Procedure Operations and features are selected from the requirements and the object model. For each operation and feature it is checked that it can be used on all features/objects where it makes sense. Generic operations and features and common sense operations are added.

Performance specifications (820) Purpose Specific check of requirements specification to see whether it contains performance goals for the requirements, thus giving specific goals for the developers. Procedure Take the requirements one by one. Check that realistic ranges and accuracy are specified for those requirements that involve time, space, amounts etc. Also check/verify tacit assumptions, and interactions with other systems or hardware. For requirements that involve the user interface, identify frequent tasks and tentatively break them down into individual task steps. Specify a response time for each task step, using experience data for annoyance thresholds.