Member-only story
Identifying and documenting business rules
Policies, regulations, standards, and other business rules are important sources of software requirements.
My friend Jeremy visited his local blood bank’s website and made an appointment to donate blood later that day. However, when Jeremy arrived at the blood bank, the staff told him that they didn’t take same-day appointments, even though the website let him make such an appointment. He was annoyed.
Jeremy’s experience illustrates the problems that can arise when software fails to properly enforce or comply with established rules. The blood bank had a policy — no same-day appointments — but the appointment website’s designer didn’t make the software comply with the policy. Therefore, it had to be enforced manually (and inconveniently) by the blood bank’s staff.
This policy is an excellent example of a business rule. It’s not a software requirement, as it applies to manual operations too. If Jeremy had walked into the blood bank to make an appointment for later in the day, some staff member would have told him, “Sorry, we can’t make same-day appointments.” The policy should have served as the origin of functional requirements for the blood bank’s appointment system. In this case, though, someone dropped the ball.
