BDD: Value and function

author avatar

Brian Ansems

It has been my experience that large enterprises with complex and legacy business systems often will describe their wants and needs in terms of business functions. These business functions then detail how something should work within the practices that already exist within the system. This is valuable and appropriate analysis to ensure your requested solution will find a proper fit when implemented in the real world. However, what is often missed is the identification and explanation of the business value of the requested solution.

What do we mean when we say business value?

Value is the creation of positive effects and outcomes for identified stakeholders. Value can be monetary, informational, relational, or even emotional. Value can be thought of as the why when describing what it is you need to be developed. As an example, we might be collecting requirements for a new application that returns receipts of purchases upon completion of a retail transaction. If I were to write a business function, I might describe the requirements as the following:

Business Function: Upon completion of a retail transaction, a receipt should be created, detailing the transaction, and made available to the buyer. 

Of course, this is very simple, if not reductive. However, what I’m trying to show is an example of documentation that ends up describing what should happen, but not why that thing should happen at all.

Feature descriptions and user stories

To help myself answer why I’m asking for something to be developed, I write my requirements using feature descriptions and user stories.

Feature descriptions provide a high-level description of the aims and goals of the requested specifications.

User stories are a method of recording identified stakeholders, their explicit or implicit wants and, lastly, their reason for using your solution. When writing your user stories, you should be identifying the business value your solution will provide. There are various ways people write user stories, but my own preference is:

As a (the identified stakeholder)
I want (their want or need)
In order to (the value your solution should provide)

Going back to our example, we might write our requirements as the following:

Feature: Buyers of our products should be presented with a receipt of purchase after a retail transaction has been completed.

As a buyer 
I want a receipt of my retail transaction 
In order to be assured that I have been charged the proper amount of money

Using this as a baseline description of the intended solution, we have identified a key reason to create our receipts. Buyers want proof of the purchase and build trust with us, the hypothetical company. Our solution then should be designed in a way that optimizes providing that value. We may then have a better understanding of language we wish to use on the receipt or even the layout. Provided our specifications are directed at providing our identified value (assuring buyers and building trust), we should be comfortable ourselves in developing those specifications for production.

Documenting and identifying the business value

Documenting and identifying the business value of your solution also helps to understand the scope of your project. Any and every specification should challenge the question, “Does this provide the intended value to our identified stakeholders.” If it does, provided other constraints do not impede its development, the specification should likely be considered inside the scope of your project. If, however, the specification does not provide the intended value, then it may simply be wasted effort or, in the worst cases, actually reduce the value you provide.

Of course, we can document these specifications using the scenario format I’ve discussed previously, our Given, When, Then statements. And by using clear examples of real-world use cases, we can be doubly assured in our judgment when evaluating whether or not our particular specifications actually would provide real value to our users and stakeholders.

Is this the only way to do this?

All of this is not to say that other people do not do this analysis in other ways. I’ve worked in teams that can and do provide immense value to many people using the tools they have available to them. This post is meant more to answer tendencies I have noticed when working in enterprises with complex business behaviours; analysis can often be occupied with documenting those systems and then writing requirements that only answer how the developed solution will accommodate that system, all without naming the real reason the solution is being developed in the first place.

It just so happens that for myself, feature descriptions, user stories, and scenarios help me provide that value within my own documentation.

Thanks for reading! If you would like to know more about BDD (Behavior-Driven Development) and how can help your business or organization, email us or tweet at @thinkingbiginc.

More articles

; ;