One source of requirements for a software system is business rules. Business rules are usually defined as rules and constraints that affect how a company achieves its goals. These rules are typically independent of the software system being designed or deployed.
But what about the collection of rules and constraints that are NOT independent of the software system being developed?
For example, suppose I’m automating my widget factory. I’ve got lots of equipment in my widget factory, and the software system that we’ll deploy is going to automated all of this equipment, as well as the movement of widgets through that equipment. Because the automation aspects of the software system are completely new, there are few (if any) business rules that describe the constraints of the automated system. The managers of the factory need to make important decisions about how they want the automation system to operate. For example, they might need to make a decision about when they’ll allow the automated system to shut down a piece of equipment without human intervention.
When I discuss this type of problem with customers, I typically describe it as a “policy” decision that they need to make. This type of decision is typically made by business managers rather than the technical subject matter experts who might describe the functionality of the system. Policy questions often answer “when” and “who” questions. They define “when” from a business management perspective we’ll allow (or desire) certain things to happen. They define “who” (in some cases a system, in some cases a person) is allowed (or supposed) to do certain things.
There are several good reasons for calling out policies separately from other requirements:
- Policies are often set by management. Management may not care about the operational details of a system that might be called out in a Software Requirements Specification, but they probably care very strongly about a specific list of operational policies.
- Because policies are set by management, subject matter experts have often internalized the policies to the extent that they don’t think about them. But during the requirements phase, we need to do a critical analysis of the entire system.
- Policies are subject to change, and often affect many aspects of the system. By calling out the policies separately, you can trace the affects of that policy to other requirements.
There are some formal systems that have good hooks for policies. In IDEF terminology, a policy would probably act as a “control” on a function. There is definitely room for more research in this area.
