After I’ve solved the same problem half a dozen times, even I start to notice patterns. Pattern recognition is an important skill for people doing requirements. However, if you don’t have a way of acting on the pattern recognition, you aren’t helping yourself.
I’ve begun to catalog the patterns that I see associated with software requirements. Formally capturing and articulating of the models associated with a particular pattern is probably beyond the scope of a simple blog post, but the base technique I use with patterns is simple enough to describe here.
I start with a spreadsheet of questions that I seem to have to ask associated with the pattern. For example, if I’m working on an application that has a login, then I’ll have to answer the same questions that I had to answer the last time I worked on an application with a login:
1. What credentials are required to log in?
2. Is the login process dependent on whether cookies are enabled?
3. Is the login process dependent on what machine I’m using?
4. Are there any security measures in addition to the user provided login credentials?
5. Are we tracking the number of attempted logins?
6. Are there thresholds of attempted logins that should trigger us to do other things?
7. What if I forget my password?
8 What if I forget my username?
I put these questions in the first column. I then have a blank column next to it for the answer. The third column contains the impact of the answers. The impact might be a list of use cases that are impacted, or other models that I might have to change based on the answer.
As I use this pattern more and more often, the underlying models become more and more reusable as I flesh them out. Ultimately, I begin to build a personal pattern library.
