The usefulness of requirements writing

I don’t know the actual history of requirements writing and would be really glad if someone shared it with me but this I do know – many organizations with an internal technology team live and die by the presence/absence of requirements.  I know that there was a time in my career that I campaigned for them and spent long hours working on “making them better”.  In the interviews I participate in, requirements writing is always a topic that surfaces.  Currently, there is so much discussion/argument/debate around these artifacts in many environments such that the success or failure of solutions delivery is usually tied to requirements.  I beg to differ.

The unfortunate thing about this is that the individuals pushing this argument in the organization are generally technical people who should know better but we don’t.  I don’t think this is intentional but the consequences of such thinking run deep.  It impacts the working environment by creating silos and low trust.  We are stuck in the methods of the past and still feel they are required in the dynamic and ever-changing environments we inhabit today.  We forget that requirements are just a response to a need – a business gap that needs to be “filled”.  We feel that better “requirement writing” will solve the business situation.  I beg to differ.

Traditionally, these documents are some form of functional design intended to communicate to developers what needs to be developed.  We imagine that this document should simply be handed off to the developers and they’ll come back with a product.  In theory, this sounds good but in practice, it rarely is the case as we find that there is generally an impedance that needs to be worked through.  There are many questions that need to be asked and answered.  There are dependencies that exist that the requirements writer is not aware of.  In fact, review of the requirements generally turns into a whole new requirements gathering exercise.  It’s also important to realize the requirement writers are generally not the end users who are going to use the product so by the time the information actually reaches the developers, its subject to Chinese whispers.  There is so much obvious waste in this approach, I’m still surprised that it is still heavily touted.

A different approach is to have the people (business analysts) who traditionally write requirements focus on identifying gaps in the organization.  In my opinion, this is a full time job that is very often neglected because more important things (such as requirements writing) are occupying their time.  Once those gaps have been identified, business analysts facilitate a forum that allows the end users to share with the product team the gaps (requirements) that can be addressed by technology.  The team of end users, business analysts and product developers collaboratively determine the features (and estimates if need be)  that address the business gap.  The product team should have individuals capable of both capturing this information and identifying means to verify that the capabilities have been delivered.

I realize there are situations where the product team does not have access to the end users, but that should be the exception.

Doing the wrong thing righter doesn’t address anything.  We need to fundamentally change the way we work.

Advertisements

About Ebenezer

culture hack. contrarian. change artiste. speaker. writer. silo-connector. entrepreneur. totally human. ff at your own risk. :-)
This entry was posted in Software Development and tagged , , , . Bookmark the permalink.

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s