Delivering Results with Requirements Engineering, Part I – An Overview

EDITOR’S NOTE: This blog post is the first in a continuing series about the importance of a requirements engineering process. If you’re considering an eCommerce project at your company, you’ll want to watch this space. The posts in this series will help explain how having a solid process in place saves time, work, and money. It also turns clients into partners and when that happens, everybody wins. Enjoy this inaugural post, and be sure to stay tuned for the rest of the series.

Just about everything a service provider does should revolve around a single objective: using technology to make clients more successful and efficient. But the way that work gets done sure has changed. Development methodology has evolved significantly over the past 30 years. In the old days, service providers would have their input people – business analysts, sales reps, and account managers – gather the necessary requirements to complete a project and then throw all of that information over the wall to their developers, who would get down to work on their specific part of that project. The input people would then move on to the next client without ever looking back.

That’s not happening anymore. Service providers have realized that there’s a better, smarter way to work – one that relies on gathering requirements up front, documenting them, understanding a client’s needs, and ensuring that things don’t fall through the cracks. Agility is an essential part of this new methodology, especially with complex software development projects; Even the smallest change to a requirement can have an enormous impact on how the finished product will work. For that reason, service providers now tackle a project in pieces, so that they and their clients can test each piece, gather feedback as they go, and address any requirements that may change as the project progresses.

Providers also understand that what they and their developers do isn’t accomplished in a vacuum. That’s because stakeholder involvement, communication, and an iterative process are critical to success. The more of it there is, the better the product will be on the other end

Having end-to-end documentation and establishing a solid requirements engineering process is a first step toward ensuring excellence. And “process” is the key word. Here’s the process that Ultra Commerce  has created and uses with its clients. Although the schematic below starts with project initiation and appears to end with development, it’s far more accurate to consider it the first stage of development. Throughout a project, developers should be constantly re-evaluating and tweaking functionality to ensure that clients get exactly what they need to succeed.

As the schematic shows, Ultra Commerce’s requirements engineering process consists of nine distinct steps that start with the assignment of a development lead and a client lead, and eventually arrive at a project plan that marks the kickoff of the development stage.

Remember what we said in the introduction to this post about how a good requirements engineering process turns clients into partners? This middle ground is exactly where that partnership happens. Getting to know clients, and not just their projects, is one of the hallmarks of effective requirements engineering. The process also gives clients ownership and agency, because it invests them in their own results. By collaborating with clients during discovery, the creation of deliverables, and the review/approval process, service providers can do a better job of defining objectives, increasing efficiencies, identifying potential issues, minimizing errors, and ultimately achieving success.

Requirements engineering is an awful lot like the preparation stage of baking a cake. Imagine, for a moment, that your kid is really in the mood for his or her favorite cake. You have all the necessary elements in your kitchen, but you need to run out for the afternoon and get errands done. So you hand your kid an apron, and say, “Here – when I get back home, I want to see all of the ingredients measured and prepped to bake a cake. Later!” Then you leave. There’s just one problem: Your kid has never baked a cake before. (Let’s take some artistic license here and assume that 1) you don’t use cookbooks and 2) your Wi-Fi is down so that the kid can’t go on YouTube to find helpful videos about cake-baking.)

When you arrive back home a few hours later, what’s the likelihood you’re going to see anything that even remotely resembles a fully prepped kitchen ready to bake? Slim to none, probably.

To take the cake analogy one step further, the work that a service provider does is so customized to each client that it’s like baking a new kind of cake each time a project begins. A little preparation goes a long way, in the kitchen as well as in eCommerce. Think of the requirements engineering process as the recipe for your project’s success. And although the deliverables in the process aren’t edible, they are essential. They include:

• The functional specifications document
• Wireframes
• A statement of work
• A project plan

In the second post of this series, we’ll take a much closer look at one of those deliverables: the functional specifications document.

In the meantime, all this talk about cake has made us hungry. We’re just going to check out the Ultra breakroom and see if there are any good snacks hanging around in there…