Readings on how to communicate requirements to our developers?

December 13, 2004 8:46 AM

ChangingRolesAtWorkFilter: I am moving from a pure development role into more of an integration/product manager role. I need advice on things to read that will help me learn to write requirements documents. [more (requirements?) inside...]

We, as a company, have done a very poor job doing this in the past. Generally passing requirements to the dev staff consists of a short email from sales or client services with “We need a new X to do something important and we would like it yesterday” so dev builds X and it does something important and much more but when the client sees it we find that really it needed to do a small thing that is either completely different or could have been added to the product with a few small tweaks.

I know that this is typical for many technology companies and it was fine for the first few years here since we were a start-up but now it is a hindrance and it is time for us to grow up. My job will in part be changing the way we do things to make sure that we do not spend so much time spinning our wheels due to poor specs. We are an ASP and not a thick client app if that makes a difference.

It is going to be an interesting time because I am basically going to be trying to change the way that people work here and force them to actually plan things and think about what they really need and how important it really is and I am sure that there will be a lot of resistance at first.

With that said, I would love to hear about anything that you have read that will help me to create a requirements gathering process and then write coherent documents that clearly communicate the need to the dev team.

posted by GrumpyMonkey to technology (9 comments total)

Steve McConnell has written several books on these topics, and is a thought leader in the area. Rapid Development and The Software Project Survival Guide are probably most up your alley. Don't let the fact that Microsoft published them deter you!
posted by mkultra at 9:06 AM on December 13, 2004

I would also recommend The First 90 Days, which is not about product management but is an excellent guide to assuming a new role, particularly one in which you're going to be instigating change (which it sounds like you are).
posted by donovan at 9:23 AM on December 13, 2004

You could also take a look at what the IEEE has to say on software requirements specifications.
posted by Loser at 9:32 AM on December 13, 2004

"Practical software requirements" is a good book if you are looking to create a map of your system. Break it out into entities, relations, and events. If you are looking for a better template for your requirements, I suggest some kind of overview book. Most will have this.
posted by xammerboy at 9:57 AM on December 13, 2004

For wise, witty, eminently practical advice, I recommend joel on software website - in your case, starting with the archive , which includes four articles on "Painless Functional Specifications".
posted by WestCoaster at 11:49 AM on December 13, 2004

donovan.. you may want to check your link to The First 90 Days.
posted by Doohickie at 11:49 AM on December 13, 2004

Alistair Cockburn wrote the book to start with.
posted by normy at 12:00 PM on December 13, 2004

two points that don't answer your question, but which i wish i'd heard earlier in my career (i hope this is ok, it's off-topic but not, i hope, in a very bad way). apologies if it seems tupid or condescending. i just wish, as i'd said, someone had said these things to me:

- project management is very different to programming (i don't like it as much, but maybe i've been unlucky). try to understand as clearly as possible what your new responsibilities are, and then see what new powers you get to go with them. you need to make sure that you're not caught with responsibility for things you can't change (for example: what happens if you estimate that your team needs more time than your boss, or the client, will allow for?; what are you going to do when your use cases aren't up to scratch?)

- your big task is changing how people do things, which can be very hard. a particular tool or process might be a way of helping with that, but it might also be seen as a nuisance that is there to make paperwork rather than solve problems. my best boss ever (tm) would have tackled this problem by getting us all together and discussing what we saw as problems, and what we would like to do to improve things, with very light guidance (but a lot of supporting info ready as needed). in your case, you probably need "sales or client services" there, along with "developers". do they speak the same language?
posted by andrew cooke at 1:07 PM on December 13, 2004

This is all great advice - thank you.

I am not sure where we went wrong but it seems like in the last 6-12 months things have just started slipping into some strange hell where communication is failing and the sense of camaraderie has been replaced by an angry undercurrent and division into fiefdoms.

There is a variety of causes that span the gamut from a lack of clear direction from the top, a director of software who thinks that everyone is trying to blame things on him, an influx of clients who have ideas of where we should go as a company, frustrated developers who are working in technology that is at least 2 generations out of date etc...

It will also be particularly interesting because
a: we are a small company
b: most of us have worked together for a long time
c: I have been with the company longer than anyone but my manager and have a lot of leeway with what and how I work.

I have many years and a lot of sweat tied up in this so I am really hoping that this new role will end up a good thing and that I will be able to get people to change how they do things and perhaps learn to "speak the same language" again.
Man, I sound like I have been listening to Oprah or something...

Anyway, thanks again for the advice.
posted by GrumpyMonkey at 1:39 PM on December 13, 2004