Tag Archives: requirements management

Requirements Management Please!

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.