requirements engineering: a good practice guide

© I. Sommerville 2000 Requirements Engineering SI-SE 2000 Slide 1

Requirements Engineering Requirements Engineering A Good Practice GuideA Good Practice Guide


The good practice guidebookThe good practice guidebookThe good practice guidebookThe good practice guidebook

Structure:• Contains a guide to the activities and

products of the requirements process.• Lists 66 guidelines to key good

practices.• Introduces the REAIMS

improvement model for requirements process improvement.

• Provides guidance on the assessment of RE process maturity.


REGPG guidelinesREGPG guidelinesREGPG guidelinesREGPG guidelines

Guidelines are provided for each activity/product area.• Requirements elicitation

• Requirements analysis and negotiation

• System modelling

• Requirement validation

• Requirement management

Guidelines are:• Basic: Fundamental measures needed for a repeatable process.

• Intermediate: Help make process more systematic, sometimes complex to implement.

• Advanced: Require specialist expertise, support on-going improvement.


The top ten good RE practicesThe top ten good RE practicesThe top ten good RE practicesThe top ten good RE practices

• Define a standard document structure.

• Make the document easy to change.

• Uniquely identify each requirement.

• Define policies for requirements management.

• Define standard templates for req. description.

• Use language simply, consistently and concisely.

• Organise formal requirements reviews.

• Define validation checklists.

• Use checklists for requirements analysis.

• Plan for conflicts and conflict resolution.


Basic good practicesBasic good practicesBasic good practicesBasic good practices

Assess system feasibility Be sensitive to organisational and political considerations Identify and consult system stakeholders Record requirements sources Define system’s operating environment Use business concerns to drive requirements elicitation


IntermediateIntermediate practicespracticesIntermediateIntermediate practicespractices

Look for domain constraints Record requirements rationale Collect requirements from multiple viewpoints Prototype poorly understood requirements Use scenarios to elicit requirements Define operational processes In general, you should not introduce intermediate

practices before a large number of basic practices are in normal use


AdvancedAdvanced practicespracticesAdvancedAdvanced practicespractices

Reuse requirements Assess requirements risks Specify systems using formal methods Collect incident experience Advanced practices should only be introduced after you

have reached the repeatable level in the process maturity model. If you introduce them earlier, then you may find them ineffective


RE - GPG GuidelinesRE - GPG GuidelinesRE - GPG GuidelinesRE - GPG Guidelines

Guidelines to the good practices are structured in a standard easy-to-understand way

Each description includes• A short discussion of the key benefits

• Practical advice on how to implement the practice

• An assessment of likely costs and problems of both introducing and using the practice


Example: Guideline 8.4Example: Guideline 8.4

Define validation checklists

General

You should define a checklist or checklists which helps focus the attention of requirements validators on critical attributes of the requirements document. These checklists should identify what readers should look for when they are validating the system requirements.

Key benefits: Help to focus the validation process

Costs of introduction: Low-moderate

Costs of application: Low

Guideline type: Basic

General

You should define a checklist or checklists which helps focus the attention of requirements validators on critical attributes of the requirements document. These checklists should identify what readers should look for when they are validating the system requirements.

Key benefits: Help to focus the validation process

Costs of introduction: Low-moderate

Costs of application: Low

Guideline type: Basic


Example: Guideline 8.4 Example: Guideline 8.4 (contd.)(contd.)

Benefits

Checklists add structure to the validation process. It is therefore less likely that readers will forget to check some aspects of the requirements document.

Checklists help in the introduction of people who are new to requirements validation. The checklist gives them hints what they should be looking for so that they feel more able to participate in the process. This is particularly important for customer management and end-users who may not have requirements validation experience.

Benefits

Checklists add structure to the validation process. It is therefore less likely that readers will forget to check some aspects of the requirements document.

Checklists help in the introduction of people who are new to requirements validation. The checklist gives them hints what they should be looking for so that they feel more able to participate in the process. This is particularly important for customer management and end-users who may not have requirements validation experience.



Implementation

The use of checklists for requirements analysis has already been discussed in Guideline 5.2, Use checklists for requirements analysis and similar checklists may also be used in the validation process. These checklists are oriented towards individual requirements; validation checklists should also be concerned with the quality properties of the requirements document as a whole and with the relationships between individual requirements. This can’t be checked during requirements analysis as the requirements document is unfinished at that stage.Questions which might be included in such a checklist should be based on the following general issues:

1. Are the requirements complete, that is, does the checker know of any missing requirements or is there any information missing from individual requirement descriptions?

….etc…...

Implementation

The use of checklists for requirements analysis has already been discussed in Guideline 5.2, Use checklists for requirements analysis and similar checklists may also be used in the validation process. These checklists are oriented towards individual requirements; validation checklists should also be concerned with the quality properties of the requirements document as a whole and with the relationships between individual requirements. This can’t be checked during requirements analysis as the requirements document is unfinished at that stage.Questions which might be included in such a checklist should be based on the following general issues:

1. Are the requirements complete, that is, does the checker know of any missing requirements or is there any information missing from individual requirement descriptions?

….etc…...



Costs and problems

This is not an expensive guideline to implement if you use a fairly general checklist with questions like those listed above. To introduce the guideline, you need to draw up an initial checklist based on the experience of people who have been involved in requirements validation.If a checklist is simply used a memory aid, there are no costs involved in applying the guideline. If checkers of the requirements must mark each requirement against the checklists, clearly some additional time is required. This should not be more than one or two minutes per requirement.In principle, there should be few problems in applying the guideline so long as you have a fairly flexible process which allows people to ignore inappropriate checklist entries. In practice, some requirements analysts may resent the introduction of checklists as they see them as de-skilling the process. You have to emphasise that the checklists are designed to help them and point out that professional judgement must still be used.

Costs and problems

This is not an expensive guideline to implement if you use a fairly general checklist with questions like those listed above. To introduce the guideline, you need to draw up an initial checklist based on the experience of people who have been involved in requirements validation.If a checklist is simply used a memory aid, there are no costs involved in applying the guideline. If checkers of the requirements must mark each requirement against the checklists, clearly some additional time is required. This should not be more than one or two minutes per requirement.In principle, there should be few problems in applying the guideline so long as you have a fairly flexible process which allows people to ignore inappropriate checklist entries. In practice, some requirements analysts may resent the introduction of checklists as they see them as de-skilling the process. You have to emphasise that the checklists are designed to help them and point out that professional judgement must still be used.


Process improvementProcess improvement

Stakeholderrequirements

Requirementsmanagement

ElicitationAnalysis andnegotiation

Validation

System requirementsTest plans

GoodPracticeGoodPractice


Applying the REGPG Applying the REGPG

Getting started• Ensure that the top 10 guidelines are in place

Assess the maturity of the current processes Plan incremental RE process improvements Introduce new practices Check success of improvements against your improvement

goals Introduce the next stage of improvements


Planning and implementing improvementsPlanning and implementing improvementsPlanning and implementing improvementsPlanning and implementing improvements

The essence of the REAIMS approach to improvement• Goal-driven

• Incremental

• Recognises the importance of controlling risks and costs

There are four questions to ask when planning improvement:• What are your most pressing problems?

• What are your improvement goals?

• How can improvements be matched to the goals?

• How should improvements be managed?


What are the most pressing problems?What are the most pressing problems?

Incremental improvement should be problem-driven. Start by identifying and addressing your most urgent

problems: Possible problems might be:

• poor product quality

• loss of change control

• cost and delivery over-runs

• staff morale

• low productivity

• lack of process visibility


What are the improvement goals?What are the improvement goals?

Decide what you want to achieve from the improvement process. • If you don’t know where you are going, you won’t be able to

tell if you’ve arrived

Improvement goals should normally be related to the identified problems

Goals must be realistic - unrealistic goals lead to disappointments, disillusion and cancellation.

May be expressed in a qualitative or in a quantitative way


Match improvements to goalsMatch improvements to goals

Use the advice in the good practice guide to identify the practices that are most likely to help you achieve your goals

Relate the improvement goals to specific RE process activities or to deliverables from the RE process

If the symptoms of your problems are hard to tie back to one of the activities/products of the RE process then STOP!.

You need more information about your problems at this stage


Manage the introduction of improvements Manage the introduction of improvements

You have to assess your improvements against your goals.

You should collect feedback from the improvements• Quantitative information about the process such as the number

of change requests, the time required to approve new requirements etc.

• Qualitative information from practitioners. What do people think?

Feedback must be acted upon. If the practices don’t appear to be making a difference then don’t hesitate to re-iterate and to try something else.


Advice on introducing improvementsAdvice on introducing improvements

Find an evangelist• An evangelist is someone who believes in the improvement and

will work to convince others. If you have an evangelist, this is a good reason to select one improvement over another

Try changes out on pilot projects• There will be problems! Pilot projects let you find these

problems without affecting too many people

Allow enough time to make the change• Improvements to professional processes take time

Respect professional skills• The people in the processes are the experts. Listen to them


SummarySummary

The RE- GPG is intended to help organisations improve their requirements engineering processes

Extends the principles of top-down software process improvement to requirements engineering

Provides 66 good practices with advice on benefits, costs, etc.

Focuses on pragmatic advice that is adaptable to individual organisations’ needs

requirements engineering: a good practice guide

Business