This post is a discussion about the following articles:
The authors of these articles: Jim Heumann, Thomas Hathaway, and Karl Wiegers, propose three starkly different approaches to writing a business or technical requirement. The fact that all of these approaches are different yet effective are a testament that writing requirements is an imperfect science. There is not a one-size-fits-all process or method that can be applied to craft a requirement in every situation. However, what these authors provide us with is a set of guiding principles or “rules of thumb” to follow when writing requirements.
Heumann offers us a process of writing requirements from the perspective of a programmer by employing similar concepts and practices that are used to write code. He draws parallels between core principles that are used in coding such as following a structure, using best practices that are established, elaborating with comments, knowing the language, managing change, etc. A parallel that I found especially interesting is understanding the language that you are using. Heumann explains that while programmers must learn a certain programming language to code and “speak” to the computer, requirements are written in natural languages such as English or French. However, while many requirements writers may take this for granted, understanding the language that you are using is also very important in normal writing for understanding the limitations of the language you are using as well as following best practices. A good example of this is using active voice instead of passive voice.
Hathaway lays out his philosophy for writing a requirement into three stages: ‘Capturing’, ‘Clarifying’, and ‘Confirming’. Capturing is the means by which you gather your requirements. Hathaway explains that this can be done through several methods such as:” interviewing, observation, analysis, etc.” Hathaway essentially explains clarifying as “making sure that more than one person (i.e., the author) fully understands what the requirement means.” Of course, a requirement is always going to make sense in the mind of the author that wrote it because they wrote it! However, as Hathaway explains it is important to have different, fresh, eyes look over a requirement because ultimately you are writing requirements for an external audience as a form of communication, not just yourself. The final step for Hathaway’s approach is confirmation which really just means reconciling requirements and their different interpretations between the business community and the technical community.
Wiegers takes a very simple and standard approach to writing requirements. He lists and explains the key characteristics and qualities of a ‘good’ requirement. Some of these characteristics are: correct, feasible, necessary, prioritized, unambiguous, consistent, complete, etc. These are the guiding principles that I am most familiar with and have learned about through course material. While they seem quite simple and don’t follow a deep philosophy, I contend that they are still useful to keep in mind as you are writing requirements and as a checklist to use once you are reviewing your own requirements or critiquing someone else’s.
Something else that is important to mention is that these three approaches are not mutually exclusive and you may use any and all of them in conjunction with each other. In fact, it may be better to do so.