Today even Change has changed. Indeed we know today that everything changes constantly: the users needs change, the business drivers change, the company gets bought or sold, the delivery platforms change, the interface environment changes, the industry standards change, and the development processes change.

Thus the “software uncertainty principle” has been widely accepted as accurate. The SUP states that, because everything changes all the time, the “right specifications” are inherently unknowable at any given time. You can define and deliver a set of requirements that match the needs of some sample of your users for some period of time, but that’s about all that you can do. Like an electron in the electron cloud, you can’t point to a spot in requirements space and say “there it is”. Your requirements document is more like a curved surface in Requirements Space, where the Requirements Space is populated by all known or future requirements in your domain.

To complete the metaphor, you can even say that the very act of looking at requirements causes them to change. This is the requirements version of the “Observer Effect” seen in many fields, from quantum mechanics to retail shopping research. Merely reviewing a set of requirements causes the requirements to change.

This was pointed out by a QA manager during a recent lunchroom bull session – he noted that when he reads requirements, questions are raised in his mind. The process of resolving or answering these questions often causes the requirements developer to question her assumptions, and results in a change in requirements.

How then can a stable, useful system be specified and delivered in less than an infinity of time and manhours? Many times the effort to complete in my projects has climbed towards the infinite…