Requirements Engineering: “What” vs. “How”
By: Matt Angerer
It’s been my experience that firms place too much emphasis on the end result and not enough on the requirements in the software development process. Don’t get me wrong, the end result is what truly matters to your business. We have all heard that there are multiple paths to the same end result, but the beginning phases of a project are essentially the foundation to build your house upon. If you build on a weak foundation, your house is bound to crumble.
Do you remember hearing about Hurricane Andrew that devastated Homestead, Florida in the mid-90s? What you may not have heard is that many of the houses destroyed were not build up to the “code” necessary to withstand a storm of that magnitude. After the devastation, Miami-Dade county wised up and mandated more strict building codes to withstand hurricanes of this magnitude. It’s not a matter of IF another hurricane of this magnitude will occur, it’s a matter of WHEN. As a resident of Homestead, Florida — the house we just built exceeds every hurricane code in the book. It can outlast a storm the size of Andrew, or even more if necessary.
If we stop to think about this for a moment, we can see how software development relates to this analogy. If you rush through the requirements definition phase and focus your team’s attention on “HOW” to create the product, you’re losing focus on “WHAT” is required. Without a sure foundation, you’ll never be able to withstand the devastating storm of changes, enhancements, fixes, and most importantly- what your customers truly want from this software development project.  Tony Robbins, the world famous life coach, said it best in this YouTube video. You must become “riveted” on WHAT you want to achieve before you even think about WHY or HOW you are going to achieve those outcomes in a software development project.
If we fail to focus on requirements engineering, the final product has no chance of delivering what we actually want. You hear so many IT professionals droning on and on about this very topic (like me in this post), but why do we keep seeing history repeat itself time and again?
My opinion is that the Captain (Project Manager) of your ship must possess the leadership qualities to help your team crystallize the WHAT at the onset of the project. That Captain must then have a strong team of Lieutenants (Functional Leads) who fully understand the WHAT of your mission. These Functional Leads must then eat, sleep, and breathe this “WHAT Vision” and remind your Business Analysts, Test Designers, and Developers of that WHAT on a daily basis. Leadership is what sets apart successful IT projects from mediocre outcomes.
“What” Instead of “How” in Software Development
I’ve noticed  that many of us become so caught up in how we are going to do something that we fail to look at what we are actually developing. In this regard, software development has become a bit like taking orders for fast food. Coders simply accept orders but fail to obtain the basic pieces of information necessary to determine what the client needs. Rather than probing deeply enough to find out exactly what the customer requires, teams prefer as little interaction as possible with their clients. What ultimately happens is that the coders are given an order to build a product and find they must rely on guesswork to try and fill that order,  compromising functionality in the process.
I have worked with world-class coders and developers in my career. I have also worked with developers who fly under the radar and deliver buggy code. The one fundamental truth about both is that a developer is only as good as the team surrounding them. You have all of these folks running around the periphery (project managers, test leads, business analysts, executive sponsors, etc.) trying to keep it all together and deliver what the business or customer wants, but it’s the coder/developer who constructs the house, so to speak.
Think about it: would Joe Montana, Tom Brady, Warren Moon, or Dan Marino been so successful as quarterbacks without their 340lb lineman blocking every step of the way? It doesn’t matter if your developer/coder is world-class or barely squeaking by — if they don’t have clear requirements, they will ultimately produce substandard and buggy code. The results are re-work, frustration, and finger pointing during the delivery lifecycle.
Not Enough Information Leads to Poor Quality Development
Imagine for a moment if we used this same process in purchasing a vehicle. As we all know, vehicles are not created equally and different vehicles include different features. Yet, if we simply told the car dealer that all we need is a vehicle with air conditioning and a CD player, he or she might recommend anything from a small compact vehicle to a minivan to a truck. By comparison, if we said we need a vehicle that is capable of seating at least six people, has a built-in DVD player, and ample cargo storage, the car dealer would know that what we really need is a minivan.
Similarly, we can see why it’s so important to extract basic requirements and ensure the software is developed to meet the true needs of the client. In terms of testing, the test is only able to verify that the product works with the information provided. If the information obtained by the coders does not reflect the true needs of the clients, testers have no way of determining what the client really needs. Procuring and documenting accurate requirements are essential for both software development and testing. Incorporating this step will significantly reduce misunderstandings and errors and still deliver products that are more closely aligned with the needs of the client.
At ResultsPositive, we look at the entire application development lifecycle. On June 17th, we will provide some insight into leveraging HP ALM or Quality Center to create, profile, and manage requirements. Profile requirements? You never heard of that one before? Well, after you set the foundation — inevitably, you need to modify or change it a little. I know, you don’t see this much when it comes to a real live house, but when it comes to software development you must include flexibility in the process. Adding enhancements or change requests to an IT project means that originating requirements and associated test cases will evolve as a result. HP ALM allows us to track this evolution in the form of forwards and backwards traceability, giving you the tools for proper change impact analysis, risk profiling, and testing prioritization.
In our June 17th webinar, we will explore a number of these topics while providing you an in-depth look at HP ALM’s Risk Based Quality Management (RBQM) features.
Subscribe for the latest RP Blog Updates:
