In software development, I find that many firms place insufficient emphasis on requirements―one of the most fundamental building blocks of successful software origination.
Requirements are the “what” of the matter―what we are supposed to build. However, humans are creatures of action. They are so enamored with the “how”―how are we going to accomplish it―that they do not adequately define “what” it is they are building.
This approach is often doomed to failure, not because coders aren’t doing their jobs, but because what the customer wants isn’t what he actually needs. It takes a highly skilled business analyst to probe deeply enough to discern the customer’s true need. Then, the developer and his team can determine the fastest, most accurate, and least expensive way to accomplish that goal.
Too often, the individuals working on user stories are order takers who don’t procure that most fundamental piece of information. They have a minimum of interaction with end users without ever getting to the core need that should drive the process.
As a result, they cannot effectively communicate that need to the developer. The developer then tells the coders, “I heard they want this; go build it.” The coders engage in guesswork, which leads to functionality that might not do its job.
There are corollaries to this scenario in our daily lives. Here is one.
A young man goes to his father and says, “Dad, I need a car.”
If his dad is an order taker, like so many business analysts, he says, “OK, what features do you want it to have? A CD player; two doors or four; a sunroof?
In reality, these are nothing more than embellishments, and the car itself is a deliverable, not the need that drove the request. The need is transportation― which prompts a different set of questions.
- Is your school too far for you to walk?
- Do you want to take a young lady out for a date?
- Do you get out of school too late to catch a ride with friends to sports practice?
As it turns out, the problem that generated this request was number three―getting to sports practice. Now that Dad knows this, he can explore the workflow of the activity and develop potential use cases that might resolve this issue. In the end, Dad determines that the fastest, most accurate and least expensive way to resolve the need is for his son to hitch a ride to sports practice with another friend who also gets out of school late.
This is a simplification, of course, but the fundamental principal is the same. Without accurate requirements, achieving the right functionality through coding becomes a stroke of luck. On the testing end, all the tester can do is ensure the software works as written. If the code doesn’t reflect the requirements with all their variables, there is no way for testers to realize the code doesn’t provide what the user really needs.
At the end of the day, requirements are impossible to escape. Companies have two choices. They can support their business analysts by equipping them with the skills and time to extract real needs and write accurate requirements, including user stories and detailed acceptance criteria. Such an approach substantially increases the chances that missteps and misunderstandings will be caught early on, while changes aren’t costly or disruptive. Or, they can expend more money and time to fix the software in production, when remediation is at its most expensive. There is always a choice.