Should Requirements Make Assumptions About the Technology Solution?

Over the past few years I have come to realise that business stakeholders are growing in their understanding of technology. Does this understanding carry an advantage, a risk, or aspects of both within the project world?

In my early years as an analyst, I remember working on a particular project and jotting down business requirements that were delivered from a strategic perspective. It was blatantly clear that these requirements were carefully derived to support an organisation’s strategic mission. I discussed these with the technical stakeholder before committing to the business what could or could not be delivered.

In these discussions, I realised that many of the requirements were either a) technologically impossible within the current landscape or b) going to take much longer to complete than what the project allowed. In order to ensure that all avenues had been explored, I held workshops with the technical stakeholders to uncover alternative options or workarounds.

Challenging the challenges

My next step was to sit down with the business stakeholders and explain to them why some of the proposed requirements were not as feasible as was originally anticipated. They accepted some of the workaround suggestions, but didn’t think twice about those that would in any way compromise the ultimate, organisational strategic objective. The short of it was that I needed to sit down with the technical stakeholders again and thrash out workarounds for the ‘non-negotiable’ requirements. These would need to provide the same result – within the original timeline and budgetary constraints of course. Needless to say, long hours and vast amounts of effort ensued.

What was important here was that the business knew what they wanted and compromises to the strategic objective were not in question. Whenever requirement negotiations went on, the business stakeholders would keep that ultimate objective in mind. Everybody in the discussions knew what they wanted and more importantly, they knew why they wanted it.

We can meet objectives, or we can meet objectives

In contrast to the above and on a more recent project, I worked with a particular stakeholder who picked up information very quickly. He took the time to sit down, learn about the technologies in question and ultimately deliver better formulated requirements. I say ‘better’ in a very loose manner as these requirements were only better if seen from a specific perspective. The developers for example, enjoyed discussing requirements with the stakeholder, as they were never far reaching or difficult to understand.

What resulted was functionality that was designed around the limitations of a system, rather than requirements that were aligned to a strategic objective. The difficulty here was managing the stakeholder and asking him to take a step back and consider whether the requirements he had provided were in line with the original strategic objective of the system implementation.

If this is not managed correctly, a danger exists that a compromised system is delivered, that meets the revised business objectives, but no longer aligns to the original strategic objective of the organisation. It’s an imperative step to move out of the detail every so often and ask that all important question – Why? Why are we implementing this? Why is this project taking place? Having a business stakeholder step into the technological realm is a bit like having Darth Vader step over to the light side. You lose the story. In this case, you lose your user story.

Is the meaning of ‘requirement’ getting lost?

The role that I needed to play on this project was very different to the one I played on the project where the stakeholders took no interest in the technicalities of delivering the system. My view is that the role of the business analyst is to implement benefits driven change. To achieve this, it is necessary for the BA to understand how stakeholders approach the requirements conversation and to stand up for the benefits appropriately.

Sometimes requirements need to be challenged, even when they’re easily implemented. I understand that this approach might expose a more complex requirement, which could in turn impact delivery timelines. However, this ensures that a strategically aligned system is delivered, and not just an easily implemented system. To answer the opening question, I believe that having business stakeholders with technological knowledge holds both advantages and disadvantages. In order to make the most of it though, somebody needs to ‘keep an eye on the game’. That somebody is the analyst.

>> Learn the Business Analysis Process

An essential element of succeeding in a business analyst job role is understanding the business analysis process. We walk you through an 8-step business analysis process in the 4-week self-study session of the BA Essentials Master Class. You’ll learn a step-by-step business process that you can customize to meet your organization and project situations, how to create a timeline for a new business analyst assignment, and be prepared to handle the more common issues BAs face on new projects.

Click here to learn more about the BA Essentials Master Class

Free Training - Quick Start to Success

(Stop the frustration and earn the respect
you deserve as a business analyst.)

Click here to learn more

By signing up, you agree to our Privacy Policy.


  1. I see no way the two can be kept separate very effectively (i.e., business requirements and technological challenges). Business requirements often contain a mix of what we want to do, what we feel we must do to succeed and what we can do now. One reason for business leaders to continuously enhance their understanding of technology is so they better appreciate the risk, cost and opportunity the technology presents. We’d hope.

    Unfortunately, vision, strategy and objectives are all unclear, dynamic and disconnected. The difference between the Zachmann framework, say, and a real environment is the difference between a fresh loaf of sliced bread and a paper bag full of donuts you just sat on. This difference is entropy, waste, lack of agility and frustration for everyone. It’s also a reason the dream of using IT to enable capability and vision can be very tough. It’s the world where multimillion dollar systems implementations give us the hope of a brighter tomorrow, but with no one in charge of data definitions–doesn’t matter, they’re all NULLs-allowed anyway.

    Business Analysts may be the best defense–the boots-on-the-ground as they say–but shame on us if we should ever forget why we needed a layered architecture model in the first place. With strategy potentially changing over night, stable requirements have no chance. Like data dictionaries that contain narrative definitions written by people, I expect requirements management will be just a head-scratcher on the page of history soon. [smile]

  2. Brendan MacDonald says

    Agreed Nik, the issue that we’re currently facing is that our Business users are getting over-excited by the new technologies that are coming on to the market that they are forgetting what their business units are actually supposed to deliver.

    I think that if the Business users really understood the ‘nuts and bolts’ of their business then they would still have that clarity and strategic vision. I feel though that a lot of Business users don’t actually have a feel for what they are doing any more and are therefore relying on technology to drive their direction rather than using technology to enable their vision.

    That being said there is a lot of ‘cool’ new technology out there that Business and IT should be looking at together to see how the business could leverage off it to deliver better results quicker.


    • Srila Ramanujam says

      Could so much agree to the thoughts put out that I am almost beginning to dangerously classify the Technological workings most often go to form a subset of the broader ‘business goal’ vision or probably more rightly termed mission.
      So given that, and assuming that it is not false on its own premise, I would totally agree that technical know-how’s ought to go in tandem with the business objectives and hence it is nice and may be a good practice to check every once in a while on both those yardsticks if we are progressing on the desired path…..

    • Ian Drake says


      I totally agree that our stakeholders have lost sight of their own processes and goals. They now tend to communicate in systems vocabulary which is itself the outgrowth of 20-30 years of miscommunication.

      However, I disagree totally with any suggestion that technology should have any place in business analysis. It is still the purpose and role of the business analyst to shield the stakeholders from their existing technology and to drill back into their business domain. Any attempt to bypass business modeling in favor of relying on either existing applications or off the shelf products as business models is pretty much guaranteeing failure (see Laura’s “5 Steps to a Failed Project”.)

      The BA need to make the stakeholders understand the it is first and foremost a business problem that is being solved. The underlying business problem is rarely stated as such, but absolutely must be, without any systems terminology. Just performing that “simple” step will almost always change the direction of any project radically.

      Once they understand the business problem, they can look to design a business solution which may subsequently be automated. The automation of the business solution, in most cases, will tend to be much simpler and cheaper than the end result of trying to bring technology into the mix from the get go.

  3. Michael Hendon says

    Nik –

    As always, a well written article. I couldn’t agree more that business stakeholders are beginning to step over into the technical space. I see it on our projects all the time. I often wonder if there isn’t some correlation between job cuts and employees looking to gain greater knowledge outside of their specific domain. In some instances, business stakeholders may be doing this because they are being stretched to perform the roles of others, while in other instances, they may just be looking to make themselves indispensable.

    As you say though, this can bring major risks with it if it is not monitored. Stakeholders need to understand where their core focus must lie. If they deliver a project on time, but it doesn’t meet business strategy, they should be held accountable. At the end of the day, they need to understand what THEY are delivering on and being monitored against.

    Thanks again,



Before you go, would you like to receive our absolutely FREE workshop?

(No formal experience required.)


Quick Start to Success
as a Business Analyst

By signing up, you agree to our Privacy Policy.