REQUIREMENTS !

Why ? The more I think about it, the more "why" is the word when it comes to requirements gathering. The question "Why ?" has two different meanings: THE PAST : you ask questions to understand the cause, what has happened in the past. THE FUTURE : we ask questions to understand what the user will need in the future, what he wants to do.

Weeks ago I attended a course about requirements at a clients' premises, and spoke briefly as a "special guest" about my experiences in requirements gathering. The audience was all senior people, from 10 to 30 years experience. Which were my four cents ? 1. Be careful of the usual three pillars of chaos form the users: wrong facts, omissions and inconsistency, 2. Ask three times Why ? why ? and why ? (the first answer is never the right one), 3. The system needs 100, the users tells you he wants 90, you understand 80, you write 70 and the developer starts working on the 60 he understands, 4. There are things you do know and things you THINK you know but you don't, so be respectful of the "monkey" user, he always know the business better than you. Be humble.

I found in my library the "Mastering the Requirements Process" book , that some might know as the " Volere " book. After many years I still find it very useful. I don't think the good Robertsons invented anything really new, but I do believe that this book covers 90% of the "how to" solve requirements problems in software development.  And 90% is a lot ! The parts I appreciated more, this last time are: Chapter 12. Prototyping the Requirements  Working together to the prototype, can really take out the users' implicit knowledge, correct lapses and help in many other ways. Chapter 11. The Quality Gateway You could try put an analyst that doesn't work on the same project, to read the project's requirements and have him refuse: all incomplete or inconsistent entries, frills, etc. I think it can be a very powerful practice.

I am reading the beautiful book "More About Software Requirements: Thorny Issues and Practical Advice" by Karl E. Wiegers. I'd like to share with you two of the most important points of his "10 cosmic truth",  that to me are #6 and #9. #6 The requirements might be vague, but the product will be specific. I would say this is the usual point of "Natura abhorret a vacuo", that is here... each gap n requirements will be filled by some bad feature. #9 The customer is not always right, but the customer always has a point. Never underrate your key users

Something we should never forget: some people use the products, some OTHER people gathers requirement for those products. So, to gather requirements is as easy as... walking on water. When it's frozen .

In writing requirements, synonyms do not exist . An example is "tree" and "plant".  The two words seem similar, but they have different meanings. Tree:   "a usually tall plant that has a thick, wooden stem and many large branches" Plant:   "organism belonging to the vegetable kingdom" Please note also that tree can mean"a drawing that connects things with lines to show how they are related to each other", while plant suggests a "factory and its buildings and equipment".

We do like Don Estes' blogs: we always find something to learn.. This page is about Business Rules, but you will find many interesting concepts abut requirements. I think this two images are very important, too  

There are many steps between the real needs, the requirements you write, how the thing is made. * What the user really needs * What the user knows What the user thinks * What the user actually says to you What you hear What you understand What you memorize * What you write down What the developer will read * What the developer will understand etc.

At the end of it, the job of us "requirements gatherers" is to ask the right questions.  In my experience, the really big issues arise basically from three kinds of errors : - All the questions you forgot to ask, - Some questions that you asked, didn't get (or understand) the answers well, and were afraid of asking again (and again, and again, and again), - Some questions you asked in the wrong way (so the user was "forced" to give you an incorrect answer).

A few words about the different kind of systems, just so you know in which kind of trouble you are when you start gathering requirements :-) SIMPLE What it is: you can see clearly all the connections between cause and effect . How to handle it: it is usually easy. COMPLICATED What it is: there are cause - effect connections, but it's not easy to see them. There is never a unique solution. How to handle it: ask questions to the experts (if there is any). COMPLEX What it is: it is made of many pieces, and they are highly interconnected. The output is usually part of the system itself and influences it, so it's difficult even to ask yourself the right questions. How to handle it: test some small parts and see what it happens (someone calls it "dance with the system.") CHAOS What it is:  high uncertainty, no apparent cause and effect and ... when some rule seem to apply, it will probably change very rapidly. How to handle it: run away !

Aristotle's was often thinking which were the four causes of... anything: the material, formal, efficient, and final cause. To my own risk, I'll try to apply these causes, to the very limited scope of software requirements. Final cause:   to build a software that works well and is efficiently used by customers. Efficient cause: it's us, we want build software for our customers. Material cause:  the pieces of paper we write requirements on. Formal cause: well. I still have to think about this one. Aristotle used the word aition, "cause". He meant an explanation that accounts for something: "x is the aition of y" means "x explains y".

The word Requirement comes from the latin word Requisitum , that comes from requirĕre  «to demand, to require, to call for» and quaerĕre  «to ask, to strive for, to require». Never forget that asking a lot of questions is one of the key in understaning the real needs of your customers.

In my experience, many problems arising from the little care in requirements gathering are mainly due to these five factors: Pre-judgments: we believe we know how to do the right thing before we even realize what we have to do, We do like to "settle" things "later", End users often do not know exactly what they want, or express themselves in their own way and often different users have conflicting requirements, The requirements now are constantly changing: as soon as we catch some, some other requirement has already changed, Often there are organizational or "political" factors involved (ie. we listen more to the requirements of a manager who will never use the system rather than the requirement of the user who will use it 10 times a day).