Stakeholders and Requirements

Use cases are a widespread adopted technique for recording requirements. One of the sections (in the Cockburn format) is named "Stakeholders and Interests", and it reports... stakeholders AND interests. ALWAYS use it. Forget a stakeholder and you'll miss his interests, and as you can guess this is NOT good.

Cockburn uses a candy machine as an example: you interact with a candy machine to get a candy, so you're the user. If the manufacturer did not hold into account the interests of the seller (make money out of selling you candies) the candy machine would not ask you any money, but would give you free candies. That would make you happy, but it would make the seller unhappy. It would be very expensive to recollect all the candy machines on the market, go back to design, build new machines and redistribute them, let alone all the free candies gone with the wind.

The same happens with software, and it is a worse phenomenon as it is much easier to forget a stakeholder.

I recently witnessed a situation in which the headquarter superimposed a software to other offices without taking into account the real needs of the final users (yes, it holds for both extremes) but oversimplifying the business model. That was not an act of power nor stupidity, it simply was what they thought was best - and they had their reasons. Unluckily now they're back to formula, and a meeting has been scheduled to gather more requirements that can satisfy these stakeholders. Everyone would have saved a lot of time, and a lot of money as well (as one of the latest activities was an almost pointless meeting with more than twenty managers).

The problem was magnified by the fact that the software was a tool to use in a change management process, namely the first step to computerization and standardization of workgroup activities, which is already noteworthy per se. And, as change management involves people, it is never easy nor simple, as people normally resist changes. This time the persons involved (that were stakeholders AND users) did not understand the message (one of the reasons for resistance) because it was not conveyed in their language, and that brings us to another consideration.

Eric Evans asserts that everyone involved in a project should speak the very same language (he calls it "Ubiquitous Language"), and that a great investment has to be done in discovering and defining it: it will definitely pay off. Do it. It is the language that drives development, understand the language and you'll understand the requirements, thus you'll deploy more suitable software.

So to summarize: do not forget any stakeholder AND find a common language.