Why Write Requirements

old typewriter keyboard

There is a lot of advice out there for how to write requirements. There is not as much discussion about why to write requirements. Spend some time thinking about why you write requirements before you make decisions about how to write your requirements.

Why Write Requirements?

Whether you communicate requirements through conversation, user stories with acceptance criteria, or traditional structured requirements and use cases, or diagrams and commentary, you are sharing them as a means to an end – creating the right product.  Don’t just follow some prescription and go through the motions of documenting requirements.  Take a step back and consider the following goals for your requirements-writing.

  • Improve your understanding of what your market needs (from you).
  • Decide on the sequence in which you will deliver what you choose to build.
  • Collaborate with (and set expectations for) your engineering team.
  • Manage expectations with your stakeholders.
  • Improve the efficiency of your product-creation process.
  • Remember why your team created what they created.

Every team will place different emphasis on each of the above goals, depending on their unique situation. Each of the above goals could be the most urgent goal for your team. All things being equal, IMHO the goals are in order of descending importance.

Understanding Your Market

Understanding what your market needs is the most important goal supported by writing requirements, although writing requirements only indirectly contributes to your understanding. There isn’t a single standardized structure for capturing market understanding, every product manager has their own approach, ranging from “in your head” to sticky-notes and back-of-the-napkin drawings to canvases, mind maps, wikis, and big documents. What they have in common is that they all help the product manager with synthesis and analysis of information, informing decisions about what is important to deliver.

Throw-it-over-the-wall processes are flawed not only because they inhibit change, but because they impede feedback loops. The simple act of documenting requirements based on your understanding of market needs will identify opportunities to improve your understanding of your market. As you apply the rules of requirements completeness and correctness, you will discover that you are missing some information, and that some of your analysis is incomplete or flawed. Writing requirements creates the feedback loop that forces you to revisit and improve your understanding of your market.

Sequencing Delivery

Develop a point of view about what is important and what will be important to your market, specifically to your customers and prospective customers. Combine that with a vision or strategy for your company, specifically how your company intends to serve your market. Mix in a perspective about the competitive landscape, specifically how your competitors (alternative solutions your customers could choose) compete and will compete.

When your documentation of requirements identifies who’s goals you’re addressing, how much addressing that goal is worth to them – and to you, and the relative strategic importance, that documentation tells you the relative value of each “thing” you intend to build. This is a key contributor to the sequencing of what you build.

Collaborating with Delivery

I love the name of Jeff Patton’s company – Comakers. It communicates that discovering which problems are worth solving is a collaborative effort between the product manager and the engineering team. It is the solving of valuable problems that is interesting, not just the discovery of valuable problems worth solving. Requirements, expressed verbally, pictorially, or in prose, are part of that collaboration and communication. The intersection of value with feasibility, timing, and cost is what defines what your team can accomplish.

Note that sequencing decisions are usually tightly coupled with solutioning decisions. In other words, you cannot solve “when” and “how” independently, you have to solve for both, in the context of “why” simultaneously.

Managing Expectations

Stakeholders are better served when they know what to expect. Part of knowing what to expect is knowing the scope of what you intend – ideally communicated in terms of market needs, more commonly shared in terms of “what” and “how.” The requirements you communicate are a reflection of the “why” and are a key component of managing expectations. There is a lot more than this to managing expectations (for example, predicting “when”), but being able to say “these are the problems we intend to address” is a great place to start.

Improving Efficiency


Teams that start building without knowing why they are building will, by definition, build stuff that isn’t needed. Teams that ignore opportunities to get smarter about changing needs will also, by definition, build stuff that isn’t needed. The requirements you document enable teams to focus their efforts on what is needed. The cadence by which you update those requirements as you get smarter (learning more about your market, adapting to changes in your market, etc) and your team consumes those updates will impact the team’s ability to stay focused on a – by definition – moving target. The clarity of how you document and communicate your requirements impacts the effectiveness of your communication. All of these factors contribute to the efficiency of your team – and therefore to their capacity to create value. My experience has been that (with caveats for diminishing returns) small amounts of additional time following the rules of requirements avoid large amounts of time clarifying and re-communicating, freeing up more time for me to “get smarter” about my markets.

Remembering Intent

Enterprise software folks know full well that software applications can live for decades. We also know what it’s like to have no idea why a particular capability exists in a product, who uses it, how much value it provides, or what would happen if we improved (or removed) it. Now that software-as-a-service has gained traction, more and more consumer-facing products will have similar long life-cycles. When you document requirements – at the time of building things – don’t throw them out. Keep those requirements around, they will provide context later, after you’ve forgotten why you built something. This is particularly important for whoever takes over your job after you get promoted, or leave for a greener pasture.

Conclusion and More

Keep in mind why we write requirements. When considering how you will write requirements, think about the impact of different techniques on the goals that matter to you.

If you want to follow this approach at the next level of detail, check out The 8 Goals of Use Cases.

13 thoughts on “Why Write Requirements

  1. Great post, and many products besides enterprise software suffer for your last point.

    One other reason:

    If the product manager leaves and is replaced mid project (I assure you that this is not a rare occurrence), well written, clear requirements from the beginning of the project are a lifesaver to the incoming product manager.

    I am in this hell right now. My predecessor didn’t articulate clearly what the “need” was, but listed a set of specifications. Engineering wasn’t constrained in what they were doing, so they “interpreted the requirements” how they saw fit. Now that we are past the halfway point, we are scrambling to try to recover what the intent of the project/product was.

    In this case, the original requirements were a list of features without rhyme or reason, on an excel file.

    But I guess this is why I get the big bucks.

    1. Hey Geoffrey, you made me chuckle!

      I’ve “picked up the reins” several times – and almost always have to reverse-engineer / re-create / re-define the goals for the product. Very rarely has someone left a clear vision behind when they left. Great points as always!


  2. Great topic as always, Scott. Though I was just picturing myself saying to my project teams, “let’s spend some time thinking about why we write requirements”, and getting some very puzzled looks :-). But we do spend a lot of time discussing and collaborating on how to capture requirements, testing different models to see how well they work for the various audiences and purposes.

    @Geoffrey: I’m curious to learn whether you don’t consider the specifications you inherited “requirements” as well. I get what you are saying, that what is typically called “business requirements” (the description of the business objectives and business needs) have not been captured (huge issue), but it looks like you did inherit the “product requirements” from your predecessor, right?

    I experience the same as you and Scott all the time, and what I’ve concluded is that there is no documentation of the vision / business objectives left behind *because nobody developed it*, rather than just forgetting/refusing to documenting it.

    I find it hard to understand why people are so fixated in jumping into “solution mode” without spending even a few minutes thinking about what the objectives are, but that’s the reality. I’ve lost count of times when I asked a project sponsor what is the problem he/she is trying to solve, and it’s like pulling teeth to get a valid answer, because they always go back to saying “oh, I just want to have this report with 5 columns sent to me by email every week / these quotes automatically calculated / the help desk requests routed to the next available agent “. ARGH!

    1. I guess it is how loosely you want to accept the definition of “requirements” to be.

      My predecessor was a smart man, a PhD in physics, but he was a poor communicator, and worse, didn’t get involved with the details. His idea of requirements was to take the current specs, and that of the competitors, and just crank up the {precision|speed|resolution} and toss it to engineering. No documentation of why, what need it would fulfill, or even whether there was a true market problem to be solved (this thinking isn’t just endemic to my field, scientific instruments).

      Since there was little guidance beyond a spec sheet with near impossible (need to break the fundamental laws of physics impossible, not just hard to do) requirements, the engineering team was left to muddle around.

      Then he left, and after a fairly long time of the position being unfilled, I was hired. I am trying to understand the logic and reasoning behind the original specs, but after long bouts of pulling my hair out, it really just appears to be a ratcheting up of the specs, and not some grand strategy to lead the market with a great product.

      There were no business objectives besides: “Make a great product, and take lots of business from #1”.

      1. The worst part is, because, as you say, your predecessor was a “smart man” so there’s a non-trivial possibility that the “solutioning conclusions” he reached could absolutely be the best approach to solving some problems that were only articulated in his head. Makes it hard to throw that stuff all out and start over – what if you’re throwing out the “right answer?”

        From our conversations over the years, I’m willing to bet you’re already doing the following, but for the benefit of newer folks who may be faced with a similar situation and no idea what to do:

        Instead of trying to reverse engineer his specs, can you start by (1) defining the business objectives that make sense now, and (2) the goals that would best support those goals? Then you can just assess the suitability of his ideas to supporting _your_ goals. It may be that he focused on fantastic solutions to the wrong problems. My anecdotal experience is that some of the “speeds and feeds” requirements will “move the needle” on sales, and others will not.

  3. “Instead of trying to reverse engineer his specs, can you start by (1) defining the business objectives that make sense now, and (2) the goals that would best support those goals? ”

    THIS. I’m glad you spelled it out, Scott, because so often I see reluctance in the business and technical teams to go back and define the business objectives, derive the business requirements from them, and then compare the specs you have with these requirements to see what you need to add/remove to keep only what is adding business value.

    Sometimes I think that the (irrational) thought behind this reluctance is “oh, I’ve spent so much effort in this initiative already, what if I learn that it’s entirely irrelevant for my business objectives and requirements”. Yeah, as if avoiding the truth will help you somehow :-).

    1. Thanks, Adriana!

      The other (irrational) justification I’ve heard more than once is “wasting time revisiting this would be wasting time.”


      ps: redundant redundancy was intended and intentional.

  4. Great post and follow-up thread Scott, Adriana and Geoffrey.

    Building on Adriana’s point: “what I’ve concluded is that there is no documentation of the vision / business objectives left behind *because nobody developed it*, rather than just forgetting/refusing to documenting it.” Yes! In my experience, if the business objectives aren’t clear to everyone they’re probably not clear to anyone. It’s rare to find a situation where one person on the team thoroughly, accurately and clearly understands the business objectives but just fails to “write them down” and communicate them clearly to the rest of the team. Usually the lack of transparency of the business objectives is a symptom of incomplete understanding across the team.

    And Geoffrey, I definitely feel your pain about stepping into a project without clear business objectives. The resistance to “going back” to examine the goals can be difficult to overcome. Good luck!

    Great conversation all!

    1. Thanks, Brian!

      I think I agree with you that when everyone doesn’t know, it generally means no one fully knows. But I’ve definitely seen teams where limited information was shared, even when someone had a pretty comprehensive (but not technically complete) understanding of the goals, but didn’t share, because that person had a “your job is to do what I tell you” mindset.

Leave a 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.