Archive of Communication Articles

“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.

Kathy Sierra writes (another) great article at Creating Passionate Users. This time, she talks about why users don’t upgrade and presents ways to get users to install the latest version. We focus in this article on one way in particular - using goal-driven documentation to encourage upgrading.

Yesterday we wrote about focusing our documentation on what our users are trying to accomplish. With a structured requirements approach, or with an interaction-design driven approach, we’ve already solved half the problem - determining what to document.

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.

Marcus Ting-A-Kee has assembled a great presentation on the value to his company of requirements management tools. In addition to creating the presentation and sharing it with all of us, he shares the process of creating the presentation in several articles.

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 of product management, identifying 8 goals for which use cases are [...]

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.

We can build a prototype of what the stakeholders don’t want, and then get feedback and fix it. Or we can review use cases of what we intend to build, confirm that each stakeholder wants it, and build it right the first time.

Seilevel has a post that presents the top 10 signs that you should not pursue a career writing requirements, check it out. Thanks Joy for the great article!

While effective meetings may not be the key to success, ineffective meetings are inarguably one of the largest time wasters in corporations. Applying these tips before, during, and after meetings will make us much more effective.