Information Systems and Service Design (Fall 2011) UC Berkeley, School of Information

When a problem or opportunity is defined and scoped, any constraints on possible solutions or goals that must be satisfied can be viewed as requirements - “conditions that must be met for the solution to be acceptable to the stakeholders." Requirements do not dictate how the solution is to be achieved; that is the responsibility of design. Requirements can be quantitative or qualitative, but in all cases should be verifiable. Specifying requirements using business rules or using "simplified technical English" makes them easier to validate and communicate. Going a step further, when requirements can be captured as “decision rules” or “business rules” we can implement and enforce some classes of them using a "rules engine" or "decision service" rather than scattering them into application code.