How to implement business requirements in software development |

How to implement business requirements in software development

Increment your e-commerce app to ensure it implements required business process rules correctly.

Working on a team, busy worklife
Image by :


Subscribe now

Get the highlights in your inbox every week.

In my previous articles in this series, I explained why tackling coding problems all at once, as if they were hordes of zombies, is a mistake. I'm using a helpful acronym to explain why it's better to approach problems incrementally. ZOMBIES stands for:

Z – Zero
O – One
M – Many (or more complex)
B – Boundary behaviors
I – Interface definition
E – Exercise exceptional behavior
S – Simple scenarios, simple solutions

In the first three articles in this series, I demonstrated the first five ZOMBIES principles. The first article implemented Zero, which provides the simplest possible path through your code. The second article performed tests with One and Many samples, and the third article looked at Boundaries and Interfaces. In this article, I'll take a look at the penultimate letter in our acronym: E, which stands for "exercise exceptional behavior."

Exceptional behavior in action

When you write an app like the e-commerce tool in this example, you need to contact product owners or business sponsors to learn if there are any specific business policy rules that need to be implemented.

Sure enough, as with any e-commerce operation, you want to put business policy rules in place to entice customers to keep buying. Suppose a business policy rule has been communicated that any order with a grand total greater than $500 gets a percentage discount.

OK, time to roll up your sleeves and craft the executable expectation for this business policy rule:

public void Add2ItemsTotal600GrandTotal540() {
        var expectedGrandTotal = 540.00;
        var actualGrandTotal = 0.00;
        Assert.Equal(expectedGrandTotal, actualGrandTotal);

The confirmation example that encodes the business policy rule states that if the order total is $600.00, the shoppingAPI will calculate the grand total to discount it to $540.00. The script above fakes the expectation just to see it fail. Now, make it pass:

public void Add2ItemsTotal600GrandTotal540() {
        var expectedGrandTotal = 540.00;
        Hashtable item = new Hashtable();
        item.Add("00000001", 200.00);
        Hashtable item2 = new Hashtable();
        item2.Add("00000002", 400.00);
        var actualGrandTotal = shoppingAPI.CalculateGrandTotal();
        Assert.Equal(expectedGrandTotal, actualGrandTotal);

In the confirmation example, you are adding one item priced at $200 and another item priced at $400 for a total of $600 for the order. When you call the CalculateGrandTotal() method, you expect to get a total of $540.

Will this microtest pass?

[ 00:00:00.57] tests.UnitTest1.Add2ItemsTotal600GrandTotal540 [FAIL]
  X tests.UnitTest1.Add2ItemsTotal600GrandTotal540 [2ms]
  Error Message:
   Assert.Equal() Failure
Expected: 540
Actual: 600

Well, it fails miserably. You were expecting $540, but the system calculates $600. Why the error? It's because you haven't taught the system how to calculate the discount on order totals larger than $500 and then subtract that discount from the grand total.

Implement that processing logic. Judging from the confirmation example above, when the order total is $600.00 (which is greater than the business rule threshold of an order totaling $500), the expected grand total is $540. This means the system needs to subtract $60 from the grand total. And $60 is precisely 10% of $600. So the business policy rule that deals with discounts expects a 10% discount on all order totals greater than $500.

Implement this processing logic in the ShippingAPI class:

private double Calculate10PercentDiscount(double total) {
        double discount = 0.00;
        if(total > 500.00) {
                discount = (total/100) * 10;
        return discount;

First, check to see if the order total is greater than $500. If it is, then calculate 10% of the order total.

You also need to teach the system how to subtract the calculated 10% from the order grand total. That's a very straightforward change:

return grandTotal - Calculate10PercentDiscount(grandTotal);

Now all tests pass, and you're again enjoying steady success. Your script Exercises exceptional behavior to implement the required business policy rules.

One more to go

I've taken us to ZOMBIE now, so there's just S remaining. I'll cover that in the exciting series finale.

Gears above purple clouds

Programming can feel like a battle against a horde of zombies at times. In this series, learn how to put this ZOMBIES acronym to work for you.
Security monster

Start development simply, by writing and testing your code with One element and then expand it out to Many.
Looking at a map for career journey

Zombies are bad at understanding boundaries, so set limits and expectations for what your app can do.

About the author

Alex Bunardzic - Alex has been doing software development since 1990. His current passion is how to bring soft back into software. He firmly believes that our industry has reached the level of sophistication where this lofty goal (i.e. bringing soft back into software) is fully achievable. One of the amazing ways to accomplish that is to adopt the 'fail fast' approach by crafting a measurable goal/test and then iterating until the test passes. Following that, send the sniffing police dog to check the cargo (i.e...