A note to software developers: By managing requirements you can have more fun! Don’t believe me?

Indeed, we’re sure you don’t like being bothered with all that requirements “stuff” because it hinders you from spending time on tasks that allow you to be creative, such as design and coding. Consider what typically happens: Requirements are documented, sent out for review, nasty discussions occur as a result, comments are integrated, requirements are published… and then the cycle starts all over again.

And in the end? Nobody even bothers to look at the requirements anyway because, well, they’re probably out of date. Everyone will probably just look at the resulting application and comment on it anyway. So, why even bother?

Think about it from an even wider perspective: Nobody likes to produce something that is considered an intermediate product and is never referenced by anyone. Remember how it felt in school when we were forced to do homework, and in the end the teacher didn’t even bother to look at it? That’s right — doing work nobody is interested in is just plain boring!

Now let’s do a thought experiment and assume you’re developing a product and decide not to do any requirements management. Your team’s brilliant anyway, so surely they’re going to get everything right, right? Let’s further assume we’re creating a product for a global market, need to ship with documentation, and be prepared to support the product once it’s released.

One day, the documentation folks will begin to stop by your desk and ask for the latest design of the product. Since there aren’t any requirements recorded, all they can do in order to get their job done is to ask you about the latest stuff, regularly. Let’s assume you spend an hour per week with these folks.

But the support guys stop by as well since they need to create training materials for the product, and need to prepare for the issue resolution process. There goes another hour each week.

But what’s really driving you nuts are those testers, who are expected to get the product tested shortly after functionality has been completed. To accomplish this, they’re going to need to create and execute tests while the product’s being developed. And not only do they stop by regularly to ask about details in the design, they also need your help with interpreting the test results. Often it’s not clear whether the test result is a bug or is just irrelevant as, without requirements, it’s not clear how the product is intended to be used.

At this point you’re going batty. Your fun coding time is evaporating as all these people regularly stop by your desk, asking these nasty, time-consuming questions. Eventually, you’ll probably begin to wonder if it would have been a good idea to invest a little bit of time up front documenting your requirements. If you had, you could then point those guys to up-to-date information about the product… and spend more time having fun.

As an industry we’ve known about the advantages of documenting and managing software requirements for quite some time, but regardless, a lot of people don’t realize how painful it is to not do this. Perhaps it’s because we don’t capitalize on this work enough.

Usually, requirements are managed in one tool, documentation in another, and tests in a third. In recent years, however, we’ve seen more tools coming to the market which have a shared repository for all those artifacts. Collectively, these packages are referred to as application lifecycle management tools. In ALM tools, various artifacts of the development process get visibly connected, and requirements are directly connected to tests. This provides feedback to the requirements analysts in a very direct way and, suddenly, their work gets used because they also provide significant value to testers. Of course there will be feedback loops as deficiencies get detected, but they get detected much earlier during the test design phase, which costs less in rework later (i.e., giving you more coding time to spend working on the next, cooler release). As this requirements repository gets used by more and more people, its image will get better and better. Eventually, your team will trust in the information stored there, and won’t stop by so often at your desk.

And as a result, you’ll be allowed to experience more fun.

And perhaps, one day, you’ll have fun with requirements management itself… but we’ll save that for another post.

Gerald