Verbal Communication

Humans used to have such a marvelous oral tradition; myths and history were passed orally from one generation to the next. Until an Athenian ruler started writing them down Homer's The Iliad so that it would not be forgotten, stories like Homer's were told, not read. Our memories must have been a lot better back then and must have started to fade sometime in the 1970s because by then we could no longer remember even short statements like "The system shall prompt the user for a login name and password". So, we started writing them down.

And that's where we started to go wrong.

This is an excerpt from Mike Cohn's "User Stories Applied", which I encourage you to read.

What's wrong with written requirements? Actually they have advantages as well (traceability is an example), but they are based on a flawed assumption: they capture every detail of what must be developed. This is practically impossible, with the only exception of very trivial systems. Nevertheless, we do want to write something down, at least to be sure not to forget important things. So what do we have to write down?

User stories are very useful for many reasons, but one of them is that they favour high-bandwith face-to-face communication; actually stories are reminders for conversation. This calls for (I'd like to say force but it would be too optimistic) the customer and the team to interact frequently, thus leading to a product that is just what the customer wants instead of - at best - what is captured on a ton of paper that nobody reads.

This might not be true for every domain; some specific software would probabily require a very complete and detailed document, but this does not apply to anything I've had to develop so far (but I wouldn't be able to say anything about software for pacemakers). Yet, I think any written documentation is not complete unless it also describes how to test a feature. That is definitely what I'd like to have, rather than a series of "the system shall...". Oh forgive me, it is "the System shall...", capital S, we don't want to underestimate the beauty and the power of our product (which by the way does not yet exist if not in our dreams of glory).

Is time spent on requirements completely wasted, then? I think it is not. Requirements do not come out of thin air, so at least all the conversations held in requirements workshops can help the developers (but most of all the customers) to clarify what the business rules and information flows really are and what the system will really need to do in order to support them.

And this only emerges through verbal communication.

Again on detailed requirements

Some time ago I wrote about how detailed written requirements are just, well, detailed written requirements. They don't add value for our customers, at least not direct value, they can just help them to build or enforce their vision about a system. And at a high price.

Clashing with reality, sometimes you just have to produce these huge documents even if you know that no one will ever read them, and you'll sign contracts that say that you'll produce exactly what is "so clearly" written.

Pity that when you actually try to read through these 600 pages and understand what's expected from your team, most of the times you find out that you have to start out again, wasting your time and your customer money; I like very much this example borrowed from Mike Cohn, who refers to the following requirements written in IEEE style:

1. the product shall have a gasoline-powered engine
2. the product shall have four wheels (mmm I see where we're going)
3. the product shall have a rubber tyre mounted to each wheel (yes, yes)
4. the product shall have a steering wheel (definitely! we're on it!)
5. the product shall have a steel body (of course it should)

At this point it should be clear to everybody we're talking about a car. But... would not be easier if we just had the customer at hand in case of need and a simple card with the user story "the customer needs a comfortable product with which it's fast and easy to mow the lawn"? Yes, this customer just wanted a riding lawnmower. What happens if you find it out only AFTER you've built a car? Do you think it is always possibile to attach a rotary blade under a Cadillac?

Get this one. The same holds true for software systems. So you'd better consider it before you embark on the quest.

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.

Detailed requirements: a never ending story

In an article about selling your IT Projects to Executives the author quotes a former managing director and global CIO:

User requirements, no matter what the development style, must be rigorously developed, detailed and documented.

While I think that it is perfectly true for big companies like Credit Suisse First Boston, where he worked for 18 years, I still am persuaded that it doesn't apply to every situation, though I hope my bank gives very detailed requirements to developers and that they have a very deep QA process in act (I also read from Symantec that banks spend about 10% of their IT budget in security).

But... where's the point of having 600 sheets of paper and 0 lines of code? Surely the requirements eliciting process can provide customers with real breakthroughs and give them a much clearer view of their processes and needs, but it all seems to end with that...

First draft requirements: lessons learned

I recently talked to a friend of mine that had just terminated a preliminary collection of requirements for a couple of new customers; I found his insights very interesting for a bunch of reasons, and I'd like to report some lessons he learned and was so kind to share. Having seen the result of his efforts I'd like to add a couple of thoughts of my own.

• Having just a person conducting the interviews and another one working on the resulting minutes is not a good idea (we're not talking about polishing them up), as it is very time consuming. Better to spread the work among two persons and interact frequently between sessions: even if it might seem more expensive, as it doubles the resources involved, it greatly reduces further analysis and review time and leads to better results (likewise pair programming). This practice also reduces bottlenecks.
  
• A versioning system is very useful. Use it.
• Time spent on "aesthetics", like formatting, logos and such, would be better spent at the pub. Ops, I mean concentrating on the core stuff. A good look should not be important to you. If you really need it (you normally do when you approach a new prospective customer) leave it for someone else when the process is (almost) terminated. Better yet, separate presentation from content.
  
• Don't forget nonfunctional requirements. I am always astonished when I see that nobody cares (or remembers) about security, scalability, reliability, configurability, performance, and so on. I can understand a customer might not think of maintenability at first, but how is it possibile that nobody ever says things like "the system should support no less than 2000 concurrent users" or "the system should adapt to many different situations"?
• Inspect and adapt. Rinse and repeat.
  

Note that the purpose of these interviews was the production of a first draft for a possible collaboration, not working software; nevertheless the same rules hold true also in production time.