ebook img

User-Centred Requirements Engineering PDF

223 Pages·2002·8.32 MB·English
Save to my drive
Quick download
Download
Most books are stored in the elastic cloud where traffic is expensive. For this reason, we have a limit on daily download.

Preview User-Centred Requirements Engineering

User-Centred Requirements Engineering Springer-Verlag London Ltd. Alistair Sutcliffe User-Centred Requirements Engineering Springer Alistair Sutcliffe, MA, PhD Centre for HCI Design, Department of Computation, UMIST, PO Box 88, Manchester M60 1Q D, UK British Library Cataloguing in Publication Data Sutcliffe,Alistair,1951- User-centred requirements engineering 1. Software engineering 2. Systems engineering 3. Human engineering 1. Title 005.1'2 ISBN 978-1-85233-517-5 ISBN 978-1-4471-0217-5 (eBook) DOI 10.1007/978-1-4471-0217-5 Library of Congress Cataloging-in-Publication Data A catalog record for this book is available from the Library of Congress. Apart from any fair dealing for the purposes of research or private study,or criticism or review, as permitted under the Copyright, Designs and Patents Act 1988, this publication may only be reproduced, stored or transmitted, in any form or by any means, with the prior permission in writing of the publishers, or in the case of reprographie reproduction in accordance with the terms of licences issued by the Copyright Lieensing Agency. Enquiries concerning reproduction outside those terms should be sent to the publishers. ISBN 978-1-85233-517-5 http://www.springer.co.uk © Springer-Verlag London Limited 2002 First published 2002 The use of registered names, trademarks etc. in this publication does not imply, even in the absence of a specific statement, that such names are exempt from the relevant laws and regula tions and therefore free for general use. The publisher makes no representation, express or implied, with regard to the accuracy of the information contained in this book and cannot accept any legal responsibility or liability for any errors or omissions that may be made. Typesetting: Gray Publishing, Tunbridge WeHs, Kent Printed and bound at the Athenreum Press Ltd., Gateshead, Tyne and Wear 34/3830-543210 SPIN 10839647 Preface If you have picked up this book and are browsing the Preface, you may well be asking yourself"What makes this book different from the large number I can find on amazon. com?". Well, the answer is a blend of the academic and the practical, and views of the subject you won't get from anybody else: how psychology and linguistics influence the field of requirements engineering (RE). The title might seem to be a bit of a conundrum; after all, surely requirements come from people so all requirements should be user-centred. Sadly, that is not always so; many system disasters have been caused simply because requirements engineering was not user-centred or, worse still, was not practised at all. So this book is about putting the people back into com puting, although not simply from the HCI (human-computer interaction) sense; instead, the focus is on how to understand what people want and then build appropriate computer systems. The book is based on my own research in the area over a number of years in several projects: basic research projects funded by the European Union (EU) - NATURE (Novel Approaches To Requirements Engineering) and CREWS (Cooperative Requirements Engineering With Scenarios) - and applying that research in EU-funded ESPRIT projects - Intuitive (database front ends) and MultimediaBroker (web-based broker services). Other research contributions come from projects funded by the Engineering and Physical Sciences Research Council - DATUM (safety critical systems), CORK (socio-technical requirements analysis), ISRE (requirements analysis using virtual reality prototypes) and SIMP (requirements analysis and per formance assessment in complex large-scale systems). Besides my academic life in the field, I can lay some claim to have worked at the coal-face. Before starting my academic career I acted as my own requirements analyst in sys tems I developed during my PhD, and in industry as an analyst programmer; I then became what was in those days the precursor of the requirements engineer: the systems analyst. I experienced requirements creep, communi cation problems, irreconcilable stakeholder viewpoints, and all the other hassles that reside in RE. Of course, I still practise RE in my university domain: I have to figure out students' and employers' requirements for the courses I teach, requirements for good research projects, and indeed infer to the best of my ability your requirements for this book. Not surprisingly, I am both an academic interested in the theory of requirements and a practitioner aiming to improve what I do. v I find it helps to explain the title of my books in a preface, usually because the title reflects my motivation in writing the book, and partly to open a dia logue with the reader to explain the contents. The world is not short of books on RE, so I must confess to a slightly selfish motivation for writing yet another one. This book is primarily a review of my research in RE over the last 15 years. It also, I hope, provides a review of research by others in the area, although I should note that it was not my prime intention to review the field comprehensively. The title User-Centred Requirements Engineering reflects my background and research interests in the people side of require ments. Requirements engineering, I contend, should be a deeply people-cen tric process. Requirements, after all, originate with people, and the process of discovering them involves conversations between people; how we record and understand them involves the psychology of comprehension, and require ments for computer systems are only a small part of designing complex sys tems that involve people. A sub-text for the book is the tension between theory and practice. In spite of RE's practical orientation, I argue that it does have a theoretical back ground and is beginning to make some theoretical contributions in its own right. The background theory comes from psychology and sociology. I cover the former in reasonable depth and give sociology some attention, but not as much as I would have liked - this will have to wait for a longer tome. I justify including psychology because RE is quintessentially about human problems of communication and understanding. Explaining how we reason and com prehend the world, as well as communicate with each other should, I hope, make for better mutual awareness when requirements engineers meet users in the miasma of uncertainty; it may lead researchers and practitioners to develop better methods and tools. RE as a field of endeavour has emerged from computer science; however, similar concerns are present in many areas of design. Within computer science, researchers in human computer interac tion, information systems, and knowledge engineering wrestle with similar issues. Accordingly, I have tried to weave their contributions into the picture where I can. To give you a reading guide of how the book is structured and my inten tions in each chapter, let us start predictably at the beginning. Chapter 1 introduces the field and describes a framework for RE research and practice to date. Chapter 2 explains the psychological background behind RE prob lems and acts as a simple tutorial for perceptual and cognitive issues that are relevant to RE in memory, problem solving, communication, and human error. My intention in this chapter is to provide some understanding about why RE is difficult and how human misunderstanding can cause the prob lems we observe in getting requirements right. Any psychologists amongst you can give this chapter a miss, unless you want to look at the implications for requirements. Chapter 3 is an expanded version of a framework/survey paper I published some time ago in the Requirements Engineering journal. It takes the reader through the activities (or tasks) in RE, pointing out tech niques, guidelines and research findings. This chapter also investigates how RE activity is influenced by the domain and is a starting point for develop ments such as product procurement, requirements for legacy systems, and so on. The final part of the chapter examines how reuse and different types of product influence the process. Chapter 3 is thus both a review and a frame work with some embedded practical advice. Chapter 4 covers one of the key problems in RE: how we communicate. This chapter is partly background information on psycholinguistics, but to save you from the unleavened bread of discourse theory I have included practical advice based on my research into patterns of conversation in requirements meetings. Hence the chapter gives some theory to explain how we manage to misunderstand one another, and practical patterns or tem plates for managing the human communication in requirements analysis. Chapter 5 continues the communication thread by investigating how we rep resent requirements during meetings. It consists of a review of research and a framework for thinking about representations, with practical advice on selecting the optimal set of presentations for a particular RE setting. The chapter deals with the familiar forms of requirements - lists and diagrams - but then considers how multimedia should fit into the process. This develops into more practical advice on choosing representations for the major activi ties in the RE process. The final part of the chapter deals with devices and technologies that we use for communication, and how computers can help group working and collaboration in requirements analysis. Chapter 6 shifts gear wholly into the practical domain. A practical method that I have researched, taught, applied in industry and published is described. As the title indicates, it is a scenario-based approach that synthe sizes much of the advice given in previous chapters into a step-by-step method. The method falls within the prototyping, requirements-by-work ing-with-examples tradition, so it may not fit all applications; however, it has proven its worth in several projects. Chapter 7 addresses a special concern of safety critical requirements analysis based on research I have published over a number of years. Again, a scenario-based approach is taken but this chap ter also describes tools for analyzing requirements to defend against possible human error and other failures that may arise in safety critical systems. The final chapter does the futurology bit for RE and investigates how reuse and application generator technologies may improve RE. I return to the commu nication question and examine the prospects for the holy grail of RE: a natu ral language-understanding machine that automatically creates designs from our wishes. This may be fantasy, or a prospect worth more research. The chapter ends with reflections on how RE fits within other engineering and design disciplines, and how evolutionary computing might influence the future. In any book it is a pleasure to acknowledge the help and stimulus over the years of one's colleagues, whose contributions appear in some form on the pages. I will also record the traditional caveat that should I have misrepre sented their views the fault is mine. Colleagues include many on the EU basic research projects NATURE and later CREWS, notably Matthias Jarke who was always a fount of new ideas; Collette Rolland whose conceptual model ling and ideas on RE processes found their way into Chapters 3 and 4; Janis Bubenko who influenced my goal-modelling research; Klaus Pohl whose work on standard, multimedia representations and the requirements dimen sion have found their way into several chapters; and Neil Maiden who collab orated on the scenario-based methods and tools that appear in Chapters 6 and 7. John Mylopoulos and Eric Yu's work on conceptual modelling and their i* language appears in several places and their approach has led to many useful directions in my own work. Colin Potts started the scenario based approach with his obstacles work and later SCENIC method that stim ulated many ideas in SCRAM, while Jack Carroll's work on scenario-based design and my collaboration with him on claims appear in Chapters 5 and 6. It is also a pleasure to acknowledge the influence of some of my more formal colleagues (formal in the methods sense, not in demeanour): Michael Jack son whose research on the dependencies between the real world and the design machine has initiated a potential theory of RE; and Chris Johnson who has worked on safety critical systems and the intersection of formal and informal methods. A substantial part of this book was written while I was on sabbatical at the University of Oregon, so my thanks go to Steve Fickas for many conversa tions about RE issues, systems architectures and requirements languages, and for his patience in answering other topics I pestered him with. I should also like to thank colleagues in UMIST, and Nick Gold in particular for com ments on the whole text; and colleagues in the ISRE conferences and IFIP working group 2.9 whom I have not mentioned above. Finally, my thanks to my personal editor-in-chief, Gillian Martin, whose patience, attention to detail and copious unpaid assistance made writing this book a feasible task. In conclusion, I hope you find this book interesting and useful. If having read this far you have decided you really want a more practically oriented tome, I can recommend an excellent book by Robertson and Robertson (1999) on their Volere method; the classic on requirements elicitation by Gause and Weinberg (1989) is still worth every penny; while more solid sur vey treatment can be found in Ian Somerville's books with Gerald Kotonya (1998) for a practical orientation, and with Peter Sawyer (1997) for a more academic view. For the more formal modellers among you, Michael Jackson's books (1983, 1995) are always stimulating. If, however, you are looking for a different perspective and I have aroused your interest in matters psychologi cal, then read on. Alistair Sutcliffe UMIST, November 2001 Contents 1 Introduction .•.....•...•...•....•..•........ 1 1.1 Motivation for Requirements Engineering . . . . . . . . . . . . .. 1 1.2 A Little History ............ . . . . . . . . . . . . . . . .. 5 1.3 People, Communication and Requirements ............. 6 1.4 A Framework for RE .......................... 7 1.5 Requirements Types and RE Pathways ............... 11 1.6 Constraints on Design ........................ 13 1.7 Documenting Requirements .. . . . . . . . . . . . . . . . . . .. 15 1.8 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 18 2 Understanding People ......•......•.....•...... 19 2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 19 2.2 Cognitive Models ........................... 19 2.3 Speech and Language . . . . . . . . . . . . . . . . . . . . . . . .. 21 2.4 Memory ................................ 21 2.4.1 Working Memory . . . . . . . . . . . . . . . . . . . . . . . .. 21 2.4.2 Long-term Memory ....................... 22 2.5 Thinking and Problem Solving ................... 27 2.5.1 Mental Models .......................... 29 2.5.2 Levels of Reasoning . . . . . . . . . . . . . . . . . . . . . . .. 30 2.6 Attention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 31 2.7 Motivation and Arousal . . . . . . . . . . . . . . . . . . . . . . ., 32 2.7.1 Motivation ............................ 32 2.7.2 Arousal .............................. 33 2.8 Stress and Fatigue . . . . . . . . . . . . . . . . . . . . . . . . . .. 34 2.9 Human Error ............................. 35 2.10 Social Issues ............................. 38 2.10.1 Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 38 2.10.2 Trust ............................... 40 2.11 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 42 3 RE Tasks and Processes . . • . . . . • . . • . . . . . . . • . . . . • •• 45 3.1 Requirements Elicitation . . . . . . . . . . . . . . . . . . . . . .. 45 ix 3.1.1 Scoping . . . 47 3.2 Analysis ..... 48 3.2.1 Goal Analysis 48 3.2.2 Event Analysis 50 3.2.3 Analysis Techniques 51 3.3 Modelling . 51 3.4 Validation . . . . . . . . 54 3.5 Negotiation ....... 55 3.5.1 Managing Negotiation 57 3.6 Functional Allocation .. 59 3.7 Processes for Discovering and Refining Requirements 61 3.7.1 Policy-Driven Requirements ... 61 3.7.2 Problem-Initiated Requirements . . . . . . . . . . 63 3.7.3 Requirements-by-Example ............. 64 3.7.4 Requirements Imposed by the External Environment 67 3.8 RE for Different Target Products ..... 68 3.8.1 The Market Dimension ....... 69 3.8.2 The Specific to Generic Dimension 72 3.8.3 The Service Dimension 75 3.9 Summary ................. 77 4 Understanding Requirements Conversations ............. 79 4.1 Introduction to Discourse Theory 79 4.2 Conversations and Context . 82 4.3 Conversation Structures . . . 84 4.4 Non-Verbal Communication 86 4.5 Dialogue Acts and Patterns . 87 4.5.1 Requirements Elicitation. . . . . . . . . .. 88 4.5.2 Analysis and Modelling Dialogues 96 4.5.3 Refining Requirements 98 4.5.4 Validation Dialogues ... . . . . . . 98 4.5.5 Negotiation Dialogues 100 4.6 Summary ............................. " 102 5 Representing the Problem ...•................... 103 5.1 Representation Criteria . . . . . . . . . . . . . . . 103 5.2 Representations and Information Requirements 106 5.3 Media and Representation ............ 109 5.4 Choosing Representations for RE Tasks . . . . . 113 5.4.1 Requirements Acquisition and Fact Capture 113 5.4.2 Analysis and Modelling 114 5.4.3 Validation . . . . . . . . . . . . . . . 116 5.4.4 Negotiation .............. 117 5.5 Delivering Representations on Artefacts 118 5.6 Representational Paradigms ....... 119

Description:
If you have picked up this book and are browsing the Preface, you may well be asking yourself"What makes this book different from the large number I can find on amazon. com?". Well, the answer is a blend of the academic and the practical, and views of the subject you won't get from anybody else: how
See more

The list of books you might like

Most books are stored in the elastic cloud where traffic is expensive. For this reason, we have a limit on daily download.