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.
Business Analysis / Product Management / Product Strategy
Posted on:
Who Are Your Customers – Comparing Products Part 2
The first step to comparing products is understanding your customers. This may seem counter-intuitive, but your product’s capabilities are meaningless unless you are comparing them from your customer’s point of view. This article is part 2 in a series on comparing products. Check out part 1, then continue with this […]
Business Analysis / Product Management / Product Strategy
Posted on:
Compare Products Not Specs – Comparing Products Part 1
Recently, the gadget-reviewer crowd has caught on to something we’ve known for a long time. Comparing products is not about comparing specs, it is about comparing how well the products solve problems that customers will pay to solve. That begs the question – how should you compare products? Read on […]
Agile / Business Analysis / Ishikawa Diagram / Prioritization / Product Management / Requirements / Requirements Models / Software development / Software requirements specification / User Stories
Posted on:
Atomic Requirements
Each requirement you write represents a single market need, that you either satisfy or fail to satisfy. A well written requirement is independently deliverable and represents an incremental increase in the value of your software. That is the definition of an atomic requirement. Read on to see why atomic requirements […]
Business Analysis / Product Management / Requirements
Posted on:
Writing Unambiguous Requirements
Writing unambiguous requirements is about understanding what is written, and what is read. Without a clear understanding of your market, you can’t write unambiguously. Even when you understand your market, you risk writing something that is ambiguous to your readers. Documenting requirements is about communication. Don’t break this rule, or […]
Business Analysis / Requirements / Requirements gathering
Posted on:
Business Goals and Requirements
One of my colleagues got into a debate with one of his colleagues about the differences between goals and requirements. His opponent fired the following salvo: “[That] is not a business requirement in any company of the world…” What you call your requirements is less important than how you communicate […]
Business Analysis / Ishikawa Diagram / Product Management / Requirements / Requirements Models / ROI
Posted on:
Attainable Requirements
Unless you live in a world filled with unicorns and rainbows, writing realistic requirements is critical. When you set unattainable goals, the best result you can hope for is a frustrated engineering team. Write requirements that are attainable, and your team will surprise you with what they can achieve.
Agile / Business Analysis / Ishikawa Diagram / Product Management / Requirements / Requirements Models / Software development / Use Cases / User Stories
Posted on:
Concise Requirements
Concise requirements give your team a useful, easy to read and easy to change understanding of what must be done. Great requirements exist to do three things: Identify the problems that need to be solved. Explain why those problems are worth solving. Define when those problems are solved.
Flashback
Posted on:
Flashback: This Week in the Past on Tyner Blain [Feb 16]
A look back at the best from this week in the past.