Christopher Creel presents Requirement Patterns, analogous to Design Patterns, but to cover the problem space rather than the solution space. I agree with him that requirements engineering is not given enough weightage. One way a project effort and cost estimate is brought down is by stripping down the requirements elicitation and analysis. Assumptions or ‘I think’ or ‘I feel’ replace the factual information that could have been gathered.
Academic institutions groom us as solution-space engineers from the moment we express an interest in building software. We learn algorithms, language theory, computational theory, discrete mathematics, and calculus. Each of these lessons is meant to help us solve problems. But we never learn about the problem space.
Requirements are necessary, they define the problem, they define your business need which is always unique from someone else. Unless the problem is identified and defined properly no amount of engineering is going to be able to solve it.
Patterns help you have solutions ready for repeatable problems. How many times has it happened that you came across a seemingly similar problem but could not recollect what you did to solve it! Patterns are nothing but a documentation of these, that you can refer to solve these repeatable problems. There is a lot of angst against patterns since they seem to impose rather than give space for innovation. There is a reason why patterns are not standards, because it is quite possible that they apply in most of the cases, not all. Patterns should be used as guidelines, not as a must-comply-with standard.
Christopher mentions that patterns can be used to reproduce the indescribable qualities found in timeless structures. The purpose of patterns is not to be attractive, but to restrict ambiguity.
The quality, in this instance, is not necessarily the ability to draw people in (though that would be a nice side effect). Rather, it’s the ability to restrict ambiguity in the problem space while simultaneously introducing latitude into the solution.
Christopher presents the Specify, Presentation and Prioritize Requirement Patterns. While I was reading it I could find out there use, since I used some of these unknowingly. I always use a combination of questions What, When and Where to gather information and Why to identify the purpose, the intent. These patterns can do the same thing. Take a look at them, even if you do not specifically use them, they might help you identify the missing pattern in your identification of problem space.