The death of "shall" and "will"?

"Shall" and "will" have been my guys for a long time! From the moment I took Requirements 101 I learned a few things:

• The buyer "will" do this and that (for the seller) Seller = developer; or contractor if selling to a project office
• The seller "shall" do this and that (for the buyer) Buyer = customer; or project office if buying from a contractor
• Never put two required outcomes in the same statement; in other words, no compound requirements that confuse "or" and "and".

But  the agilists are push aside "shall" and "will" as relics of mid-20th century project doctrine. Now, we have "conversations":

"As a {role}, I want {some capability, feature, functionality, or performance capability/capacity} so that {something can be accomplished}"

And, the conversation, often written informally on a card posted on a wall in the war room is just the beginning. From the card ensues the real conversation, ultimately documented by developers in design level test scripts and by business analysts in business scenario scripts. The former are used for verification, and the latter for validation (The ole V & V of the "V" model).

The little card on the war room wall all but disappears; it not retained or maintained. What's the memorial to requirements? Test scripts.

Is this a bad thing? Actually, no. On large scale projects, like an ERP installation, I've found that the "shall" and "will" business is less effective than business scripts supported by process diagrams and workflow tables.

So, perhaps the time has come to retire "shall" and "will" from a whole class of projects.

  Bookmark this on Delicious