F5

Question 1

Verification

Answer 1

The software should conform to its requirements specification.
– Are we building the product right?

Question 2

Validation

Answer 2

The software should do what
the user really requires.
– Are we building the right product?

Question 3

VALIDERING AV KRAV

Answer 3

– Att säkerställa att vi har eliciterat och dokumenterat rätt krav
– ”Kommer vi att bygga rätt system med dessa krav?”

Question 4

validering av krav metoder

Answer 4

– Granskningar
– Tester
– Modellbaserad simulering
– Härledning med matematiska modeller

Question 5

GRANSKNINGAR (INSPECTIONS)

Answer 5

– En systematisk utvärderingsteknik där dokument undersöks manuellt av andra än författaren för att detektera defekter
• Generellamålmedgranskningar:
– Detektera defekter
– Sprida kunskap inom projektet
– Fatta beslut baserat på granskningsdata – Dra lärdomar av granskningsdata

Question 6

GRANSKNINGS- PROCESSEN

Answer 6

planning - preparation - inspection meeting - correction - follow up

Question 7

OLIKA SÄTT ATT DETEKTERA FEL (READING TECHNIQUES)

Answer 7

• Adhoc
– 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
– Utgå från användningsfall • N-faldig
– 􏰀N-foldinspection􏰀ärenvariantavinspektionerdärmananvänder sig av flera lag med olika individer för att hitta defekter.

Question 8

EXPERIENCES reviews

Answer 8

• average number of hours per found error
• number of errors found per review unit (e.g. page of design)
• efficiency: reviews are 2-10 times more efficient than tests • reviews take time: 4-15% of a project’s resources
• can we motivate this
• reviews improve the quality
• reviews improve the productivity
• example: error in deployment costs $10.000 - which can pay for many hours of review
• Reviews can replace testing

Question 9

KRAVVALIDERING GENOM

OLIKA TESTER

Answer 9

– Manuell ”simulering” (walk-through) baserad på
scenarios/use cases/task descriptions
– Pappersprototyper
– Exekverbara prototyper
– Pilottester

Question 10

Checking and validation

Answer 10

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?

Question 11

Classic: A good requirement spec is:

Answer 11

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.

Question 12

Contents check

Answer 12

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

Question 13

Consistency checks

Answer 13

virtual window tasks E/Rmodel 1 VW 2 eventlist function list

Question 14

CRUD matrix

Answer 14

Create, Read, Update, Delete + Overview

Question 15

testing

Answer 15

Testing is the process in which a (probably unfinished) program is executed with the goal to find errors.

Question 16

purpose of testing

Answer 16

Detect deviations from specifications • Debugging
• Establish confidence in software • Operational testing
• Evaluate properties of software
• Reliability, Performance, Security, Usability etc

Question 17

bugs trace

Answer 17

Humans make ERRORS, that may lead to SW containing FAULTs. When executing such SW it may lead to FAILURE.
• FAULTS are also sometimes called “BUGS” or “DEFECTS”.

Question 18

Software inspections

Answer 18

Concerned with analysis of
the static system representation to discover problems (static verification and validation)
– May be supplement by tool-based document and code analysis.

Question 19

Software testing:

Answer 19

Concerned with exercising and observing product behaviour (dynamic verification and validation)
– The system is executed with test data and its operational behaviour is observed.

Question 20

VERIFICATION AND VALIDATION TECHNIQUES

Answer 20

Static defects detection: Reading techniques
• Inspections: rigorous evaluation using a check list of items
• Walkthrough: Examine source code/detailed design
• Reviews: Often done by document owners
Dynamic defect detection: testing

Question 21

Installation test:

Answer 21

Hardware, software, external products. Test basic functionality.

Question 22

System test:

Answer 22

Test all requirements.
(Except those needing daily operation) Stress test, special cases, etc.
Special data base contents.

Question 23

Deployment test:

Answer 23

Production data (data conversion). Test real user tasks with real users.

Question 24

Acceptance test:

Answer 24

= System test + Deployment test.

Question 25

Operational test:

Answer 25

Test remaining requirements, e.g. response times, availability, hot-line . .