Requirement Patterns

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.

Discussion [Participate or Link]

  1. David Locke said:

    Let’s be clear here applications automate meaning, not doing. Doing doesn’t get done without meaning. Meaning is not prioritizeable or negotiable. Neither is doing.

    When functionality is negotiated away, the user must build replace that functionality. They will not go without it. When meaning is negotiated away, the meaning is ascribed to the meaningless data, which can only lead to poor decisionmaking.

    Requirements management as it is taught in school never once addresses the discipine specific cultures, of which they are one. You are taught to think a particular way. I’m telling you, you are wrong. Feel that. Then, ask yourself how it is to be a user and be told by someone that can’t do your job, that you should do your job this way instead. How does that feel? The same way. We are not Spock. Spock isn’t better. People love their work. Automating it doesn’t make it more loveable.

  2. David Locke said:

    Code is free, so why are you optimizing for that by ruining the reqirements. The expense has shifted to the user and the effort they have to put out to code around the application. That is where the true expense is. Back before the bust, code was expensive. We need a requirements practice for the new realities that ship coder work to the cheapest coder.

  3. Abhijit Nadgouda said:

    David, thanks for your comments. The aim to prioritize requirements is not to filter or negotiate them. It is to help plan the development, identify depedencies and maybe help in other factors of project management like budget. Neither meaning nor doing is negotiable. But by prioritizing we can maybe stagger the rollout, in more manageable pieces. I agree with you that automation is not just for namesake, if automating something ends up harming meaning and doing, it should be reconsidered.

    I agree with you that code is free. However I would like to qualify that use of code is not. Using the wrong code, the wrong software can do more harm than just wastage of time. Requirements practice is required not necessarily only to develop code, but also to identify which one to use.

  4. Patterns and the Evolving Business Analyst : Practical Analyst said:

    […] found some wise counsel to this point in a post on ifacethoughts: There is a lot of angst against patterns since they seem to impose rather than give space for […]

  5. Patterns and the Evolving Business Analyst : Practical Analyst said:

    […] I found some wise counsel to this point in a post on ifacethoughts: […]

Say your thought!

If you want to use HTML you can use these tags: <a>, <em>, <strong>, <abbr>, <code>, <blockquote>. Closing the tags will be appreciated as this site uses valid XHTML.



Abhijit Nadgouda
iface Consulting
+91 9819820312
My bookmarks


This is the weblog of Abhijit Nadgouda where he writes down his thoughts on software development and related topics. You are invited to subscribe to the feed to stay updated or check out more subscription options. Or you can choose to browse by one of the topics.