“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.
Category Archives: Consulting
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
Communicating A Release Schedule With Use Cases
topsyWidgetPreload({ “url”: “http%3A%2F%2Ftynerblain.com%2Fblog%2F2006%2F07%2F19%2Fcommunicating-a-release-schedule-with-use-cases%2F”, “style”: “big”, “title”: “Communicating A Release Schedule With Use Cases” }); We manage release schedules with project management. We manage customer expectations with consulting skills. How do we manage customer expectations about release schedules? With Use Cases. Background We started a series of posts exploring why we apply use cases as part [...]
Communicating Intent With Implementers
Giving a functional spec to developers and testers is not sufficient for creating great software. To a developer, a spec is only the what and not the why. And for a tester, the software requirements specification is neither. Use cases provide the why that explains the intent of the system for the implementation team.
Latest Articles
Comments on all Articles
