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.
Category Archives: Writing
Posted in Business Analysis, Product Management, Requirements, Writing
Tagged business requirements documentation, correct requirements, good requirements, managing data, product requirements, requirement correctness, requirements documentation, software requirements, writing business requirements, writing requirements
7 Comments
Posted in Communication, Requirements, Requirements gathering, Writing
Tagged ambiguous requirements, bugs, gathering requirements, holy grail, holy grail requirements, managing data, monty pythod, monty python, python, Requirements, requirements elicitation, software requirements, unambiguous requirements, writing requirements
1 Comment
Another Use For ‘Why?’
“Why?” The question is our inspiration and our muse. “Why?” is the justification for our requirements. The key to identifying “What?” and “When?”, which lead to “How?” and “How Much?” But there is another use for “Why?” – communication of intent (with stakeholders and implementers). Requirements documents are artifacts, but they are also dynamic documents. By documenting “Why?” a requirement is a requirement, we make it easier for future readers to understand.
Posted in Business Analysis, Communication, Requirements, Software requirements specification, Writing
Tagged asking why, documenting intent, documenting justifications, documenting requirements, justifying requirements, managing data, requirements documentation, requirements intent, requirements justification
5 Comments
Posted in Communication, Design, Prioritization, Product Management, ROI, Requirements, Software development, Usability, Writing
Tagged documentation, documenting upgrades, goal-driven documentation, managing data, passion threshold, prioritizing upgrades, software documentation, software upgrade, suck threshold, upgrade prioritization, upgrade priority, upgrades, user centric documentation
Leave a comment
Posted in Communication, Design, Interaction design, Requirements Models, UX, Use Cases, Writing
Tagged doc, documentation, help file design, Interaction design, interaction design and documentation, managing data, software doc, software documentation, structured requirements, structured requirements and documentation, use case analysis, Use Cases, use cases, writing doc, writing documentation
3 Comments
Goal-Driven Documentation
Why do we write documentation? Because someone told us to write it? Because our competitors have it? Or because we want our software to be easier to use? It should be the third one, but often, writing documentation is an afterthought, and it is deprioritized, and we just get it done, instead of thinking about the goals for doing it in the first place and doing it right.
Posted in Product Management, Software development, Writing
Tagged competent users, goal-driven doc, goal-driven documentation, managing data, raising the suck threshold, software doc, software documentation, suck threshold, writing doc, writing software doc, writing software documentation
3 Comments
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.
Posted in Product Management, Requirements, Software requirements specification, Writing
Tagged business requirements documentation, good requirements, managing data, passionate requirements, product requirements, requirements documentation, software requirements, writing business requirements, writing passionate requirements, writing requirements
9 Comments
Posted in Product Management, Requirements, Software requirements specification, Writing
Tagged atomic requirements, business requirements documentation, good requirements, managing data, product requirements, requirement atomicity, requirements documentation, software requirements, writing business requirements, writing requirements
Leave a comment
Writing Verifiable Requirements
One of the ten big rules of writing a good MRD is writing verifiable requirements. Verification is both a function of having a precise goal, and having the ability to affordably measure the requirement. A precise goal is a verifiable requirement if we can clearly answer “yes” or “no” when asked if the requirement has been implemented. We also face the practical realities of being able to measure the results profitably.
Posted in Product Management, Requirements, Software requirements specification, Testing, Writing
Tagged business requirements documentation, good requirements, managing data, product requirements, requirements documentation, requirements verification, software requirements, verifiable requirements, writing business requirements, writing requirements
Leave a comment
Latest Articles
Comments on all Articles
