Archive of Writing Articles

A rose by any other name…

When we’re learning how to write in high school and college, we’re taught that synonyms make our writing more exciting. In fact, not using synonyms can make our prose clumsy and awkward.

When it comes to requirements, the last thing you want to do is use synonyms. Except sometimes.

Separation of business rules from requirements is a good thing. Not because of semantic distinctions, but because it allows you to write better software, write it faster, and change it more easily. This article is a response to an excellent comment on our recent article about hidden business rules. Thanks for challenging the idea - it either eliminates it from discourse or makes it stronger, and we all benefit. Here’s an attempt to make it stronger.

Effective communication of requirements requires more than documentation and broadcasting. Effective communication requires interaction and collaboration. Alistair Cockburn addresses this in his analysis of project successes and modes of communication.

You knew it would happen eventually, the big ten rules of writing requirements has become the big twelve rules. Maybe scope creep isn’t such a bad thing after all. Writing style plays an important role in writing requirements too.

We talk about characteristics of good requirements, including completeness, correctness, and ambiguity. But how do we assure that our requirements are complete, correct, and unambiguous? Simple, Captain, with logic.

Pair programming is a bit of a foreign concept for many people in business. A few years ago, it was foreign to most programmers too. Pair programming is a powerful technique for software development because it allows two people to look at the same problem/solution from two different perspectives at the same time. Would that same approach work for business analysis?

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.

The Monty Python troupe helps us remember five (no, three sir!) things about software requirements. And now for something completely different…

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