Writing Better Requirements
Writing Better Requirements
Häftad, Engelska, 2002
919 kr
Well-written requirements are crucial to systems of all kinds: you are unlikely to get what you want unless you ask for it. This book explains and demonstrates exactly what requirements are for, and how to write them
Produktinformation
- Utgivningsdatum2002-07-24
- Mått195 x 235 x 10 mm
- Vikt284 g
- FormatHäftad
- SpråkEngelska
- Antal sidor176
- Upplaga1
- FörlagPearson Education
- ISBN9780321131638
Tillhör följande kategorier
Ian Alexander is an independent consultant specialising in Requirements Engineering. He has written several training courses on systems and requirements engineering. He has led hundreds of training courses on systems engineering, requirements, DOORS, and DXL, and has run numerous practical workshops on scenarios, trade-offs and requirements. He was co-author of an Addison-Wesley book on HTML 3 and its 2nd Edition on HTML 4. He is the author of the Scenario Plus for Use Cases toolkit, and is a well-known speaker and writer on scenario usage. He is currently on a technology project to investigate the reuse of specifications for control systems in the German automobile industry. He helps to run the BCS Requirements Engineering Specialist Group and the IEE Professional Network for Systems Engineering. He is a Chartered Engineer. Richard Stevens is the founder of QSS, the firm that launched the pioneering Requirements Management tool DOORS, the world's most popular requirements tool. He is the co-author of books on "Systems Engineering", "Software Engineering Standards", "Software Engineering Guidelines" and "Understanding Computers". In 1998, Richard was appointed as the first European Fellow of INCOSE, the International Council on Systems Engineering.
- Table of Contents 1. Introduction 91.1 Why do requirements matter? 91.2 Who are requirements for? 121.3 Different names for requirements 131.4 Different types of specification 141.5 The challenge of writing better requirements 151.6 The requirements writing process 182. Identifying the stakeholders 212.1 Different types of stakeholder 212.2 Your house extension: a simple case? 222.3 A practical approach to identifying stakeholders 23Exercise 1: Listing the stakeholders 233. Gathering requirements from stakeholders 263.1 Possible techniques 26Exercise 2: Asking 'why?' 283.2 Interviews 283.3 Workshops 323.4 Experiencing life as a user 363.5 Observing users at work 363.6 Acting out what needs to happen 363.7 Prototypes 384. Other sources of requirements 404.1 Possible sources 40Exercise 3: Extracting requirements from source documents 44Exercise 4: Extracting requirements from a memo 454.2 Getting requirements for mass-market products 454.3 User requirements in subsystem projects 465. Structuring the requirements 475.1 You need structure as well as text 475.2 Breaking the problem down into steps 485.3 Organizing requirements into scenarios 505.4 Examples of goal decomposition 52Exercise 5: A structure for user requirements 535.5 Handling exceptions 53Exercise 6: Could anything go wrong here? 54Exercise 7: Exceptions 555.6 Examples and exercises in requirement structure 57Exercise 8: Creating a heading structure 57Exercise 9: The right document for each subject 57Exercise 10: Wrongly placed requirements 586. Requirements in context 596.1 The user requirements document 596.2 Organizing the constraints 60Exercise 11: Writing constraints 646.3 Defining the scope 64Exercise 12: Restricting the scope 656.4 Requirement attributes 656.5 Keeping track of the requirements 677. Requirements writing 707.1 Quality, not perfection 707.2 Sketch, then improve 707.3 Anatomy of a good requirement 707.4 Guidelines for good requirements 717.5 Don't write like this 72Exercise 13: Good requirements 75Exercise 14: Writing requirements for familiar domestic systems 75Exercise 15: Ambiguous requirements 768. Checking and reviewing 788.1 Checking the document structure with users 788.2 Checking the requirements 80Exercise 16: Checking individual requirements 81Exercise 17: Checking a set of requirements 828.3 Reviewing 838.4 Success - the reviewed document 85Exercise 18: Reviewing 85A: Answers to exercises 87Exercise 1: Listing the stakeholders 87Exercise 2: Asking 'why?' 87Exercise 3: Extracting requirements from source documents 87Exercise 4: Extracting requirements from a memo 88Exercise 5: A structure for user requirements 88Exercise 6: Could anything go wrong here? 89Exercise 7: Exceptions 89Exercise 8: Creating a heading structure 90Exercise 9: The right document for each subject 90Exercise 10: Wrongly placed requirements 90Exercise 11: Writing constraints 91Exercise 12: Restricting the scope 92Exercise 13: Good requirements 92Exercise 14: Writing requirements for familiar domestic systems 93Exercise 15: Ambiguous requirements 93Exercise 16: Checking individual re