Ok. I said it. The dreaded “D-word”. Design. We’re not supposed to do that. Let the designers do the designing, and let the business analysts define the requirements. Actually, I’m not suggesting that design be included as part of software requirements. I did, however, want to talk about the relationship between software design patterns and software requirements.
Design Patterns in the software world were introduced primarily through the well-known book “Design Patterns: Elements of Reusable Object Oriented Software” by Gamma, Helm, Johnson, and Vlissides. Design patterns are basically reusable solutions to common problems that are encountered when building software.
It would be very unusual for a Software Requirements Specification to explicitly call out a design pattern as a requirement. However, a good software architect knows how to hunt for clues in requirements documents. Oddly enough, many design patterns end up being hinted at not so much in a Software Requirements Document, but rather in Business Requirements Documents.
For example, a Business Requirements Document might talk about the need of a piece of software to calculate tax correctly based on the location of the customer. A software requirements document might contain the actual business rules used to calculate tax in the current locations that the software is deployed. A clever architect might notice that the business requirement is actually the one that might lead him to adopt a Strategy design pattern for calculating tax. The Strategy pattern essentially encapsulates an algorithm in an object, separating the calculation logic from the object on which it is performing a calculation. Different tax strategy subclasses could hide from the rest of the application the complicated logic associated with sales tax in Canada vs California.
Many design patterns are actually driven not so much from functional requirements as they are from non-functional requirements. For example, scalability and maintainability requirements frequently drive architectural choices. Knowing that a customer wants to be able to add functionality in the future helps us to pick design patterns that minimize the cost of adding functionality in the future. Many business analysts pay only lip service to non-functional requirements, even though these may define some of the most fundamental architectural decisions made in a piece of software.
If you are a requirements analyst, should you care about design patterns? Absolutely. Design patterns, as defined by Gamma et al, always have context applied to them. Good design patterns have well defined rules about when each pattern should apply. Learning about design patterns and learning what types of things an architect is looking for as clues to which design pattern to apply will help you to write better requirements. If a software architect, reading your requirements, can’t decide if a design pattern applies or not, it’s a good indication that your requirements are missing something.
