Business Requirements

See UserRequirements and ClearRequirements.

The important thing about BusinessRequirements is that they exist (in some platonic sense) whether or not any IT system or user exists or is contemplated. There is a business requirement to pay employees even if there is no payroll system to pay them with. And people were withdrawing money from banks long before computers or ATMs were conceivable.

In general, we should acknowledge the primacy of business requirements. That is not to say that we are condemned to automate the manual systems of the past, only that there is a high probability that the manual system encapsulates some of the new system's requirements, and we ignore or overlook those requirements at our peril.

Questions to ask about an individual requirement appear in BusinessRequirementQuestions.

Well spoken, Alan. This statement needs to be integrated in to the larger discussion of requirements. I agree that it is incumbent upon us as developers to attempt the task of identifying and clarifying the requirements for any system, regardless of its technical capabilities (or shortcomings) or perceived applications.

One of the med sys instruments I worked on was never meant for direct patient treatment; it was meant to extract platelets from healthy donors to be infused into sick patients. However, the machine was later used to treat patients directly in a different configuration. The real requirement here was not the extraction of platelets, it was the treatment of patients. It was only after the requirements were analyzed more thoroughly that the box was used in a different, and more direct, manner than was originally intended. Too bad about the $10M spent on the intermediate step. Oh, well.