Archive of Communication Articles

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.

Robin Lowry has posted a story of a demo gone horribly wrong at The Product Management View. In the story, users end up confused by the myriad of features of the software - resulting in a $5,000 sale instead of a $250,000 sale.

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.

*(scroll to the bottom and come back)

Guerilla Product Management (pdf) is an article available from Sequent Learning Networks, written by Steven Haines. (Hat tip to brainmates for finding it)
Steven’s pdf includes 17 golden rules for achieving product management success(no, we won’t do 17 articles on each of them). Many of them are relevant [...]

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.

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.

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.

One of the ten big rules of writing a good MRD is writing unambiguous requirements. Ambiguity is a function of communication. The writing can be generically ambiguous, or ambiguous to the writer. A requirement could be precise in intent, but ambiguous in interpretation by the reader. Understanding our audience is as important as precision in language. We write unambiguous requirements because misinterpretation of requirements is the source of 40% of all bugs in delivered software.

Welcome Dr. Franke’s students in Analysis, Modeling and Design MCIS6310! Thanks again for inviting me to present to your class on requirements gathering and requirements management.
The presentation is available for download. You can get both the slides and the notes pages. The notes pages include additional content and links to articles for [...]