All Resources

Book : Requirements Engineering - A Good Practice Guide (1997)

Requirements Engineering - A Good Practice Guide

Publisher:John Wiley & Sons

Author(s):Sawyer, PeteSomerville, Ian

Published: 1997 • ISBN: 0471974447 • 404 pages • Delivery Format: Hard Copy - Paperback

Available from: Amazon (DE)Amazon (UK)Amazon (US)

Summary

From the publisher:

Requirements engineering is the process of discovering, documenting and managing the requirements for a computer-based system. The goal of requirements engineering is to produce a set of system requirements which, as far as possible, is complete, consistent, relevant and reflects what the customer actually wants. Although this ideal is probably unattainable, the use of a systematic approach based on engineering principles leads to better requirements than the informal approach which is still commonly used.

This book presents a set of guidelines which reflect the best practice in requirements engineering. Based on the authors’ experience in research and in software and systems development, these guidelines explain in an easy-to-understand way how you can improve your requirements engineering processes.

The guidelines are applicable for any type of application and, in general, apply to both systems and software engineering. The guidelines here range from simple ‘common sense’ to those which propose the introduction of complex new methods. The guidelines and process improvement schemes have been organised so that you can pick and choose according to your problems, goals and available budget. There are few dependencies between guidelines so you can introduce them in any order in your organisation.

Guidelines presented in the book

  • are consistent with ISO 9000 and CMM
  • are ranked with cost/benefit analysis
  • give implementation advice
  • can be combined and applied to suit your organisation’s needs
  • are supported by a web page pointing to RE tools and resources

Content / Structure

Preface

  • Further Information
  • The REAIMS Project
  • Acknowledgements

1. Introduction

  • 1.1 How Will This Book Help Me?
  • 1.2 What Are Requirements?
  • 1.3 What is Requirements Engineering?
  • 1.4 What is a Requirements Document?
  • 1.5 What is the Best Way to Write Requirements?
  • 1.6 How Detailed Should Requirements Be?
  • 1.7 What is the Difference Between Functional and Non-Functional Requirements?
  • 1.8 What are System Stakeholders?
  • 1.9 Does System Size Make a Difference?
  • 1.10 What is a Requirements Engineering Process?
  • 1.11 How do I Recognise Requirements Engineering Process Problems?
  • 1.12 Can You Suggest a Good Requirements Engineering Process?
  • 1.13 Where Does ISO 9000 Fit In?
  • 1.14 Where Can I Find Out More About Requirements Engineering?

2. Practical Process Improvement

  • 2.1 Process Maturity
  • 2.2 Process Assessment
  • 2.3 Process Improvement
  • 2.4 Top Ten Guidelines
  • 2.5 Guideline Lists

3. The Requirements Document

  • 3.1 Define a Standard Document Structure
  • 3.2 How to Use the Document
  • 3.3 Include a Summary of the Requirements
  • 3.4 Make a Business Case for the System
  • 3.5 Define Specialised Terms
  • 3.7 Lay Out the Document for Readability
  • 3.8 Make the Document Easy to Change

4. Requirements Elicitation

  • 4.1 Assess System Feasibility
  • 4.2 Be Sensitive to Organisational and Political Considerations
  • 4.3 Identify and Consult System Stakeholders
  • 4.4 Record Requirements Sources
  • 4.5 Define the System's Operating Environment
  • 4.6 Use Business Concerns to Drive Requirements Elicitation
  • 4.7 Look for Domain Constraints
  • 4.8 Record Requirements Rationale
  • 4.9 Cllect Requirements From Multiple Viewpoints
  • 4.10 Prorotype Poorly Understood Requirements
  • 4.11 Use Scenarios to Elicit Requirements
  • 4.12 Define Operational Process
  • 4.13 Reuse Requirements

5. Requirements Analysis and Negotiation

  • 5.1 Define System Boundaries
  • 5.2 Use Checklists for Requirements Analysis
  • 5.3 Provide Software to Support Negotiations
  • 5.4 Plan for Conflicts and Conflict Negotiation
  • 5.5 Prioritise Requirements
  • 5.6 Classify Requirements Using a Multi-dimensional Approach
  • 5.7 Use Interaction Matrices to Find Conflicts and Overlaps
  • 5.8 Assess Requirements Risks

6. Describing Requirements

  • 6.1 Define Standard Templates
  • 6.2 Use Language, Simply, Consistently and Concisely
  • 6.3 Supplement Natural Language with Other Descriptions of Requirements
  • 6.4 Specifiy Requirements Quantitatively

7. System Modelling

  • 7.1 Develop Complimentary System Models
  • 7.2 Model the Systems's Environment
  • 7.3 Model the System Archtecture
  • 7.4 Use Structured Methods for System Modelling
  • 7.5 Use a Data Dictionary
  • 7.6 Document the Links Between Stakeholder Requirements and System Models

8. Requirements Validation

  • 8.1 Check that the Requirements Document Meets Your Standards
  • 8.2 Organise Formal Requirements Inspections
  • 8.3 Use Multi-Disciplinary Teams to Review Requirements
  • 8.4 Define Validation Checklists
  • 8.5 Use Prototyping to Animate Requirements
  • 8.6 Write a Draft User Manual
  • 8.7 Propose Requirements Test Cases
  • 8.8 Paraphrase System Models

9. Requirements Management

  • 9.1 Uniquely Define Each Requirement
  • 9.2 Define Policies for Requirements Management
  • 9.3 Define Traceability Policies
  • 9.4 Maintain a Traceability Model
  • 9.5 Use a Database to Manage Requirements
  • 9.6 Define Change Management Policies
  • 9.7 Identify Global System Requirements
  • 9.8 Identify Volatile Requirements
  • 9.9 Record Rejected Requirements

10. Requirements Engineering for Critical Systems

  • 10.1 Create Safety Requirement Checklists
  • 10.2 Involve External Reviewers in the Validation Process
  • 10.3 Identify and Analyse Hazards
  • 10.4 Derive Safety Requirements from Hazard Analysis
  • 10.5 Cross-check Operational and Functional Requirements Against Safety Requirements
  • 10.6 Specify Systems Using Formal Specifications
  • 10.7 Collect Incident Experience
  • 10.8 Learn from Incident Experience
  • 10.9 Establish an Organisational Safety Culture

11. System Modelling with Structured Methods

  • 11.1 Background and Motivations
  • 11.2 Choosing Models and Methods
  • 11.3 Models
  • 11.4 Methods
  • 11.5 Further Information

12. Formal Specification

  • 12.1 Why Formalise?
  • 12.2 Definitions and Life-Cycle Issues
  • 12.3 Formal Specification Issues
  • 12.4 Motivations and Potential Benefits
  • 12.5 Problems, Pitfalls and L:essons Learned
  • 12.6 Costs
  • 12.7 Reasoning About a Specification
  • 12.8 Further Reading

13. Viewpoints

  • 13.1 Why Viewpoints?
  • 13.2 PREview: A Pragmatic Viewpoints Approach
  • 13.3 Further Reading

Index

Copyright 1997 by John Wiley & Sons Ltd.

Reviews

Be the first to review this book - Requirements Engineering - A Good Practice Guide

Elsewhere On The Internet






Return to Previous Page

Chosen at random from all the resources listed:

All articles/posts © of the respective authors

Site design and architecture © 2010 - 2011 Eclectica Systems Ltd.