Stating how to achieve a result is normally taboo in requirements writing. The resounding “No” that causes systems personnel to cringe is when someone wants to dictate how to perform a task in business requirements. This temptation, to which multitudes fall prey, causes the undoing of a requirement. There are times when it’s absolutely necessary to state the how to of a requirement but, in general, business requirements should state what is desired, and not how to achieve the results.
Simply put, children can be our best teachers when it comes to writing requirements. They often declare what they want without concern for how to achieve the results. It echoes throughout stores, “Mommy, I want this,” or “Daddy, I want that.” Somehow, we never hear a child say things like, “you know, you can use the savings account, or the checking account, or your credit card to obtain this particular item.” Children don’t care how we get the bear or bubblegum; cash, credit, barter or trade makes no difference to them. Just get the toy, or in these days of electronics, the iPod, tablet, computer, computer game or the newest cell phone with apps.
The reason not to say how is that it confines developers/system personal to limited functionality within a limited spectrum while other methods are feasible and may yield faster results with added value and significant quality. Technology changes at a blinding rate; thus, what is known by business partners as ‘cutting edge’ can change within months.
I’ll close with a couple of examples:
1) Business partners wanted data displayed, but stated how by dictating the use of a familiar legacy system. Immediately, conflict and confusion arose, because the legacy systems were in transition and system personal were feeling obligated to either use legacy or develop an explanation of why the legacy systems were not part of the new system architecture. The project stalled and gave way to discussion of the legacy system verses new architecture and explaining the benefit of using the new architecture. In the end, the legacy system was shutdown. The discussions hampered progress and the time lost is a resource not regained.
2) One method of stating what to do without confining resources is to state, “The system shall,” and to explain what the system should perform. “The system” is a generic term that offers uninhibited functionality and liberates personnel in solution development.
