Requirements Patterns and Antipatterns: Best (and Worst) Practices for Defining Your Requirements |
|
|
|
|
| Martin L. Shoemaker |
| January 2007, Addison-Wesley Professional, Paperback, 352 pages, ISBN 0321330617
|
|
|
|
 |
|
The Tablet Unified Modeling Language (UML) Company announces the Summer 2005 release of Requirements Patterns and Antipatterns: Best (and Worst) Practices for Defining Your Requirements from Addison Wesley.
Some software projects use .NET, while others use J2EE. Some projects use C++, some C#, some VB.NET, and some Java. Some projects use Unified Modeling Language (UML) and modeling, but many don’t. Some projects use large orchestrated processes like the Unified Process, but some use agile processes like Extreme Programming, and some projects use no formal process at all.
But all projects have requirements. No matter the environment or the language or the process, all projects have requirements: goals that the end users need to accomplish and tasks they need to do in order to satisfy those goals. And another thing is true of all projects: failures in requirements analysis cause more bugs, more confusion, and more failed projects than any other factor.
Thus begins Requirements Patterns and Antipatterns, the new book from Martin L. Shoemaker, author of Tablet Unified Modeling Language (UML). In this book, Martin returns to his main theme from Unified Modeling Language (UML) Applied: A .NET Perspective: that software development is largely a communications effort, and that improving communications is one of the most effective ways to improve your development process. In particular, he looks at requirements elicitation and analysis, ways to ask questions and understand the answers. Using the popular patterns format, he describes 51 best practices for requirements analysis, as well as 18 worst practices: antipatterns that represent common mistakes people make as they try to understand customer needs.
While this book is written primarily from the perspective of a programmer who has to also work as an analyst and wants to learn requirements analysis techniques, it's also aimed at other participants in the requirements process, including full-time analysts, designers, architects, managers, testers, and technical writers. It even looks at ways that customers and end users can become more active and effective at communicating their requirements to development teams.
|
 |
|
| Here's a preview of the patterns and antipatterns in the book:
Part I. Setting the Stage
Chapter 1. Requirements: The Root of All Evil
Chapter 2. Patterns and Antipatterns, Defined and Described
Chapter 3. The Hard Part: Recognizing the Patterns
Part II. Elicitation: Asking the Questions
Chapter 4. Elicitation I: Basic Communication Patterns
1. What Are You Really Selling?
2. The Written Word
3. The Outline Effect
4. The Echo Effect
5. The No-Lose Scenario
Chapter 5. Elicitation II: Participant Patterns
6. Trained Analysts
7. Stakeholders
8. Domain Experts
9. The Mission Control Team
Chapter 6. Elicitation III: Conversation Patterns
10. Brainstorming
11. Interviews
12. Focus Group
13. The Scoop Patterns
14. Parking Lots
15. Surveys
16. On-site Customer
Chapter 7. Elicitation IV: Supplemental Elicitation Patterns
17. Read the Journals
18. Those Who Teach, Can
19. Requirements Archaeology
20. Manual Development
21. Prototyping
22. The Complaint Department
23. Bird Watching
24. Mixing It Up
Chapter 8. Elicitation Antipatterns
25. Process Over Progress
26. Obsessive Compulsive Template Disorder
27. The Department of Obfuscatory Verbiage
28. All You Have is a Hammer
29. No, No, No! This is What You Want!
30. I Already Told You What to Do
31. Single Point of Contact
32. Telephones: The Worst of Both Worlds
33. Big-Picture Users/Little-Picture Users
34. User Proxies
35. Cool Features
36. That’s Design, Not Analysis
Part III. Analysis: Answering the Questions
Chapter 9. Analysis I: Informational Patterns
37. Fundamentals
38. Actors
39. Use Cases
40. Scenarios
41. Domain Objects
42. Events, States, and Responses
43. The Numbers Game
44. Testability
Chapter 10. Analysis Patterns II: Organizational Patterns
45. Categorization
46. Modeling
47. Domain Glossary
48. Actor Hierarchy
49. Use Case Hierarchy
50. Domain Object Hierarchy
51. The Software Requirements Specification
52. Trace Matrix
Chapter 11. Analysis Patterns III: Building Block Patterns
53. Analysis Patterns, etc.
54. CRUD
55. Inverted Org Chart
56. Extended Inverted Org Chart
57. Customer-Agent
58. Bad Actors
59. User Interface States
Chapter 12, Analysis Patterns IV: Business Process Patterns
60. Chronologies
61. Tasks
62. Reservations
63. Orders
Chapter 13. Analysis Antipatterns
64. Geek Speak
65. Prioritization
66. Multi-User Network Access
67. The Cancel Problem
68. Quote, Then Estimate
69. Analysis Paralysis
|
|
|
