Good Requirements Relate to Business

Why Requirements are so critical in the software product and project business. How do they relate with the business case?

Have you ever heard of:

  • A Developer complains: “I cannot program to these requirements!”
  • The Product Manager says: “Our developers wrote features that didn’t do what the customer needs!”
  • Developer: “don’t tell me how to do my job”
  • Developer: “This is NOT A REQUIREMENT!”
  • ALL: how much detail is needed?
  • ALL: when do I know when I am done?
  • Who writes Requirements?
  • Who writes specs? What’s the difference?
  • Tech. acct. manager: “It is not my responsibility to write requirements. I am just communicating what the customer told me!”
  • Customer: “this is not what I needed!”

This causes a number of issues:

  • Friction between people, teams and functions make everything harder. When the project is critical and the pressure is very high things often get out of control.
  • Different ways to see the product or the feature objectives and priorities. Misalignment
  • Bad requirements lead to bad prioritization and wrong or very (unnecessarily) risky decisions.
  • Lack of common vocabulary or methodology take the organization to non repeatable success or most often to unsuccessful products.

Examples of why this happens:

  • Requirements are not actionable. Developers have to guess
  • Requirements are too detailed. Developers are told the solution to build (it’s their job and they are they are good at building solutions to problems). But there is no such a thing as a document with all details covered.
  • Developers lack the understanding of the customers need…which makes it harder for them to make informed decisions in building the solution
  • The customer tells the dev team what the solution should be. But Problem Solving is not for them. Explaining us the problem is. We are the experts for finding a solution to the problem (for N customers if you mean to build  a product that sells to a given  market)

The Value of Good Requirements

  • Are actionable
  • Provide a common language for everybody (from dev to customer)
  • Are easier to prioritize (pain, severity, importance etc)
  • Are easier to agree upon when we discuss what we need to do
  • Are easier to compare with others (patterns, use cases)
  • Are easier to analyze and design for
  • Are easier for providing better and faster estimates
  • Reduce the risk of rework (you may not even get to have another shot at it)
  • Are connected to the business

Yes, connected to the business! This is the critical, essential part of all this. What is the impact on business that every technical decision related to the software can have. How to relate a major release success criteria with software engineering tasks and vice versa.

If you are able to master it you will be successful. Making sure you have Good Requirements means you have done most of the work to get to a successful (business) outcome.