Consistent Requirements

writing consistent requirements logo

Consistency in writing requirements is important on two levels – strategic and tactical. Tactically, you need to write your requirements with grammatical consistency, so that potentially ambiguous statements will be interpreted similarly. You also need to write requirements that are logically consistent, so that you avoid “impossible” requirements and gaps of unspecified meaning. Strategically, your requirements need to reflect a focus on markets and problems that are consistent with your business objectives and the vision your company is manifesting

Consistent Requirements – Revisiting

Thirteen hundred ninety-six days ago (grin), I wrote about the importance of grammatical and logical consistency in writing requirements – an emphasis on the tactical aspects of consistency in writing requirements. This article adds a brief discussion on the consistency of the requirements you write. This article is the sixth update of a series of articles on the rules of writing requirements.

Grammatical Consistency

[source]

Writing requirements is not like other forms of writing in one key way – you don’t want to vary the terms and language you use in your requirements documents. Remember the critiques you received when you studied writing in school for a moment. Your teacher told you not to repeatedly use the same word, but to use synonyms for that word – walked, ambled, stepped, capered, etc. Those synonyms allowed you to create imagery and helped your readers avoid boredom. Your teacher encouraged you to use metaphors that created even stronger imagery – flew, slogged, muddled, danced, etc. Those metaphors allowed you to infuse emotion into your narrative and helped your writing come to life for your readers.

As Yoda said, “Unlearn, you must!”

Requirements are not a narrative. Your primary goal is not entertainment, it is enlightenment. Don’t use varying terms to describe the same action or object – use the same terms over and over again. Don’t vary the modifiers of terms except when you are explicitly varying the context and referenced items – and then make certain that you use the same modifiers consistently for the same context and references. When dealing with anything that has some complexity, provide a figure or diagram (possibly in an appendix or glossary) that explains the explicit meanings of each term and term-modifier.

For example, if you are defining requirements for a classification system for authored works, be specific about the definitions of author, editor, publisher, and reviewer. You may also need to define a term that is used collectively for all of them, like creators.

You must consistently use the same voice – ideally the active voice. And of course, you must not use ‘the system shall.’ [There’s a great debate in the comments on that article – one thing to note – all of the people on both sides of the debate emphatically expressed their consistent use of one form or the other.]

Logical Consistency

commander data from star trek [source]

Logical inconsistency most commonly comes from expressing the same requirement twice. If you use the exact same words to express a requirement twice, you’re being redundant and repetitive (grin #2). Most likely, the second expression of the same requirement is both unintended, and worded differently – running the risk that it will be interpreted differently, and therefore inconsistently.

You will also create logically inconsistent requirements when you express mutually exclusive requirements. These can be directly incompatible, like writing “the system must infer the value…” and “the user must provide the value…” Or they can be indirectly inconsistent like “the animal must bark” and “the animal must be a cat” – which is logically inconsistent because cats cannot bark (thereby making at least one of the requirements infeasible).

Strategic Consistency

stratego game board

One of the elements that defines valuable requirements is that they “support your business strategy.” In the context of value, that means you have created a decomposition model for how you intend to realize value – manifesting a strategy or a component of a strategy.

A strategy, however is not always defined by a single measure. Your strategy could include financial metrics and targets, as well as a stated mission regarding customer service levels, and a long-term investment that is hoped to eventually return long-term rewards. Your requirements, while not only completely defining the mechanisms for achieving value, must also be consistent with the other elements of your strategy.

For example, you should not take advantage of uninformed costumers when you have a core value of integrity – regardless of how effective that may be at meeting financial goals. The requirements that articulated the (subordinate) goal of grifting your customers (to maximize revenue) would be inconsistent with the goal of operating with integrity.

Conclusion

Consistent Requirements are requirements that

  • Are not in conflict with any of your strategic objectives, vision, or corporate goals
  • Avoid logical inconsistencies
  • Utilize consistent structure, terms, and grammar
  • Scott Sehlhorst

    Scott Sehlhorst is a product management and strategy consultant with over 30 years of experience in engineering, software development, and business. Scott founded Tyner Blain in 2005 to focus on helping companies, teams, and product managers build better products. Follow him on LinkedIn, and connect to see how Scott can help your organization.

20 thoughts on “Consistent Requirements

  1. Pingback: Scott Sehlhorst
  2. Pingback: Yama
  3. The primary component of strategy that requirements must support is positioning. For what one idea do you want your product to stand in the mind of the customer? The requirements for the product should at the very least be consistent with this idea.

  4. Thanks, Roger (@rcauvin on Twitter)!

    Really interesting point about positioning. My initial reaction was “alignment is more important than positioning” – but the more I think about it, the more I think they are two sides of the same coin.

    I think of alignment (with our internal goals) as “are we doing what we intend” where positioning is “will our product be perceived the way we intend?” Alignment is an inside-out perspective, where positioning is outside-in. Being market-driven requires that we include positioning as an aspect of how we engage our markets, to assure that our customers are considering our product as we intend.

    So I don’t know that my initial reaction is right. How do you (and other folks here) make the distinction?

    I also really like the “what one idea…?” way you describe positioning – very powerful!

  5. Scott, I think you’ve hit the nail on the head about “alignment” and positioning being two sides of the same coin. There is an interplay between internally-driven and externally-driven company goals:

    1. Fundamentally, companies start with very high-level financial (and possible philanthropic) goals.
    2. To achieve those goals, companies develop products or services that are successful only when prospective customers perceive them as valuable.
    3. For customers to perceive them as valuable, they must be positioned properly; i.e. the products must stand for something simple and compelling in the mind, and must solve problems.
    4. In turn, companies formulate lower-level internal goals that help build those perceptions.
    5. Included among those internal goals is developing a product that actually delivers the value that the company wishes the customer to perceive.
    6. To actually deliver the perceived value, the product must satisfy requirements that embody the intended positioning of the product.

  6. Pingback: Roger L. Cauvin
  7. Pingback: Kevin Brennan
  8. Pingback: topsy_top20k_en
  9. Pingback: Mariale Linares
  10. Pingback: Scott Sehlhorst
  11. Pingback: Karri Ojanen
  12. Pingback: Brett Lutchman
  13. Pingback: Laurens Bonnema
  14. Pingback: Remco Hulshoff
  15. Pingback: Igor Vergasta
  16. Pingback: Abhishek Katiyar
  17. Pingback: Anna Evans
  18. Pingback: Scott Willeke
  19. Pingback: Michael

Leave a Reply to Scott Sehlhorst Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.