Requirements management in an agile world ?

In traditional (non-agile) development, requirements management was a discipline taken extremely seriously: requirements were dealt with in very formal ways, by requirements specialists who analyzed, allocated, versioned, froze and baselined them.  Oftentimes frozen requirements were part of the commercial contract between the supplier and consumer (a.k.a contracts driven development). When the requirements specialists finally were done with their elaborate work on requirements, they passed them over the fence downstream to the developers, whose job it then was to ensure that they implemented exactly what the requirements stated, no more, no less. Basically, the overall approach was to agree and freeze “the perfect” set of requirements before development was allowed to start. Any changes to requirements after they had been agreed upon was to be avoided at all costs, and if changes were necessary,then the contract had to be renegotiated.

Now, in an agile world, where change is constant and actively embraced, do we really need/want to continue dealing in this very formal way in our requirements management workflows, do we still need to version, baseline and freeze our requirements in a world embracing change – i.e. we don’t like to freeze things anymore –  where frequent customer interaction,  combined with short iterations and feature centric development is the norm ?   I don’t have the answer myself to this question, so I’m hoping that someone out there with strong opinions on this matter will chip in.

To elaborate a bit further, at a more abstract level about the need for versioning and baselining: why do we version and baseline artifacts in the first place…?  We are quite used since many decades to use tools to version and baseline our code, but why do we actually do that..? Couldn’t we just work in one track, all of us…?

Well, one reason for versioning artifacts (code or whatever)  is to enable parallel development: unless you somehow manage different versions of the same piece of functionality, you will run into trouble as soon as you have a team working in parallel on that same piece of functionality. So, to avoid stepping on each others toes, we need to version artifacts that we want to work on in parallel.  If we don’t do parallel development, we could perhaps manage without versioning, or could we ?

Another reason for versioning artifacts is to deal with and keep track of variants of the functionality. Lets say that we are building an application for two different platforms, let’s say Android and iPhone. Although we would want to keep as much as possible of the code base (and other artifacts) identical between the two platforms, chances are that we are forced to have separate implementations for some parts of the functinality. Let’s call this kind of versioning for variants.

The second kind of versions we can call revisions, i.e. generations along a timeline of an artifact. So, in the example above with Android and iPhone platforms, we’d probably have two variants for some piece of functionality, and within each of these variants there most likely are many revisions, representing the evolution of the functionality within each variant.

We also want to keep track of who made what changes and when and why for any artifacts, so we might call this need the “artifact history” dimension.  And finally, to release something to a customer, we need to record a configuration or a baseline, i.e. what elements in which versions went out to that particular customer.

So, there’s a lot of house keeping activities we are used to perform when it comes to keeping “metadata” about our various artifacts. But my question is: do we really need to continue performing all these activities when dealing with requirements in an agile, change embracing world, where we typically do not operate in a “development by frozen contracts” fashion ?

I see a difference between code (i.e. anything that executes) and other types of artifacts, e.g. requirements: code, in order to compile and run correctly, must be syntactically and semantically consistent. Other types of artifact though, e.g. requirements, do not have this formal requirement (sic!): for sure, requirements are better be logically consistent, i.e. not contradicting each other, but they don’t have to be syntactically perfect, nor are they subject to any formal processing such as code is when its compiled… So unless we somehow can execute and verify our requirements, e.g. to test their logical correctness, IMO we could be a bit more “sloppy” in the level of formalism when dealing with requirements.

So, the question is: do we still need to version and baseline our requirements, now that we are agile… ?


About swdevperestroika

High tech industry veteran, avid hacker reluctantly transformed to mgmt consultant.
This entry was posted in development, software and tagged , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s