The Problem of Requirements

Ask software developers what they know to be true about the requirements they get from users. They will often say:

• Requirements are incomplete.

• Requirements are usually wrong.

• Requirements (and users) are misleading.

• Requirements do not tell the whole story.

One thing you will never hear is, “not only were our requirements complete, clear, and understandable, but they laid out all of the functionality we were going to need for the next five years!”

In my thirty years of experience writing software, the main thing I have learned about requirements is that …

Requirements always change.

I have also learned that most developers think this is a bad thing. But few of them write their code to handle changing requirements well.

Requirements change for a very simple set of reasons:

• The users' view of their needs change as a result of their discussions with developers and from seeing new possibilities for the software.

• The developers' view of the users' problem domain changes as they develop software to automate it and thus become more familiar with it.

• The environment in which the software is being developed changes. (Who anticipated, five years ago, Web development as it is today?)

This does not mean you and I can give up on gathering good requirements. It does mean that we must write our code to accommodate change. It also means we should stop beating ourselves up (or our customers, for that matter) for things that will naturally occur.