Software development in the real world: Requirements

by admin on October 11, 2007

So I picked up yet another book on software development and started reading. I wasn't able to finish it because it's giving me such a headache. Every few pages I get the irresistible urge to slap my forehead. At this rate, I'm going to get a concussion by chapter three.

Anyways, this guy goes on about requirements: How not having proper requirements causes projects to be over budget and behind schedule, how feature creep leads to unmanageable project schedule and demoralized developers, yadda, yadda, yadda. No, really?

And his prescription is that somebody write out the requirements and get all the stakeholders to sign off on them. Of course, there is not just one kind of requirement - noooooo! - there are many kind of requirements. As well as user requirements, there are business requirements and design requirement and thingajig requirements and .... I don't know, but lots of lots of funky requirements and gosh, if the project manager gets all the requirements written up and signed off by all the stakeholders, then hallelujah, this will be the ONE project that will finish on-time and on-budget. If only those stupid project managers could write up a good set of requirement documents....thump!

Sorry, that was my head hitting the desk. I think I lost consciousness for a few seconds.

Okay, let's try to refute this viewpoint which seems to be conventional wisdom with the one exception where iron-clad written requirements are the rule: Embedded systems. Basically, it's really hard to change a chip after it's been designed. Duh.

For pretty much all other software development work, it's a good idea to write down a set of preliminary requirements. And then print them out. But print them out on very soft paper that can be used in the smallest room of the house. Because in a very short period of time, that's the only room where that piece of paper is going to be useful.

There are two main reasons why, one obvious & one subtle. I'll start with the obvious: Let's pretend you are the customer. You have signed a contract with a software development house to build a nifty program that does something. You have agreed to pay money. In most cases, you are paying a lot of money. You have put your signature on a piece of paper for something that doesn't exist in the present. You are also painfully aware that when this piece of software is created, if it's does not meet the expectations of your stakeholders, they are going to let you know about it. And how times does a software release meet 100% of the customer's expectations?

Now, after signing a piece of paper for what many in your organization consider an obscene amount of money, a certain period of time elapses and you get another piece of paper to read, with a title stating it's a design/user case/business/whatever requirements document. You read through the document. It looks okay. There's a space for your signature. Maybe you sign it. Maybe you send back an e-mail saying you signed a piece of paper for umpteenth millions of dollars, and that's the only piece of paper need to sign, ever. But let's pretend you sign off on the requirements doc. Does this mean that you, the customer, have given up the right to ever contact, communicate or nag the development team with new features and/or requirements?

No. Never. Ever. There is no customer that has ever existed since the beginning of time that will not continually pester the development for new features right up to the moment of release and after. Get. Used. To. It.

So the lesson for any project manager is not spend too much time on drafting requirement docs. Sure, bang them out quickly, and I mean bang them out, but if, miracles of miracles, the customer sends back an okay and a signed-off document, don't even think your job is finished. The fun has just started.

This brings up my second point about falling into the documenting-requirements trap: getting all the requirements is super-hard. In most cases, it's impossible. Not even the customer, and the customer of the customer, can give you 100% of the requirements.

Look, it's like going to Julia Roberts fan club and saying: "We want to make a love story with Julia and Brad Pitt. They fall in love, they fight & break-up, and then they make up and fall in love again. At the end of the movie, everybody in the audience because the movie was so wonderful. Here is the script of the movie. Can you assure us that after seeing this movie, you'll reach for your hankie?"

Let me recount an example from the real world (I have changed some of the details to protect the innocent): One of Creo's customer had some printing technology that was running with a software suite developed in the early 1990's. Creo has some pre-press software developed about a decade later that is vastly superior. However, there were some unique features that were needed to be developed and added to Creo's software suite.

Project management for the customer was being coordinated out of head office in mid-US whereas the printing technology was based at plant site near the West Coast. I flew down to the plant to show off Creo's software suite and capture requirements. Did the presentation, flew back to Vancouver. A couple of weeks later, we get the diplomatic message from head office that perhaps all the requirements have not been captured. So I fly down again. I also arrange to have Creo's software suite loaded on a server and shipped to the plant site as a loaner. This time, during the presentation, they have their super-user, their system administrator on hand. I am lucky that the customer is smart enough to get their users out to the presentation to critique the suite. The super-user goes deep on me. That means she drills down many levels to some really obscure (to me) but important (for them) business requirement that is not in our software suite. I promised to follow up on those features with some of Creo's SMEs (subject matter experts) when I get back to the office.

Meanwhile, the server with Creo's software arrives on-site with a local field rep to do install and preliminary training. I also arrange for a trainer to follow up with an on-site visit to the customer a week later. I pre-brief the trainer to watch & report for any new requirements. Six weeks later, I send another trainer. About five months have passed since my first visit to the customer suite. Finally, the super-user is able to articulate the requirements that the plant needs to the Creo representative who is also a SME in that particular sub-topic. So we get the requirements captured and we pass them on to the development team and we get the message back that none of the requirements are impossible to fulfill, it will take about three months to roll into the next upgrade. End of story.

Now, note that in this case study:
1. The customer was sophisticated, understanding that we needed to have the super-user spend lots of time playing with our software so she could discover what was missing.
2. We had lots of time. Getting the proper requirements took five months. Coding the requirements took two weeks (the administrative load of rolling new upgrades into the software suite accounted for the other 2.5 months).
3. This was a modification of a pre-existing software suite. We were not presenting the customer with a "blank piece of paper."
4. The business was worth enough to send a loaner server with the software to the plant AND have a total of five separate visits to the plant (two trips by the project manager, one by a local representative, and two by trainers).

In conclusion, the point of this essay is that getting requirements in the real world is not so much a point of documentation, but an iterative process with the customer that goes on through the life-cycle of the development process (and beyond).
I'm gonna try to finish the book I'm reading, if only to present myself to future employers as fount of (conventional) wisdom. But really, if the woods are full of project managers who think they are home-free once they document the requirements of a project at the beginning of the development cycle, then it's no wonder that a lot of them get shredded after a few years in the biz.

{ 2 comments }

Zak Khan January 5, 2010 at 8:12 am

Enjoyed your post. I am close to graduating and just wanted to ask you what documentation is typically critical to software project. We have covered everything in sample and senior design projects from requirements: SRS, design doc, PMP etc.

admin January 5, 2010 at 8:21 am

I would say the most important document is the business plan, the one doc that the “engineers” never get to see. Second is the budget.
Too often during a reasonably long development period, the business plan needs to be updated or even becomes obsolete. When that happens, the money men (executive sponsors) start screwing around with requirements.
It does help to know why and when those guys start messing with your head.
Secondly, it’s amazing how many project managers can’t manage or are ignorant of a budget.
PMP is nice to have but some of it is pie-in-the-sky. Like the executive charter? Come on, how are you supposed to hold a VP or even the CEO accountable. They are the boss(es). You don’t hold them accountable, you just gotta roll with it.

Comments on this entry are closed.