Quality of Usage ScenariosQuality of Usage Scenarios

Copyright, 2000 © Jerzy R. Nawrocki

Jerzy.Nawrocki@put.poznan.pl

www.cs.put.poznan.pl/jnawrocki/mse/quality/

Quality Management Quality Management

Lecture 3Lecture 3

Quality Management Quality Management

Lecture 3Lecture 3

J. Nawrocki, Quality Manag., Lecture 3

Plan of the lecturePlan of the lecturePlan of the lecturePlan of the lecture

IntroductionDocument structureVerification checklistProcess descriptionMeasurements

J. Nawrocki, Quality Manag., Lecture 3

IntroductionIntroductionIntroductionIntroduction

‘Scenarios are examples of interaction sessions which are concerned with a single type of interaction between an end-user and the system.’System End-user

1 + 1 ?1 + 1 ?

is 10

BinaryBinaryI meanI mean

J. Nawrocki, Quality Manag., Lecture 3

IntroductionIntroductionIntroductionIntroduction

Scenario contents (Sommervill):

• initial state of the system• normal flow of events• exceptions• concurrent activities• final state of the system

scenario

J. Nawrocki, Quality Manag., Lecture 3

Document structureDocument structureDocument structureDocument structure

1 Introduction

1.1 Purpose of the document

1.2 Viewpoints and stakeholders

1.3 Brief description of the system

1.4 Business case for the system

1.5 Definitions, acronyms and abbreviations

1.6 References

1.6 Overview of the remainder of the document

Concept of the system

J. Nawrocki, Quality Manag., Lecture 3

Document structureDocument structureDocument structureDocument structure

2 Usage scenarios 2.1 Scenario P1: Printing a file 2.1.1 Actor(s) John is ... 2.1.2 Goal John wants to ... 2.1.3 Behaviours description

Concept of the system (contd.)

J. Nawrocki, Quality Manag., Lecture 3

Document structureDocument structureDocument structureDocument structure

2.1.3 Behaviours description 2.1.3.1 Behaviour B1: Normal Start state Flow of data and events Final state 2.1.3.2 Behaviour B2: LP does not work Start state Flow of data and events Final state

Concept of the system (contd.)

J. Nawrocki, Quality Manag., Lecture 3

Document structureDocument structureDocument structureDocument structure

2.1.4 Rationale / Contribution to the organisation’s goals 2.1.5 Possible problems 2.1.6 Source(s) of the scenario3. Non-functional requirements4. Risk factors & system feasibility5. Workload for scenarios elicitation 5.1 Planned 5.2 Actual

Concept of the system (contd.)

J. Nawrocki, Quality Manag., Lecture 3

Document structureDocument structureDocument structureDocument structure

6 Change requests 6.1 Accepted 6.2 Rejected7. Questionnaire for reviewersAppendix: Rejected scenarios

Concept of the system (contd.)

J. Nawrocki, Quality Manag., Lecture 3

Verification checklistVerification checklistVerification checklistVerification checklist

• Does the document follow the standard document structure?

• Is the list of viewpoints complete?• Is the list of viewpoints clearly described?• Is the list of stakeholders complete?• Are the stakeholders clearly described (one

needs at least: role description, name of the person, e-mail, phone/address)?

J. Nawrocki, Quality Manag., Lecture 3

Verification checklistVerification checklistVerification checklistVerification checklist

• Is the brief description of the system clear and complete?

• Is the business case for the system clearly and completely described?

• Are all the terms and abbreviations explained?• Is that explanation clear?• Is the list of references complete?• Is each reference completely described?• Are the referenced items available for the

team?

J. Nawrocki, Quality Manag., Lecture 3

Verification checklistVerification checklistVerification checklistVerification checklist

• Is the overview of the remainder of the document clear, complete, and not too lengthy?

• Is each scenario important from the business perspective?

• Is it technically feasible to implement each scenario?

• Is each scenario clearly described?• Is the set of behaviours complete?• Is the rationale for each scenario convincing?

J. Nawrocki, Quality Manag., Lecture 3

Verification checklistVerification checklistVerification checklistVerification checklist

• Is the list of possible problems complete?• Are the possible problems clearly described?• Are the sources of scenarios well

documented?• Are the non-functional requirements clearly

stated?• Does the list of non-functional requirements

contain the project deadline / duedate?• Are any important and probable risk factors

missing on the list?

J. Nawrocki, Quality Manag., Lecture 3

Verification checklistVerification checklistVerification checklistVerification checklist

• Is the workload information well documented?• Are change requests well documented?

J. Nawrocki, Quality Manag., Lecture 3

Process descriptionProcess descriptionProcess descriptionProcess description

A. Initial / next version of the document Wednesday 13:00 - Monday 10:00 Sending the document out by Monday 10:00B. Individual preparation to the meeting Monday 11:00 - Tuesday 14:00C. Internal/formal review meeting (Tu 15:00|16:30)D. Writing the meeting minutes Tuesday 18:00 - Wednesday 12:00 Sending the minutes out by Wednesday 12:00

Week schedule

J. Nawrocki, Quality Manag., Lecture 3

Process descriptionProcess descriptionProcess descriptionProcess description

1. Initial version (11 - 18.10) ~ 4 scenarios2. Second version (18 - 25.10) ~ 10 scenarios3. Third version (25.10 - 1.11) ~ 10 scenarios4. Formal review (1.11 - 8.11)

Sending the document out by 3.11, Fri, 10:005. Follow-up & document freezing (8.11 - 14.11)

The usage scenario phase

J. Nawrocki, Quality Manag., Lecture 3

Process descriptionProcess descriptionProcess descriptionProcess description

1. Initial Project Description 2.10.00 - 11.10.002. Usage scenarios 11.10.00 - 14.10.003. Software Requirements Specification 15.10.00 - 19.12.004. Software Plan 20.12.00 - 30.01.01

Early phases

J. Nawrocki, Quality Manag., Lecture 3

MeasurementsMeasurementsMeasurementsMeasurements

A. Initial / next version of the document

B. Individual preparation to the meeting

C. Internal/formal review meeting

D. Writing the meeting minutes

Time spent on ..

J. Nawrocki, Quality Manag., Lecture 3

MeasurementsMeasurementsMeasurementsMeasurements

Sending the document out by Monday 10:00

C. Starting internal/formal review meeting

Sending the minutes out by Wednesday 12:00

Delays in ..

J. Nawrocki, Quality Manag., Lecture 3

MeasurementsMeasurementsMeasurementsMeasurements

xxxx

Defects in ..

J. Nawrocki, Quality Manag., Lecture 3

MeasurementsMeasurementsMeasurementsMeasurements

• Usage scenarios developed in each week• Time spent on preparing Initial Project Descr.

J. Nawrocki, Quality Manag., Lecture 3

SummarySummarySummarySummary

Verification procedure is based on the document structure

J. Nawrocki, Quality Manag., Lecture 3

Further readingsFurther readingsFurther readingsFurther readings

• I. Sommerville, P. Sawyer, Requirements Engineering, John Wiley & Sons, Chichester, 1997.

J. Nawrocki, Quality Manag., Lecture 3

HomeworkHomeworkHomeworkHomework

• Assess maturity of RE processes in your last-year SDS project

• Write an HTML document (Requirements Management Policy) describing the list of guidelines you are willing to follow this year

J. Nawrocki, Quality Manag., Lecture 3

Quality assessmentQuality assessmentQuality assessmentQuality assessment

1. What is your general impression? (1 - 6)

2. Was it too slow or too fast?

3. What important did you learn during the lecture?

4. What to improve and how?