Elusive software requirements

Those who have been following know that I moved to a new position about a month ago. I took over as a development lead for a project that was "just about ready" to go live. In speaking with the guys in charge, there was some concern because it seemed like some apparently simple changes where causing HUGE pushback from the development team. In addition, the application actually didn't even work by ANY measure... oh yeah, everybody could get a little tiny piece of it to work on their machine, but there's a whole other story about how we couldn't even actually build the project without having first built the project....

So I've spent an enormous amount of time (weeks) navigating the murky waters of "requirements" looking for the iceberg that caused this hole in our development boat. At first, I was told thing like "well, the requirements keep changing", and "well, things are kinda fluid, we just gotta be flexible". In addition, I had to listen to daily bitch sessions from the developers about things "always changing and nobody knows what the hell we're supposed to be doing".

Me being the FNG http://en.wiktionary.org/wiki/FNG I jumped up and said "We're not doing ANYTHING that isn't spelled out in the requirements!" This had the effect of calming the development team down, but we where still seemed to have a problem of the software doing unexpected things. In addition, it was taking a god awful amount of time to do even the most seemingly simple thing.

So, I sat down with a BA, a manager (or two), and a couple of external consultants (sounds like the intro to a bad techhie joke) and started to talk about some of our problems... "what are we supposed to do here?" and "what about over here?". At this point I started getting a variety of answers... one person would say "just show a drop-down", another person said "oh, that's not really important", another person said "I wrote down EXACTLY what was supposed to happen about six months ago, it's spelled out in the requirements doc". About 5 times during this conversation, the director of IT's head turned beet red and I could actually hear the blood pounding in HIS ears.

This scenario played out repeatedly over the next couple of hours essentially ending with a VERY uncomfortable feeling on my part. The next morning a largish binder (80+pages) showed up on my desk with a manager + BA handing it to me saying "here are the requirements, make sure everyone understands them" (I'm paraphrasing, they really were much more polite).

Frankly, I was FUMING internally at this point. And then my inner a-hole came out and a fairly unfortunate conversation occurred. Luckily, at that point a number of largish prod support emergencies happened and I was thankfully whisked out of the conversation.

After calming down and driving around in my rental car for 45 minutes at lunch (don't ask, yet another story) I resolved to sit down and read all the requirements cover to cover.

My first discovery was that the requirements where VERY detailed, I mean, they where SUPER detailed. I instantly lapsed into my middle school coma of too much information. In addition, once I discovered things that somehow made sense to me, they seemed to be subtly different than my understanding of what was supposed to happen.

Worse yet, I discovered that about 70+% of the work we where doing was nowhere outlined in the requirements... I'm now trying to find the secret decoder ring that explain WHY we're doing all this work for seemingly simple requirements. The nonfunctional requirements were evidently stored in someone's head and nobody had accounted for them in any of the time-lines.

Well, the good news is that I've got plenty of opportunities to make things better, the bad news is that we blew our date by a huge factor... More to follow and I wade through the mists of requirementland.

We have a meeting about some new functionality tomorrow that ought to be REALLY entertaining.

Comments

Unknown said…
Two gold stars for this post my friend.

I think you'll remember the feeling you had when the requirements binder was given to you. It will be a motivating factor for decisions to come.

Popular posts from this blog

Push versus pull deployment models

the myth of asynchronous JDBC

Installing virtualbox guest additions on Centos 7 minimal image