Complete Requirements

big ten rules of writing requirements logo #5

You give your requirements to the engineering team, and they look complete. The team builds your product, you launch it and the market soundly rejects it. Why? Because your requirements weren’t complete – they didn’t actually solve the problem that needed to be solved.

Complete Requirements – Revisiting

Going back almost four years, I wrote Writing Complete Requirements, as part of the Big Rules of Writing Requirements series. That article centered on two key ideas of requirements completeness.

  • Data, not opinion, is the most important input into determining completeness.
  • There is no absolute way to determine the completeness of your requirements in advance.

Completeness is best measured by market acceptance, so technically you can’t know if your requirements were complete until your customers buy (or fail to buy) your product. This doesn’t mean you should give up on this rule of requirements – you can still focus on, and improve, the completeness of your requirements.

Objective and Heuristic Assessment

picture of raven with a blue eye

Given a market problem and the associated requirements (which you can argue are actually the same thing), you can review those requirements to determine if they objectively appear to be complete. This assessment is based on what you objectively know about your market (needs, opportunity costs, competitive alternatives, etc). You can also apply heuristic, or logical analysis to identify gaps in the language of your requirements.

Objective assessment is the application of market knowledge (data) to determine if the nature of the problem is being addressed completely by your requirements. A bird-feeding maven would know that the requirements for your bird feeder would be incomplete if they didn’t address the problem of squirrels stealing food from the birds.

Heuristic analysis is the identifications of logical omissions in your requirements, without the need to apply market insights. A logician would know that the requirements for your bird feeder were incomplete if they didn’t address the need to refill an empty feeder.

When you’re writing requirements, you need to do both. Heuristic analysis of your requirements will identify where your requirements do not fully solve the problems you already know about – an eCommerce checkout process without the ability to receive payment, for example. Objective assessment will help you identify the problems that you overlooked but need to solve – the need to allow customers to have different billing and shipping addresses when placing an order online, for example.

Complete Requirements for Incomplete Solutions

image of worms on the table - illustrating a metaphor

Don’t confuse having complete requirements (a good thing) with completely solving a problem (not always a good thing). In agile development, the idea of satisficing is key to scoping individual iterations. The idea, simply put, is to solve enough of the problem, and not delay delivery (and value) until you can build a solution to the entire problem. Because of the law of diminishing returns, for many market problems, there is little or no incremental value in solving the entire problem. Those resources can be better applied to solving additional problems.

Kano analysis provides a framework for identifying which market problems must be completely solved, and which ones have a more is better characteristic. In practice, more is better problems exhibit the law of diminishing returns, and should not be “completely” solved.

diminishing returns nature of real world features [larger image, or view the entire Kano analysis presentation]

Conclusion

Complete Requirements are requirements that

  • Identify all of the market problems that need to be solved and their nature (absolute vs. diminishing returns).
  • Are logically complete in their coverage / articulation of those market needs.

To objectively improve the completeness of your requirements, apply market data in an assessment of your requirements. To heuristically improve the completeness of your requirements, look for logical inconsistencies and gaps in reasoning or coverage.

  • 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.

12 thoughts on “Complete Requirements

  1. The need for objective assessment is the best reason to desire a product manager with domain experience (to re-ignite that debate, consider jumping to the comment thread (starting at #8) on this article about product management certification ). The need for heuristic analysis, combined with the assumption that your product manager has access to people with domain expertise while learning it, is the best argument for not worrying about it.

  2. Pingback: Scott Sehlhorst
  3. Pingback: BrainJocks
  4. Pingback: Chuck Graham
  5. Pingback: Dave Kohrell
  6. Pingback: Kev Gower
  7. Pingback: Jonathan Babcock
  8. Pingback: Darrin Johnson
  9. Pingback: Sara BROCA
  10. Pingback: kevin berardinelli
  11. Pingback: Bruce Onder

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.