Requirements Management Please!
Table of contents for Developers everywhere are in terrible pain
- Requirements Management Please!
- Help Your People Escape Meeting Hell
- Project Change Management
Developers everywhere are in terrible pain. Why has it come to this? What can we do to make the world a better place for software developers and their children?
This sobering video clip was put together by devshop, and it has me fired up to help these poor souls! So, what can project managers do about these important issues? Let’s take a shot at them. This post is part of a series, addressing each of the pain points from the video.
Pain #1

We're 4 months in to a 5 month schedule and I just received the final requirements yesterday (and they've changed again!)
Requirements management please! This poor soul desperately needed a good business analyst or project manager a long time ago to flesh out the requirements in advance. Even in an iterative approach, the high-level requirements should be clear before any developer starts coding.
In my experience, project teams are very productive when you have a business analyst or project manager who knows enough about the actual work being done by the project team (usually used to do it themselves) that they can completely free up the team to work on tasks. Optimally, the team trusts the BA or PM to get the customer needs well defined, and elicit requirements in such a way that most of the normally unstated desires and ideas are captured.
Visuals are great when it comes to this. Personally, I have taken the approach of using visual tools like modified use case scenario diagrams, GUI mock-ups (for software) and simple functionality graphics to understand and capture user needs (usually creating these on the fly with a projector and the stakeholders in the room, this way you get instant feedback, check for understanding, etc.) I can use the output from this process (in addition to more formal documented requirements) to help the project team understand what is required, and often I am able to provide visual representations of suggestions for how things might work at a high level (high-level ERD’s for database structure, an outline for documents, etc.)
Furthermore, eliciting quality requirements is an art form, and is best done by a specialist. There are many schools of thoughts on gathering requirements, but the point is that you want someone who really cares about good requirements to be doing it. Many of the project team members are simply too busy with their own work to put much focus on this. I wrote about how good requirements ARE SORTA NUTS earlier, if you want to check it out.



Oct 1st, 2008 at 10:29 pm
I’ve linked to this article in my post on reviewing requirements in two easy steps.
Oct 1st, 2008 at 10:23 pm
I totally agree about a picture being worth a thousand words. In my mind, it makes things a lot easier to draw out a process or a relationship, for all parties involved.
I’ve noticed that it seems to be an exercise for most people to actually sit down and talk out how the requirements will perform within the system being developed. That’s where the good Analyst/PM comes in, as you allude to above.
I’ve linked to this article in my post on .