At the beginning of a new project, functional requirements (a specification between a system’s inputs and outputs) are often expressed orally or in long-form writing. Although this is a good first step, more needs to be done in order to get the requirements to a place where they are expressed in clear, complete, and unambiguous terms. The practice of requirements analysis provides many different work products that achieve this aim, including context data flow diagrams, functional decompositions, entity relationship diagrams, and more.
One very common way of expressing functional requirements for a system is with flowcharts. Flowcharts express a sequence of tasks, events, and decisions to reach a desired endpoint. For example, say a movie theater wants to bestow a Frequent Patron status on its regular patrons. To determine whether a patron qualifies for that status, the movie theater may want to go through the following decision process, like so:
So, if a patron has attended 15 shows the past year, and has also spent over $250, then the person is a Frequent Patron. However, the decision diamonds in the above process can be reversed to reach the same conclusion, thusly:
In situations like this, where the sequence of business rules is not relevant, the requirement is better expressed with logic, not with process. A great tool to express this logic is a Decision Model, the scope of which is typically a single business decision that an organization feels is important enough to manage. The Decision Model is a tree diagram that starts with a Business Decision at the top that is typically expressed as a verb with a direct object, for example, “validate address”, “estimate shipping time”, or “determine credit rating”. The Business Decision’s child nodes are Rule Families, and are organized thusly:
Decision Model structure
The business decision is represented by the octagon at the top level, and the polygon underneath it represents the Decision Rule Family associated with the business decision. The Decision Rule Family has three components, separated by two horizontal lines: the rule family name, the rule family conditions, and the rule family conclusion.
Let’s expand on our theater example by creating a Decision Rule Family for it. Say we want to calculate a ticket discount based on the following rules:
- Patrons under 16 are offered a discount of 10%, for any movie.
- Patrons who purchase their ticket 30 days in advance or earlier are offered a discount of 10%.
- For documentary films, patrons who are students are offered 15% off if they submit a valid student ID number.
- Frequent Patron enjoys a discount of 15%.
- The amount of discount is accumulated.
- The maximum amount of discount for all patrons is 20%.
The Decision Rule Family will describe the rules around how the theater calculates discounts for patrons. It can start out like this:
The business decision is “Calculate Patron Discount” and the decision rule family name is “Patron Discount”. The rule family conditions are Patron Age, Lead time, Student ID Number Provided, Student ID Is Valid, Frequent Patron Status, and Price. The rule family conclusion is the calculated discount based on the rule family conditions.
From there, a Decision Rule Family can be more completely expressed in a grid format, thusly:
Each condition is a column in the grid (Patron Age, Lead Time, etc.). Any row’s conditions are “AND”ed together to reach the conclusion. If each item in the row is true, then the action in the conclusion column occurs. For example, if the patron’s age is under 16, and if the current discounted price is 90% or more of the original price, then the price gets discounted by another 10%. The rows in the grid are independent, that is, any combination of rows can contribute toward the final discounted price.
Often, certain conditions require their own complex logic to be evaluated. In our example, the condition Frequent Patron Status can be described as a child rule family of Patron Discount, thusly:
This child rule family has conditions of its own, Shows Attended and Dollars Spent, which can be detailed in its own grid thusly:
According to these rules, a patron has frequent patron status if they’ve attended over 20 shows the past year, or spent over $300 this past year, or attended over 15 shows the past year while spending over $250 during that time.
A final note: It is equally valid to build a decision model from the bottom up, starting with the detailed rules first and abstracting it up to a decision tree.
As I stated earlier, formalizing requirements with work products like this and others benefits both the builders and stakeholders alike. Builders get a clear, complete, unambiguous specification of what to build, and stakeholders get the confirmation that they were accurately heard. We at Mediacurrent provide many other deliverables that clarify and formalize your requirements. Reach out to us to learn more!