Requirements "gathering"

This makes it sound as if requirements are like mushrooms in the forest - you take a small basket, go to some secret place and pick all the things that you hope are edible, bring them home, cook them, eat them and, you hope, not die of food poisoning.

But there is a lot that has to go into the creation of a "proper" set of requirements. This post was inspired by some observations from Nigel Green (@taotwit), Alec Sharp (@alecsharp) with Color commentary from Anne Manes (@atmanes), Kristof Dierckxsens (@kdierc) and Doug Newdick (@dougnewdick). All those @ signs give the twitter ids of the people involved. Mine is @seabird20.

The riff all started with this, innocuous little tweet from Alec...

alecsharp @seabird20 My point - I see far too many cases where BAs gather literally 1000s of requirements but never synthesize them into a solution.

This of course led me to thinking - we have people who have analyst in their title, but almost always need to do some level of synthesis. Analysis and synthesis are often presented as opposites, so what gives? Here, the expertchoice team point out that you can't have a solutiion from analysis alone! Well that's kinda obvious, but still well put.

We typically associate analysis and design (with design taking the sysnthesis role in this counterpoint but it really isn't).

Now back to requirements, why do we have thousands of detailed requirements listed on powerpoints, in word docs, in Excel spreadsheets or wherever? Does it really help us to create so much "electronic concrete?"

The Agile movement has been very helpful in helping is do a much lighter weight job of handling the requirements, but I think that many agile practices also miss the boat.
So what matters?

First off, if I have my architect hat on (not necessarily EA hat), I am interested in those requirements that will make a difference to the structure of the functioning system. House analogy time, what it's going to be made of, and how it will be put together not the color of the curtains. And that plays right back into the excellent book, "How buildings learn" by Stewart Brand. Being concerned with the shearing forces, the forces of change.

(Aside):One golden rule, if stuff is going to change a lot don't spend inordinate time documenting it. A mocked up screen is a much quicker/cleaner artifact than a page of documentation. But that also misses the big point.

Counting things might help you to estimate them...Counting things doesn't tell you some of the essential things that will determine the structure. So let's think about some examples:

• You are getting together the "requirements" for an accounting system. Do the following make a difference to the structure? (and therefore have got to be right early)?
• It has to be multi-currency
• We have to support monetary amounts in the 10s of billions and 3 decimal places
• Connectivity to remote users is intermittent
• The users don't all speak the same language
• We have thousands of accounts to manage
• We want to consolidate data entry onto a single screen for account master data
• We need to be able to drill down from summary data into the details
• The system has to be available for transaction posting from 0600 until midnight
• ...

Of course these aren't real requirements. Some of them make a big difference to our lives. Multi-currency??? Well if you have ever had to convert a single currency system to a multi-currency you understand those implications. So yeah, pay attention. Size of numeric fields? Not so much. It's pretty much a nit. Pain to change in the formal documentation if you have carefully mocked up a screen layout showing (8,2) and you now need  (11,3), that's a lot of editing if you have specified every screenshot. So don't!

Drill down? Well that can be huge because it exposes a level of functinality different from just posting transactions.

Do all of the "requirements" appear at the same time? - Definitely not. Looking at a simple mock up showing postings doesn't show that I have multi-currency. We have to do analysis to discover the individual postings need - and then synthesis to put it back together fully in context.

Story telling is vital here - our analysts have to tell stories, they have to understand the business future state that is being proposed, they have to understand the constraints, and then put all the ingredients together at the right time. The switch for analysts to synthesists - and maybe have to all the time. However as Alec said in a tweet:

"alecsharp:  @taotwit @seabird20 I often say a better job title would be "Business Synthesist" but a) hard to say after pints and b) terrible acronym "

and another

"alecsharp @seabird20 @taotwit Without synthesis, you end up with reams and reams of disparate "context-free" requirements."

We are often led to incredibly detailed specifications by our large consulting brethren. They do this as means to managing their profitability not the customer's value. "Oh the risk is too great unless we gather these requirements in excruciating detail, so pay us to do that." And then, "Well YOU didn't tell us so now let's have a change order, so pay for that too."

Requirements might be gathered as discrete little pieces of functional capability,  But we need the cookery of synthesis to turn them into a non-toxic meal..