You are currently viewing Business Versus Functional Requirements

Business Versus Functional Requirements

I see it all the time – business leaders get enamored with a technology and its bells and whistles without really understanding if it’s going to be good for the organization or not. They just buy it and tell teams to make it work.

But that’s a terrible way to go about software and systems in your business. It’s like buying a two-door sports car as your everyday driver because it’s a sexy car with cool bells and whistles when, in reality, you need a four-door sedan or SUV to shuttle your family of four around to school and soccer practice. The two-door sports car is shiny and cool, but it doesn’t do any of the things you need it to do for your family’s requirements. If you fall in love with that brand new shiny vehicle and buy it on impulse, you might have to trade it in at a loss a few months later when you realize it’s not what you need.

It’s the same thing at enterprises. Business leaders fall in love with software and spend millions to implement it, only to find that it doesn’t do what the business really needs it to do. The management team that selected and implemented the software most likely gets fired for picking a terrible software, and the brand new team is now saddled with crap software. The new team spends millions more to get a different program that fits, but often makes the same mistake, too. That puts you in a cycle of buying pieces of software that don’t work for what you’re trying to do and constantly replacing it every 3-5 years.

An example comes to mind from an old client. I went to the tech manager at the organization and said, “Hey Mary, there are many pieces of functionality we’re going to need to upgrade in your department on this software we’re putting in. For us to do it the right way, we need you to help us gather your business requirements.”

She looked at me and in the most matter-of-fact way said, “Tim, when I hear you say the word ‘requirements’ I think you’re tacking several months onto my timetable, and I just don’t have time for that.”

I thought, “When I hear you say that, I hear years and years tacked onto your timeline because of copious amounts of rework and the loss of data and loss of trust by your workforce as a consequence.” In the end, it took four years and $22M to get it done.

Before my team came on board, any time Mary needed the software vendor to make a change to the software, she would just call them up and tell them to make the change. There was no analysis of what the change might affect and/or how it might affect other departments. The vendor would often reflect back that it was difficult to make recommendations as to the best way to do things when there was no cohesiveness and just random one-off calls. But she didn’t care. She just wanted the thing done now.

If you want to not get fired, not waste money, and actually do shit the right way, you need to understand why business requirements are so important and how they differ from functional requirements.

Business requirements are what your business needs to do to get the work done on a daily, weekly, monthly, quarterly, and/or yearly basis and why they need to be done. They’re what needs to be achieved and why you need to achieve it in order to reach your business objectives.

Functional requirements, on the other hand, usually (ideally) come after business requirements. They answer the question: how are you going to achieve those business requirements/things you need done in a technical way?

A lot of business systems analysts work with clients to elicit the business requirements and figure out what the business is trying to achieve with a new product or update to an existing product. For example, a business may have a system that’s old and doesn’t allow them to sell new variants of the product without a major change, or they may even have no system at all (which is rare in this day and age, but I’ve seen it).

The analyst will go talk to all the business users to determine what works well in the current processes and what doesn’t work well. They’ll ask the client: in a perfect world, what would you like to be able to do?

Functional requirements are a completely different story.

Now that you know what the business is trying to do, you give those requirements to the development team to figure out what to do with the software. Functional requirements are about being able to translate what the business is looking for into something the tech team will accurately create and implement.

That’s a huge place where things fail at a lot of different enterprises. The translation of what the business wants to what the tech people can and/or will provide is not as simple as people think, and often things get lost. Writing functional requirements requires an analyst to be equally as good at talking to the business as at coming up with creative solutions with the technical teams.

So how can you support this process as a business leader?

It’s critical to have a clear idea of what you’re trying to do and why. It’s also critical to give time to the analysts looking into that so they can really understand your needs. You can help analysts refine those requirements.

Functional requirements shouldn’t be part of the business requirements. If you skip ahead to the solution too early, you’ll lose bits of what you were trying to accomplish and why. So, business owners and leaders: don’t fall in love with the tech until you know exactly what you’re trying to do and, for the love of God, make sure you document your business requirements first!