Requirements Patterns and Antipatterns:

Best (and Worst) Practices for Defining Your Requirements

Donwload a Demo!
Purchase Tablet UML
Tablet UML Fact Sheet
Tablet UML White Paper
Tablet UML News
Ink in 60 Seconds!
The 21st Century CocktailNapkin
Presentations
Free Stuff!
Contact Tablet UML
Tablet UML Samples
Tablet UML Support
The Tablet UML Company
UML Training
UML Consulting
Requirements Analysis
Tablet PC Consulting
Speech API Consulting
.NET Consulting
Process Consulting
Project Estimating
Other Tablet Tools
Other Links 

 

A new book from Martin L. Shoemaker

 

Coming soon from Addison Wesley

The Tablet 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 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 UML. In this book, Martin returns to his main theme from 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

Readers of Requirements Patterns and Antipatterns may these additional resources to be useful:

You can pre-order Requirements Patterns and Antipatterns: Best (and Worst) Practices for Defining Your Requirements from Amazon.com.

Home    Contacts/Questions

UML® is a registered trademark of the Object Management Group.
Tablet PC®, Microsoft Office®, and Microsoft .NET® are registered trademarks of Microsoft Corporation.
PayPal® is a registered trademark of PayPal, Inc., an eBay Company.

Copyright © 2005 by Martin L. Shoemaker.
All rights reserved.

Tablet PC Development Tools are within reach