What is the difference between a business rule and a business requirement? Does the difference matter? A business requirement is something that is multi-customer, and a business rule represents a single customer’s approach to meeting that requirement. Product managers and analysts care about both, but product managers emphasize requirements, and analysts focus more on rules.

How many people should be involved in requirements elicitation? A question from one of our readers via email.
Hi Scott, in the last months I faced the issue of managing the requirement elicitation phase in an Identity Management project. I have a very simple question. In your opinion how many people should do the [...]

Gathering requirements isn’t like asking kids what they want for their birthday. We aren’t giving our customers carte blanche, we are trying to identify the valuable requirements - things that solve problems and achieve value in a significant way.
Needs and Wants
Our customers usually know what they want. There’s a debate about if customers [...]

Some outside reading…

When a client asks for a capability or feature - is it a want or a need? How do we prioritize them?

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.

We all remember how to do it - both following and leading. Product Managers do not have corresponding authority for all of their areas of responsibility. We have to manage somehow, and what better way than follow the leader?

Twenty-One dysnfunctional definitions of things we encounter every day as part of the software development lifecycle. Check ‘em out and add to the list!