Repetition. Repetition. Repetition. ETS672 Requirements Engineering. Lecture 3: Quality Requirements. Christin Lindholm

Relevanta dokument
Föreläsning 3: Elicitering, Kvalitetskrav

Kravhantering rep. Repetition. Repetition. ETS672 Requirements Engineering. Lecture 3: Quality Requirements. Varför är elicitering svårt?

Adding active and blended learning to an introductory mechanics course

LARS. Ett e-bokningssystem för skoldatorer.

Beijer Electronics AB 2000, MA00336A,

Vässa kraven och förbättra samarbetet med hjälp av Behaviour Driven Development Anna Fallqvist Eriksson

Materialplanering och styrning på grundnivå. 7,5 högskolepoäng

Stad + Data = Makt. Kart/GIS-dag SamGIS Skåne 6 december 2017

Support Manual HoistLocatel Electronic Locks

School of Management and Economics Reg. No. EHV 2008/220/514 COURSE SYLLABUS. Fundamentals of Business Administration: Management Accounting

2.1 Installation of driver using Internet Installation of driver from disk... 3

EVALUATION OF ADVANCED BIOSTATISTICS COURSE, part I

Information technology Open Document Format for Office Applications (OpenDocument) v1.0 (ISO/IEC 26300:2006, IDT) SWEDISH STANDARDS INSTITUTE

HANTERING AV UPS CX

FÖRBERED UNDERLAG FÖR BEDÖMNING SÅ HÄR

Chapter 2: Random Variables

School of Management and Economics Reg. No. EHV 2008/245/514 COURSE SYLLABUS. Business and Market I. Business Administration.

Support for Artist Residencies

Schenker Privpak AB Telefon VAT Nr. SE Schenker ABs ansvarsbestämmelser, identiska med Box 905 Faxnr Säte: Borås

Isolda Purchase - EDI

Application Note SW

Module 6: Integrals and applications

3rd September 2014 Sonali Raut, CA, CISA DGM-Internal Audit, Voltas Ltd.

Module 1: Functions, Limits, Continuity

Om oss DET PERFEKTA KOMPLEMENTET THE PERFECT COMPLETION 04 EN BINZ ÄR PRECIS SÅ BRA SOM DU FÖRVÄNTAR DIG A BINZ IS JUST AS GOOD AS YOU THINK 05

Privacy Notice Ålö Group. Customers Integritetspolicy Sverige Privacy Notice UK, North America and International

Frågor och svar till tentamen i Kravhantering. Del 2. Kravhantering (ETS170), LTH Grupp B

Att fastställa krav. Annakarin Nyberg

Theory 1. Summer Term 2010

This exam consists of four problems. The maximum sum of points is 20. The marks 3, 4 and 5 require a minimum

Preschool Kindergarten

Michael Q. Jones & Matt B. Pedersen University of Nevada Las Vegas

Inför projektuppgiften. Markus Buschle,

Taking Flight! Migrating to SAS 9.2!

Resultat av den utökade första planeringsövningen inför RRC september 2005

ISO STATUS. Prof. dr Vidosav D. MAJSTOROVIĆ 1/14. Mašinski fakultet u Beogradu - PM. Tuesday, December 09,

Affärsmodellernas förändring inom handeln

Säkerhetsfunktioner rstå varandra? Finns behov av att avvika från normal säkerhetsfunktion s vissa betingelser under uppstart, ändringar i processen

Mönster. Ulf Cederling Växjö University Slide 1

Skyddande av frågebanken

Här kan du sova. Sleep here with a good conscience

Design för användbarhet Designexempel, hur tänkte man vid designen?

Configuration Management

Resultatkonferens Välkommen!

EASA Standardiseringsrapport 2014

OFTP2: Secure transfer over the Internet

Sara Skärhem Martin Jansson Dalarna Science Park

AGIL KRAVHANTERING. Hitta behoven bakom kraven!! Thomas Nilsson! Agile Coach & Mentor! CTO, Responsive

INSTALLATION INSTRUCTIONS

Custom-made software solutions for increased transport quality and creation of cargo specific lashing protocols.

Kundfokus Kunden och kundens behov är centrala i alla våra projekt

D-RAIL AB. All Rights Reserved.

PROFINET MELLAN EL6631 OCH EK9300

SVENSK STANDARD SS :2010

Revidering av ISO Peter Allvén SIS TK-304/PostNord

Robust och energieffektiv styrning av tågtrafik

Datavetenskap. Beteendevetenskap MDI. Design

Hur fattar samhället beslut när forskarna är oeniga?

Item 6 - Resolution for preferential rights issue.

Enligt IEEE Std har en bra kravspecifikation en mängd fordringar att uppfylla. Kravspecifikationen skall vara;

Här kan du checka in. Check in here with a good conscience

Sectra Critical Security Services. Fel bild

Agenda. Tid Aktivitet Föreläsare Åtgång tid 08:30 Registrering vid TS recep. Transport till våning 5.

Olika typer av krav. Funktionella krav (FR) Kvalitetskrav (NFR) Användbarhet. Olika typer av kvalitetskrav. ETS672 Requirements Engineering

Make a speech. How to make the perfect speech. söndag 6 oktober 13

Kursplan. NA1032 Makroekonomi, introduktion. 7,5 högskolepoäng, Grundnivå 1. Introductory Macroeconomics

Anders Persson Philosophy of Science (FOR001F) Response rate = 0 % Survey Results. Relative Frequencies of answers Std. Dev.

Methods to increase work-related activities within the curricula. S Nyberg and Pr U Edlund KTH SoTL 2017

Software Quality Requirements and Evaluation (SQuaRE) & Common Industry Format (CIF) for Usability snart finns det inga ursäkter längre...

Styrteknik: Binära tal, talsystem och koder D3:1

Att använda data och digitala kanaler för att fatta smarta beslut och nå nya kunder.

InstalationGuide. English. MODEL:150NHighGain/30NMiniUSBAdapter

Medical Informatics Period 2, 2009

LEVERANTÖRSLED; INKÖP OCH UPPHANDLING

Heuristisk utvärdering

Accomodations at Anfasteröd Gårdsvik, Ljungskile

ARC 32. Tvättställsblandare/Basin Mixer. inr.se

Thesis work at McNeil AB Evaluation/remediation of psychosocial risks and hazards.

Del M subpart F - FAQ Organisatorisk granskning

Examensarbete Introduk)on - Slutsatser Anne Håkansson annehak@kth.se Studierektor Examensarbeten ICT-skolan, KTH

Schenker Privpak AB Telefon VAT Nr. SE Schenker ABs ansvarsbestämmelser, identiska med Box 905 Faxnr Säte: Borås

Datasäkerhet och integritet

Dokumentnamn Order and safety regulations for Hässleholms Kretsloppscenter. Godkänd/ansvarig Gunilla Holmberg. Kretsloppscenter

A QUEST FOR MISSING PULSARS

Analys och bedömning av företag och förvaltning. Omtentamen. Ladokkod: SAN023. Tentamen ges för: Namn: (Ifylles av student.

1. Varje bevissteg ska motiveras formellt (informella bevis ger 0 poang)

Manhour analys EASA STI #17214

ISTQB Testarens ledstjärna

Questionnaire for visa applicants Appendix A

Strategy for development of car clubs in Gothenburg. Anette Thorén

Quick Start Guide Snabbguide

1. Compute the following matrix: (2 p) 2. Compute the determinant of the following matrix: (2 p)

RUP är en omfattande process, ett processramverk. RUP bör införas stegvis. RUP måste anpassas. till organisationen till projektet

Metodprov för kontroll av svetsmutterförband Kontrollbestämmelse Method test for inspection of joints of weld nut Inspection specification

Signatursida följer/signature page follows

Förändrade förväntningar

8 < x 1 + x 2 x 3 = 1, x 1 +2x 2 + x 4 = 0, x 1 +2x 3 + x 4 = 2. x 1 2x 12 1A är inverterbar, och bestäm i så fall dess invers.

Transkript:

Repetition ETS672 Requirements Engineering Lecture 3: Quality Requirements Christin Lindholm Repetition Repetition O Varför är elicitering svårt? O Vilka är intressenterna? Barriers: Cannot express what they need Conflicting demands Cannot explain what they do and why Resistance to change May ask for specific solutions Luxury demands Lack of imagination - new ways New demands once Lack of imagination - consequences others are met O Eliciteringstekniker vs Saker att elicitera

Några tekniker till O Card Sorting - kategorisering O Laddering begreppsnätverk O Scenario-analys händelsesekvenser O Etnografiska studier långtidsobservation Card sorting För att arbeta fram en informationsstruktur Antal påstående om t.ex. problem, innehåll -> sorterar dem i kategorier Fördelar: God översikt över användarens syn på problemet Nackdelar: Kräver domänkunskap för gruppering Laddering Skapa förståelse för olika termer. Kan användas som underlag för terminologi Hierarkisk bild över termerna Laddering Skapa förståelse för olika termer. Kan användas som underlag för terminologi Hierarkisk bild över termerna Kravhanteraren kommer med olika påståenden kring termerna. Vid missuppfattning flyttas termerna runt Kravhanteraren kommer med olika påståenden kring termerna. Vid missuppfattning flyttas termerna runt

Laddering forts O Fördelar: O Bra förståelse för termer och begrepp O Medvetandegör olika tolkningar O Nackdelar: O Onödigt om termer och begrepp är välkända Scenario - analys Användningsfalls modellering Beskriver systemet genom att beskriva hur systemets aktörer använder sig av funktioner Scenario analys forts. Fördelar: Bra teknik för normala krav Andra saker än vid intervjuer Nackdelar: Kräver förmåga att hitta relevanta användningsfall Förhållandevis hög inlärningströskel Fig 8.5 Business goals Shipyard goals. Business administration A1. Replace outdated platform P A2. Integrate order documents and database P A3. Use experience data for quotation D A4. Support systematic marketing D A5. Faster capture of cost data Q A6. Speed up invoicing Q Hospital goals. Payroll and roster planning B1. Reduce IT costs Personnel department B2. Automate some tasks B3. Remove error sources B4. Observe deadlines B5. Less trivial work and less stress Hospital department B6. Reduce over- and undertime payment B7. Faster roster planning B8. Improve roster quality Tax payer s association. Membership adm. C1. We cannot do without it. Noise source location. New product D1. Marketing plan. Demand, competitors...

QFD kundcentrerad planering Att gå från domän till krav Fig 8.8 Quality-issue analysis Example: Shipyard, usability Issue: Job calculation easy to learn. Style: Task time. How can we tell? Req. outline: After xx hour course, marketing staff can perform task yy in zz minutes. How can we measure it? Req., final: After hour course, marketing staff can calculate proposal B in minutes. Customer expects 12 hour course. What are xx, yy, and zz? I praktiken behöver man iterera fritt mellan olika aktiviteter och jobba parallellt med olika saker Vem$är$användarna?$ O Ringa in och kartlägg användarna Specificering O Skapa personas O Framstå som en riktig person O Namn O Bild Elicitering Validering O Beskrivning O Relevanta beteenden O Attityd O Behov O Mål Prioritering

O Bertil, 47 år, mäklare Boken O Fru, fyra barn O Åker ofta till sommarhuset på landet O Sara, 28 år, IT-konsult O Ensamstående O Kör till vänner O Ingegärd, 39 år, rörmokare O Hund O Bor i en mindre by O Kör rör och verktyg Olika typer av krav O Funktionella krav (FR) O Anger vad systemet ska göra (input/output) Lauesens stilar & tekniker i relation till processen:! Specificering O Olika stilar för att specificera funktionella krav: Lau:2-5 O Olika stilar för att specificera kvalitetskrav: Lau:6! Elicitering O Olika tekniker för att identifiera kraven: Lau:8! Validering O Olika tekniker för att kontrollera kraven: Lau:9 O Lausens bok fungerar som en katalog över olika stilar & tekniker med information om i vilka sammanhang de passar bra/dåligt FR & NFR hänger ihop I praktiken är funktionella krav och kvalitetskrav svåra att separera då kvalitetskraven manifesterar sig i extra funktionalitet. O Kvalitetskrav (NFR) O Sätter begränsningar på systemet (eller utvecklingsprocessen) O Kan ofta slå tvärs över många funktioner O Styr valet av arkitektur Exempel: kvalitetskrav om säkerhet kräver inloggningsfunktion

Olika typer av kvalitetskrav O Användbarhet O Tillförlitlighet O Prestanda O Skärmbilden ska synas på en meters håll O T ex accepterad nertid O T ex svarstider Diskussion Vilka kvalitetsegenskaper värdesätter du hos en ordbehandlare? O Underhållbarhet O Krav på t ex designen O Säkerhet O T ex inloggning Svåra avvägningar mellan kvalitetskrav O Kvalitetsaspekter ofta motverkande. O Vanliga exempel: Ökad prestanda -> minskad underhållsbarhet Ökad säkerhet -> minskad användbarhet Kräver noggrant övervägda avvägningar! Kvalitetskraven styr arkitekturvalet Produktarkitektur REQ REQ REQ REQ Kostnad? Värde? Långsiktigt vs kortsiktigt? GUI A C L1 L2 B D DB

Requirements measures Property Speed Size Ease of use Reliability Robustness Portability Measure Processed transactions/second User/Event response time Screen refresh time K Bytes Number of RAM chips Training time Number of help frames Mean time to failure Probability of unavailability Rate of failure occurrence Availability Time to restart after failure Percentage of events causing failure Probability of data corruption on failure Percentage of target dependent statements Number of target systems Fig 6.1 McCall US Airforce 1980 Operation: Integrity Correctness!! Reliability Usability Efficiency Revision: Maintainability Testability Flexibility Transition: Portability Interoperability Reusability!! Quality factors ISO 9126 Functionality Accuracy Security Interoperability Suitability!! Compliance!! Reliability Maturity Fault tolerance!! Recoverability!! Usability Efficiency Maintainability Testability Changeability Analysability!! Stability!! Portability Adaptability Installability!! Conformance!! Replaceability!! Use as check lists Fig 6.2 Quality grid Quality factors for Hotel system Critical Operation Integrity/security Correctness Reliability/availab. 1 Usability 2 Efficiency Revision Maintainability Testability Flexibility Important As usual Unimportant Ignore Transition Portability Interoperability 3 4 Reusability Installability 5 Concerns: 1. Hard to run the hotel if system is down. Checking in guests is impossible since room status is not visible. 2. We aim at small hotels too. They have less qualified staff. 3. Customers have many kinds of account systems. They prioritize smooth integration with what they have. 4. Integration with spreadsheet etc. unimportant. Built-in statistics suffice. 5. Must be much easier than present system. Staff in small hotels should ideally do it themselves. Distanskurs i multimedia Ett etablerat företag har beslutat utvidga sin verksamhet till att också omfatta distansutbildning via Internet. Det ska utvecklas en interaktiv distanskurs i multimedia. Kursen ska i första hand finnas i webbform på företagets egen webbserver. Målgruppen för kursen är: Tjänstemän inom den offentliga sektorn. Kursen bör innehålla följande: Bildbehandling: En orientering inom området t.ex. olika filformat, skillnad bitmaps/vektorgrafik. Ev tutorial Design: Orientering om grundläggande design och bildkomposition. Ev tutorial Interaktiva media: En orientering inom området. Flash, interaktiv 3D. Ev tutorial Ljud: En orientering inom området. Filformat, sampling. Ev tutorial Kursens form: Distanskursen ska ha en form som i största möjliga mån engagerar och aktiverar kursdeltagare

Fig 6.3A Open metric and open target Fig 6.3C Cost/benefit of response time Physical limits R1: Product shall detect speed violation and take photo within 0.5 seconds. $ or ratio Best available is 4 minutes? Nobody strives for 2 minutes Open target but how important? Open target + expectations Supplier uses another approach? Open metric R2: Product shall compute a room occupation forecast within 2 minutes. R3: Product shall compute a room occupation forecast within 4 minutes. R4: Product shall compute a room occupation forecast within minutes. R5: Product shall compute a room occupation forecast within minutes. (Customer expects one minute.) R6: Forecast shall be computed with exponential trend smoothing and seasonal adjustments. R7: The supplier shall specify the forecast accuracy for hotels similar to ours. 2 1 1 2 3 4 min Response time Fig 6.4 Capacity and accuracy requirements Fig 6.5A Performance requirements Capacity requirements: R1: The product shall use < 16 MB of memory even if more is available. R2: Number of simultaneous users < 2000 R3: Database volume: #guests < 10,000 growing 20% per year #rooms < 1,000 R4: Guest screen shall be able to show at least 200 rooms booked/occupied per day, e.g. for a company event with a single customer. Accuracy requirements: R5: The name field shall have 150 chars. R6: Bookings shall be possible at least two years ahead. R7: Sensor data shall be stored with 14 bit accuracy, expanding to 18 bits in two years. R8: The product shall correctly recognize spoken letters and digits with factory background noise % of the time. Tape B contains a sample recorded in the factory. Performance requirements: R1: Product shall be able to process 100 payment transactions per second in peak load. R2: Product shall be able to process one alarm in 1 second, 1000 alarms in 5 seconds. R3: In standard work load, CPU usage shall be less than 50% leaving 50% for background jobs. R4: Scrolling one page up or down in a 200 page document shall take at most 1 s. Searching for a specific keyword shall take at most 5 s. R5: When moving to the next field, typing must be possible within 0.2 s. When switching to the next screen, typing must be possible within 1.3 s. Showing simple report screens, less than 20 s. (Valid for 95% of the cases in standard load) R6: A simple report shall take less than 20 s for 95% of the cases. None shall take above 80s. (UNREALISTIC) Cover all product functions?

Fig 6.6D Defects & usability factors Användbarhet 1) Relevans. Stöder arbetsuppgifter? 2) Effektivitet. Snabbt och problemfritt? 3) Tillgänglighet. Lätt hitta nödvändig information? 4) Lärbarhet. Enkelt att lära sig? 5) Attityd. Subjektiv tillfredsställelse. Defect correction Program errors Usability problems Expected Surprising? Inspection OK Inspection low hit-rate Detect in test stage Detect in design stage Mostly simple Often redesign Test equipment OK Subjects hard to find Usability Fit for use = tasks covered + Ease of use = Ease of learning Task efficiency Ease of remembering Subjective satisfaction Understandability Functional requirements Usability factors Fig 6.6A Usability Fig 6.6B Usability problems Usability requirements? R1: System shall be easy to use?? R2: 4 out of 5 new users can book a guest in 5 minutes, check in in 10 minutes,... New user means... Training... Achieving usability Prototypes (mockups) before programming. Usability test the prototype. Redesign or revise the prototype. Easier programming. High customer satisfaction. Defect types Program error: Not as intended by the programmer. Missing functionality: Unsupported task or variant. Usability problem: User cannot figure out... Examples of usability problems P1: User takes long time to start search. Doesn t notice Use F10. Tries many other ways first. P2: Believes task completed and result saved. Should have used Update before closing. P3: Cannot figure out which discount code to give customer. Knows which field to use. P4: Crazy to go through 6 screens to fill 10 fields. Problem classification Task failure: Task not completed - or believes it is completed. Critical problem: Task failure or complaints that it is cumbersome. Medium problem: Finds out solution after lengthy attempts. Minor problem: Finds out solution after short attempts

Fig 6.6C Usability test Realistic introduction Realistic tasks Note problems Observe only or Think aloud & ask Heuristic evaluation Expert s predicted problems Inspection/Review Usability test: Cover all tasks? Mockups find same problems as test with final system? Usability test & heuristic evaluation Log keeper Heuristic evaluation User Usability test findings Facilitator Real problems Fig 6.7(A) Usability requirements Problem counts R1: At most 1 of 5 novices shall encounter critical problems during tasks Q and R. At most 5 medium problems on list. Task time R2: Novice users shall perform tasks Q and R in 15 minutes. Experienced users tasks Q, R, S in 2 minutes. Keystroke counts R3: Recording breakfast shall be possible with 5 keystrokes per guest. No mouse. Opinion poll R4: 80% of users shall find system easy to learn. 60% shall recommend system to others. Score for understanding R5: Show 5 users 10 common error mesages, e.g. Amount too large. Ask for the cause. 80% of the answers shall be correct. Risk Cust. Suppl Fig 6.8A Threats Fig 6.9 Security requirements Wire tapping Product Curious eyes Payslip R1: Safeguard against loss of database. Estimated losses to be < 1 per 50 years. R2: Safeguard against disk crashes. Estimated losses to be < 1 per 100 years. R3: Product shall use duplicated disks (RAID disks). Wire tapping Disk crash R4: Product shall safeguard against viruses that delete files. Remaining risk to be <. R5: Product shall include firewalls for virus detection. Threats Violate Preventions Input, e.g. Examples Mistake Integrity Logical checks Illegal access Authenticity Signature Wire tapping Confidentiality Encryption Storing, e.g. Disk crash Availability RAID disks Program error Integrity Test techniques Virus deletes data Availability Firewall Output, e.g. Transmission Availability Multiple lines Fraud Confidentiality Auditing Virus sends data Authenticity Encryption From: Soren Lauesen: Software Requirements R6: Product shall follow good accounting practices. Supplier shall obtain certification. R7: Product shall prevent users deleting invoices before transfer to the account system. R8: The supplier shall as an option offer features for checking and reserving deposits made by credit cards. R9: The supplier must enclose a risk assessment and suggest optional safeguards.

Fig 6.10 Maintainance Fig 6.11A Maintainability requirements Risk Corrective maintenance Perfective maintenance Product New release Preventive maintenance Maintenance cycle: Report: Record and acknowledge. Analyze: Error, change, usability, mistake? Cost/benefit? Decide: Repair? reject? work-around? next release? train users? Reply: Report decision to source. Test: Test solution. Related defects? Carry out: Install, transfer user data, inform. Maintenance performance R1: Supplier s hotline shall analyze 95% of reports within 2 work hours. Urgent defects (no work around) shall be repaired within 30 work hours in 95% of the cases. R2: When reparing a defect, related non-repaired defects shall be less than 0.5 in average. R3: For a period of two years, supplier shall enhance the product at a cost of per Function Point. Support features R4: Installation of a new version shall leave all database contents and personal settings unchanged. R5: Supplier shall station a qualified developer at the customer s site. R6: Supplier shall deposit code and full documentation of every release and correction at. Cust. Suppl Fig 6.11B Maintainability requirements Development process requirements R7: Every program module must be assessed for maintainability according to procedure xx. 70% must obtain highly maintainable and none poor. R8: Development must use regression test allowing full retesting in 12 hours. Program complexity requirements R9: The cyclomatic complexity of code may not exceed 7. No method in any object may exceed 200 lines of code. Product feature requirements R10: Product shall log all actions and provide remote diagnostic functions. R11: Product shall provide facilities for tracing any database field to places where it is used. Risk Cust. Suppl Summering Kvalitetskrav O Specificera hur väl systemet utför sina funktioner O Många kvalitetsfaktorer: Prestanda, tillförlitlighet O Öppna eller stängda metrics O Risk för kunder eller leverantör? O Användbarhetsfaktorer O Relevans. Stöder arbetsuppgifter? O Effektivitet. Snabbt och problemfritt? O Tillgänglighet. Lätt hitta nödvändig information? O Lärbarhet. Enkelt att lära sig? O Attityd. Subjektiv tillfredsställelse.