A look back at the best from a year ago.
Business Analysis / Product Management / Requirements / Requirements Models
Posted on:
Business Requirements, Project Scope, and Coupling
Robin Goldsmith wrote an interesting article for RQNG about business requirements – what he calls “REAL” requirements. Gathering the right requirements demands more than just effective listening skills, you have to focus on the right problem. Robin brings up a theme we’ve discussed here in the past, and again in today’s article.
Business Analysis / Product Management / Requirements / Writing
Posted on:
Writing Stylish Requirements
You knew it would happen eventually, the big ten rules of writing requirements has become the big twelve rules. Maybe scope creep isn’t such a bad thing after all. Writing style plays an important role in writing requirements too.
Requirements
Posted on:
Abstraction And “Requirements”
I don’t know how many of our readers have reached a conclusion to this debate, but we have for now. Thanks to everyone who has contributed to, enjoyed, or at least tolerated this ongoing discussion. Roger had some good comments in our previous article – we’ll try and address one of his points here. His point, I believe, is that using the word “requirements” to describe multiple levels of abstraction in the definition of a product is a bad thing.
Product Management / Requirements
Posted on:
Valuable and Functional Requirements
Roger asked some interesting questions on one of our previous posts about market and product requirements. In a couple recent articles, we presented some specific examples to clarify the semantics and language of different types of requirements. Roger asks six questions about functional and non-functional requirements in the comments on the last article. In this article, we answer them.
Product Management / Requirements
Posted on:
From Market Requirement To Product Requirements
We looked previously at an example of market analysis, defining first a market opportunity, and then a market requirement. We wrote an article a while ago about how to go from an MRD to a PRD. In this article, we will look at the journey from our market requirement to associated product requirements. And thanks, Roger, for throwing down the gauntlet.
Business Analysis / Product Management / Requirements / Writing
Posted on:
Writing Correct Requirements
We ran a series called Writing Good Requirements – The Big Ten Rules in May 2006. Bloggers are notorious for not being able to count. We had ten rules at the time, and now we’re adding an eleventh. Writing Correct Requirements may have been the unwritten rule, but now we take a look at it.
Product Management / Requirements / Software requirements specification / Writing
Posted on:
Writing Passionate Requirements
One of the ten big rules of writing a good MRD is writing passionate requirements. What in the world is a passionate requirement [they were all wondering]? When you believe in the product, are committed to the work, and aren’t bored, you can write passionately. The goal of a requirement is to create sustained understanding. A dry document can create understanding, but an engaging document will sustain it.
Product Management / Requirements / Software requirements specification / Writing
Posted on:
Writing Atomic Requirements
One of the ten big rules of writing a good MRD is writing atomic requirements. Just as verifiable requirements must be concretely measurable as having been met or not, so must atomic requirements. If a requirement has multiple elements that can be implemented separately, it is not atomic.