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.
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.
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 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.
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.
People hear and interpret things differently. You need to adjust to your audience, share the message through different avenues and repeat your message until it has been understood.Continue ...
In a traditional systems development life cycle (SDLC) project, sometimes the end result does not successfully meet the needs of the user, even though it does meet the requirements set out by the business requirements document.Continue ...
Plain and simple, software and services are used by people. And the user’s experience with those services will decide the success or failure of the enterprise that creates and owns them.Continue ...
Customers become frustrated with an online service that goes as far as filling out a form, then they click on submit and end up waiting for days, weeks or longer for their transaction to complete.Continue ...