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.
Category Archives: Communication


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.

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.

Foundation Series: How To Read a Formal Use Case
Use cases represent the activities that people do when interacting with a system to achieve their goals. Use cases are a very effective tool for communicating and documenting what a system is intended to accomplish. Formal use cases are use cases that use a specific structure to represent the information. Knowing how to read a formal use case is important.






