Hunting for Requirements

Gathering requirements is not that simple. It can be a bit of a wild hunt actually! As I mentioned in a previous post, the challenge does not lay in detailing the perceived solution, but in uncovering the true problem... That said, your requirements should always enable your team to create software that is more than satisfactory to the stakeholders.

So here's how I proceed... I meet my stakeholders and hunt for these three layers of requirements:

1. Satisfiers
These are the requirements the stakeholders explicitly ask for. These are often problems that will need to be avoided in the future. These requirements will cause your stakeholders to reject the solution if they aren’t specifically addressed. The more of these requirements are addressed in the new system, the better. When some of them are just not possible, make sure you explain why.

2. Dissatisfiers
These are the requirements the stakeholders 'forget' to mention, the implicit requirements. These are considered too obvious to mention. These requirements usually mirror functionality in existing systems and stakeholders naturally want them in the new system (of course they do!). The absence of implicit requirements will lead to disappointment and dissatisfaction, so make sure you identify them.

3. Delighters
These are requirements that stakeholders are completely unaware of. They are not necessarily familiar with the newest technologies, standards or methods, so they just don't know how you can do certain things, what is even possible. Addressing these requirements will add a 'wow factor' to the new system. And that's definitely something you want since it will have a tremendous impact on the stakeholder's overall satisfaction.