Is your team focusing on the mechanics of creating good software, without understanding the connections from your efforts to your goals? Are you primarily focused on the structure of use cases, the syntax of user stories, and the cardinality of your domain diagrams? All of these things are important to […]
Flashback: A Year Ago This Week on Tyner Blain [2006-06-16]
A look back at the best from a year ago.
Flashback: A Year Ago This Week on Tyner Blain [2006-05-26]
A look back at the best from a year ago.
Why Requirements Approval Matters and How To Make It Easier
Getting requirements documents approved can be a pain in the butt. Why do we need to do it in the first place? The approval process is more than just reaching concensus or creating a contract. Done correctly, it presents an opportunity to get more inputs from stakeholders.
Flashback: A Year Ago This Week on Tyner Blain [2006-01-06]
A look back at the best from a year ago.
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.
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.
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.
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.