What I learned about requirements management

Here’s what I learned about requirements management after more than 15 years in the medical software industry.

Stop! Before you invest any time or money on requirements management, or any tools for that, you must solve these three problems. No, really! Don’t work on processes or tools until you fix these:

  • Give your dev team a very clear, straightforward, down to earth picture of what you’re trying to build. You should be able to explain it in an hour and write it in a few pages. This must come from marketing, but everyone in the team should be able to relay it faithfully enough.
  • Make sure everyone in the team actually believes this is happening! Check that they believe the project is going to take place, the time scale is sensible, it’s going to succeed, and that they personally are going to do it. If they don’t really believe some of that they’ll keep working, but won’t achieve success.
  • Make it so that your people care personally about the product and its quality. If you’re building a consumer app like a game or website, make sure they use it. If it’s a profesional tool make sure they empathise with the specialist who is going to use it, and what the specialist is trying to achieve in the world.

The good news is, once you solve these three issues thoroughly, requirements management will be very easy. All you need is descriptions and categories. A document with chapters will do. If your project is large or has a long future (and not otherwise) use a database that gives you at least one level of nesting, so you can group related specs (user interface, back end, service & support, etc) together. That’s all you need. Write specs as simple facts about what the product does.

Write simple, positive statements in the present tense. Each spec item should be maybe a paragraph or half a page, up to 2-3 pages in rare cases. Do not write specs for novices! Even if you do, and especially if you do, they’ll work like novices and give you correspondingly poor work. Write specs for people proficient in the domain. If your developers are actually domain novices, fix that. You need to train them by giving a series of seminars, immersion, or whatever is effective training. Do not train them or hand-hold them through spec!

For software projects you’ll need an issue tracker and a work tracker. These two must be the same tool. Otherwise it’s madness. If that tool is also your spec database, make sure that developers close their bugs or work items but don’t close your specs. You need the bugs and stories to go away never to come back. For your specs, the opposite.

When I say issue tracker, I mean the internal issue tracker used by the engineering team. That’s an engineering tool, and will routinely contain hundreds if not thousands of issues. You need another issue tracker, such as Salesforce, for your external, field reported or customer service issues. These must not be the same tool. You need real people to carry issues and resolutions, manually, from one to the other.

Now, there is one aspect of requirements management that’s hard to do, and all the systems I’ve seen so far either didn’t support it as a feature, or were complicated and horrible. The one difficult aspect of requirements management is:

Knowing what features exist in which version of the product.

That’s hard. Effective, simple requirement management tools, starting with plain old documents, are effective and simple when they describe “it”. The thing that you’re making. The product. As soon as you stop describing “it” and you start trying to describe that the feature appeared in version 3, but was reworked in 5 and eventually scrapped in 6 it gets really complicated and nobody wants to read it any more.

The best I can recommend is don’t try to track specs for multiple versions but branch, export etc. your specs so that the specs of old versions become mostly frozen and describe what “it” was at the time. Or, if you must keep the specs concurrent, make an “applies to” table that tells you whether the spec applies to each version or edition and accept that most cells will contain the value “unknown”.

2 thoughts on “What I learned about requirements management

  1. Hi Pavlos,

    Requirements management is getting the requirements from the client and then formulating these requirements into a project charter/project plan/etc… Explaining the tasks to your team happens after the requirements gathering part and is not really part of requirements management. See this article on requirements gathering in software projects. Hope you’ll have the chance to read it and maybe comment on it!

    • Well, let’s not get into a difference of terms. There are indeed two sides of managing requirements. There’s learning the requirements from the market (for which the one client is a relatively easy case) and there’s communicating the requirements and having them acted on effectively by the team. In this case I focus on the latter.

      One thing that’s vital though is that the requirements won’t be fixed during the project. Another way of saying this is the won’t be fully captured when the project starts. For any interesting software product, the act of building the solution makes the customers change their appreciation of requirements. Inevitably this happens during the project, so if you take a snapshot of requirements at the start it’ll be out of date.

      You have to converge to a product that is what customers will want when they get it, not what they seemed to want before your product existed.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s