If you've been around for a while, you've probably heard about patterns. As the name implies, patters help you cut time and costs by re-using the same solution, whenever the same problem occurs. So, a pattern identifies the problem and its context, and the best possible solution to it, in such terms that you can apply it again whenever necessary. In software design, patterns can be lines of actual code, but, more often, they are a textual description of the solution.

The pattern craze originates in 1977, in Christopher Alexander's "Pattern Language", and has continued since, with patterns used when they are necessary, and sometimes in excess, just to show off. A pattern language is the collection of the patterns used to address a bigger problem, such as, in our case, requirements management. All the stages necessary for solving a problem, as well as the actors, objects and tools necessary, are described in the respective process.

There are some tricky issues in using patterns. First of all, you have to identify them - which is done by analyzing the case model or the event response. When you have a pattern, you need to define it in such a way, as to allow instant recognition whenever you are faced with the same problem again. This is done by using several modeling methods, sometimes combined, in order to avoid the work of re-analyzing and re-defining a pattern, once you have already dealt with it.

Because they are not bits of code, but literary descriptions, the patterns are very flexible, and can be modified and adapted as the context of the problem requires. You should not think of a pattern as a solution to your problem, but rather as a step-by-step guide to solving the problem.

There are many good books out there that contain very useful, common patterns. You should start by reading some of them, until you are familiar with the concept, and able to identify at least some of the most common patterns. "Design Patterns: Elements of reusable Object-Oriented Software" by Erich Gamma, Addison-Wesley, 1994 and "Object-Oriented Software Engineering - A Use Case Driven Approach" by Ivar Jacobson, Addison-Wesley, 1992, are two very useful books for object-oriented developers. "Data Model Patterns - Conventions of Thought" by David Hay, Dorset House, 1995, provides a wider background, with solutions for different types of businesses.

Since the key to using patterns it to think abstractly, you'll need to do a bit of reading in order to familiarize yourself with the concept, and to understand how to make useful abstractions from a given problem. It will be a while before you can use patterns efficiently. In most cases, you will not be using the patterns created by other people, but your own, the ones you have been faced with before, because these are easier to remember and, probably, specific to your line of business. Usually, a pattern is considered as such when it has been used for at least three times to solve a similar problem. On the long run, patterns can save you a lot of time, but the main problem is that you are probably running a tight deadline and under a lot of pressure from the very beginning, and thus you don't have time to look which pattern should be used for which situation.

All patterns look a bit similar, even if they are literary texts. All of them have a name - if you are able to name them suggestively and consistently, you are more likely to find what you need quickly. They include a description of the problem, of the context, and of the intent (this is actually a sentence or two about what the pattern does). Then you have the so-called "forces" - which are a bit like guidelines for how to implement the solution. They help you keep everything in order and under control. Of course, you have the solution, since this is the whole point, and the resulting context, which describes the state of the system after the use of the pattern. You can also include examples and samples of where you've used the same pattern before, in order to make things clearer. Try to keep your document as short as possible - you don't want to read a short novel, when time is of the essence. A good method to identify when a pattern can be used is to match its name, or any other of the above elements, to patterns already created (assuming you've named them correctly and consistently) and to check if you apply it to the given situation.

In writing software requirements, patterns are useful precisely because you don't have a lot of time to complete this stage. We've seen how important it is to prioritize your requirements, but this is a time consuming process. Sometimes it's a good idea to use a pattern to do this for you, in the same way as emails are prioritized according to different criteria. Another pattern available for the requirements is called Presentation, and it allows the display of data, when it is necessary to communicate it to human users. The Presentation pattern was created in order to allow you to focus on what data must be displayed, and not the method how to display it.

As you get more experienced in the use of patterns, you are sure to create some of your own, custom made for your specific needs and easy to identify and use whenever necessary. It may be a while before you can use patterns for their full benefits, but then you'll see it was worth the patience.

This entry was posted on Saturday, August 25th, 2007 at 10:45 am and is filed under Requirements Management.