10 Types of Requirements Process?

There is an old joke that runs as follows.

First Computer Scientist:: There are 10 types of people in the world.
Second Computer Scientist:: Oh? And what are they?
First Computer Scientist:: Those who believe there are 10 types of people in the world, and those who don't.

I hope you spotted that "10" is 2 in binary, the base 2 number system, convenient for computer scientists reasoning about computers made of on/off switches, but less good for ordinary folks.

Be that as it may, there are plenty of people who like to divide the world into 2, I mean 10 binary, categories.

"There are 2 types of requirements process, Mr 'Nippy' Agile (bantam-weight) here in the left corner."
(Cheers and boos echo around the ringside seats.)

"And Mr 'Finish the Job' Requirements Engineering" (super-heavyweight) over here in the right-hand corner."
(Muffled chorus of "yeah, right" and "get 'im, Finish" from the traditional side of the ring.)

The super-heavyweight versus bantam match is billed as a fight to the finish between precisely 2, or do I mean 10, extremely unequal contestants. But who exactly is in the ring, and (here our eyes seem oddly defocused, perhaps we have had too many drinks in the ringside bar) how many people are hovering around in there?

I have a question for you. Is your project using a pure 'Finish the Job' heavyweight RE process? No? All right then, you must I presume be using a pure 'Nippy' bantam-weight Agile process? You're not? How can that be? We only have 2 contestants here in the ring!

Well, clearly there's something wrong here. Every project you and I have seen has been somewhere along a spectrum between these extremes, hasn't it.

There are enormous projects with teams of safety analysts working for years to prevent catastrophic failures.
There are one-person projects with hardly a page of specifications or user manuals.
There are projects that start out to do the job swiftly with Agile rushes, but that gradually become embroiled in complexity and find they have to document things a little more traditionally.
There are large old slow projects that experiment surprisingly nimbly with Rapid Prototyping and Workshops, discovering they can cut through a lot of the usual documentation by annotating prototypes and working from lists of Issues and Actions.
And ... well, the list is endless.

Perhaps "10 Types of Requirements Process" means "ten" after all. At least, it means "more than two", "quite a few", "I haven't got a complete classification of all possible processes to hand just now".

For the real problem when people make claims like "There are 2 types of ..." is that they never agree what the 2 contestants actually are. It isn't a Final Battle between Agile and RE. It's an inability to see that our personal favourite ways of dividing the world into 2 halves are all different, because we've had different experiences. Projects too, are all different.

Perhaps on this project, requirements will work well using Scenarios.
On that project, a careful Goal Analysis will work wonders.
Over here, User Interface Prototyping will get us most of the way.
In this corner, we can copy the list of Applicable Standards and Non-Functional Requirements they used on last year's project.
This one depends mainly on Market Research and User Acceptability.
And this one is interesting, we need to experiment with new materials to Evaluate Technical Feasibility of different options.

Why should there be exactly 2 or 10 ways of Discovering Requirements? Maybe there are 1000 ways!

Maybe (if we knew enough) we could draw a unique pattern for every project. Maybe one project's pattern looks like this:

Requirement Elements Discovery Contexts	Stakeholders	Goals	Context	Scenarios	Qualities and Constraints	Rationale and Assumptions	Definitions	Measurements	Priorities
From Individuals
From Groups
From Things
Trade-Offs

Maybe your project would look different.

Home Page

Books you may like: