Good Practices of Requirements Eng. Copyright, 2000 © Jerzy R. Nawrocki...

transcript

Good Practices of Requirements Eng.Good Practices of Requirements Eng.

Copyright, 2000 © Jerzy R. Nawrocki

Jerzy.Nawrocki@put.poznan.pl

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

Requirements Engineering Requirements Engineering

Lecture 1Lecture 100

Requirements Engineering Requirements Engineering

Lecture 1Lecture 100

J. Nawrocki, Requirements Eng., 10

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

IntroductionBasic guidelinesIntermediate guidelinesAdvanced guidelines

Overview of RE guidelinesOverview of RE guidelinesOverview of RE guidelinesOverview of RE guidelines

The requirements document

Requirements elicitation

Reqs analysis & negotiation

Describing requirements

System modelling

Requirements validation

Requirements management

RE for critical systems

Basic Interm Adv

ScoringScoringScoringScoring

3 - standardised: documented standard followed and checked as part of the quality management process;

2 - normal use: widely followed but not mandatory;

1 - discretionary use: used at discretion of project manager;

0 - never: never or very rarely used;

Maturity levels for REMaturity levels for REMaturity levels for REMaturity levels for RE

Defined

> 85 Basic & > 40 Interm & Adv

Defined

> 85 Basic & > 40 Interm & AdvRepeatable

> 55 Basic & < 40 Interm & Adv

Repeatable

> 55 Basic & < 40 Interm & AdvInitial

< 55 Basic

Initial

< 55 Basic

Legend for RE quidelinesLegend for RE quidelinesLegend for RE quidelinesLegend for RE quidelines

• Responsibility of Project Managers• Responsibility of SDS Senior Responsibility of SDS Senior

Managers or Quality AssurersManagers or Quality Assurers• At a discretion of Project

Managers

Introduction

Basic guidelinesIntermediate guidelinesAdvanced guidelines

Basic guidelinesBasic guidelinesBasic guidelinesBasic guidelines

Requirements document

• Define a standard document structureDefine a standard document structure• Explain how to use the document• Include a summary of the requirements

(purpose of the system, main actors, titles of main use cases)

• Make a business case for the system (usage scenarios: problem descriptions & improvement proposals)

Requirements document

• Define specialised terms (glossary)• Lay out the document for readability• Help readers find information (?)• Make the document easy to change

• Assess system feasibility• Be sensitive to organisational &

political considerations• Identify and consult stakeholders• Record requirement sources• Define operating environment• Use business concerns to drive

requirements elicitation (planning game)

Give me a crocodile!

Analysis and negotiation

• Define system boundaries (use case diagrams; interaction diagrams)

• Use checklists for requirements analysisUse checklists for requirements analysis (reading scenarios?)

• Provide software to support negotiationsProvide software to support negotiations (e-mail, ClearQuest)

• Plan for conflicts and conflict resolution (FAST & inspections)

• Prioritise requirements (planning game)

• Define standard templates for Define standard templates for describing requirementsdescribing requirements

• Use language simply & concisely• Use diagrams appropriately• Supplement natural language with

other descriptions of requirements (UML diagrams)

System modelling

• Develop complementary system models (UML diagrams)

• Model the system’s environment• Model the system architecture

(deployment diagrams)

• Check that the requirements Check that the requirements document meets your standarddocument meets your standard

• Organise formal requirements Organise formal requirements inspectionsinspections

• Use multidisciplinary teams to Use multidisciplinary teams to review requirementsreview requirements

• Define validation checklistsDefine validation checklists

• Uniquely identify each requirement

• Define policies for requirements Define policies for requirements managementmanagement

• Define traceability policiesDefine traceability policies• Maintain a traceability manual

(RequisitePro)

• Create safety requirements Create safety requirements checklistschecklists

• Involve external reviewers in the Involve external reviewers in the validation processvalidation process

IntroductionBasic guidelines

Intermediate guidelinesAdvanced guidelines

Intermediate guidelinesIntermediate guidelinesIntermediate guidelinesIntermediate guidelines

• Record requirements rationale• Use scenarios

• Classify requirements using using a multidimensional approach

• Use interaction matrices to find conflicts and overlaps

• Specify requirements quantitatively

System modelling

• Use structured methods for system modelling

• Use a data dictionary• Document the links between

stakeholder requirements and system models

• Use prototyping to animate requirements

• Write a draft user manual• Propose requirements test

• Use a database to manage requirements (RequisitePro)

• Define change management policies (ClearCase LT, ClearQuest)

• Identify global system requirements

• Identify and analyse hazards• Derive safety requirements from

hazard analysis• Cross-check operational and

functional requirements against safety requirements

IntroductionBasic guidelinesIntermediate guidelines

Advanced guidelines

Advanced guidelinesAdvanced guidelinesAdvanced guidelinesAdvanced guidelines

• Reuse requirements

• Assess requirements risks (exploration & planning game)

• Paraphrase system models

• Identify volatile requirements• Record rejected requirements

• Specify systems using formal specification

• Collect incident experience• Learn from incident experience• Establish an organisational

safety culture

Further readingsFurther readingsFurther readingsFurther readings

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

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?

Good Practices of Requirements Eng. Copyright, 2000 © Jerzy R. Nawrocki...

Documents