Why SMEs should define software requirements before buying a SaaS product

By Peter Meyer, Principal Consultant, Elkera Pty Limited

16 April 2025

In my observation, small and medium service enterprises (SMEs) often jump into acquiring new software without a lot of obvious analytical work. This problem is particularly common when looking for an existing, hosted product, known as software as a service (SaaS).

It is fairly common for an SME project to be driven by a key manager who has already decided what they want before the project is formally initiated. Sometimes it can be difficult to persuade managers to undertake formal stakeholder consultation business process analysis and software requirements development. There seems to be a perception that because it is an existing product, there is little need to develop software requirements. Sometimes the very nature of software requirements is misunderstood. Managers may even say that they don’t see a business case for spending money on analysis work.

Unfortunately, those perceptions are likely to lead to costly mistakes. It is essential to conduct stakeholder consultation, analyse business processes, define objectives, develop a business case and develop requirements if a SaaS procurement is to deliver real business value.

This article aims to do two things. Firstly, I want to explain why investing time and money in analysis for process improvement is not optional, but essential.

Secondly, I will outline a practical step-by-step process to develop a requirements specification for procuring a software product, with particular emphasis on procuring a SaaS product. The main focus is on what must be produced, and why, at each step rather than how particular deliverables are developed.

The steps required to develop requirements for a SaaS procurement are not fundamentally different to those required for any other procurement project. However, there are some differences which will be discussed.

High risks of software project failure

The statistics on software project failure are shocking. See evidence gathered by the Standish Group and summarised in an article by Jorge Domingues at ProjectSmart UK: The Curious Case of the CHAOS Report 2009. A similar conclusion was reached by Forbes in 2021.

The majority of business software projects fail to deliver the expected business benefits. Large projects have a higher failure rate than smaller projects but it is reasonable to assess that at least two thirds of projects fail to deliver expected benefits. Many projects fail completely.

SME SaaS procurement projects are subject to those risks.

Many of the causes of project failure are listed in the Forbes 2021 article above, and in 2022 by Frank Faeth.

Requirements failure is a leading cause of project failure

In this article, I focus on requirements failure. A critical test for a project is that the project team has produced a specification of requirements that defines real business needs. While having effective requirements does not guarantee success, it will certainly put you on the road to success. On the other hand, it is almost impossible to achieve success in a SaaS procurement without effective requirements.

The result is that too many SMEs waste large sums on failed or under-performing SaaS procurements.

Why upfront planning is essential

Here are some key reasons why diligent requirements planning is essential to achieving a positive business outcome from your next SaaS or other software procurement.

Without a business case, how do you secure funding?

If there is no effective requirements analysis, it is almost certain there is no business case. A business case has to be based on a clear statement of objectives and how those objectives will be satisfied. Amazingly, some businesses continue to authorise the purchase of software products without a credible business case. As the following topics demonstrate, doing so is a recipe for disaster.

Maybe you have a really good case for procuring software (a SaaS product) to improve your business. Without a credible business case, how do you get funding approval? What is a reasonable amount to invest for the expected benefits? If you have not done the analysis, you cannot answer those questions.

High risk of selecting the wrong product

Without an effective requirements specification, an SME might choose a software product that impresses in a demonstration but doesn’t address your real needs. For example, you may not realise that the demonstrated product won’t integrate with important parts of your workflows.

The product vendor wants to sell their product to you. You cannot expect them to understand your needs unless you can tell them. They cannot spend the necessary time to analyse your business at the required level of detail. It is unlikely they are being paid to do so. There is no alternative to arranging for that work yourself.

At a minimum, purchasing the wrong product means that maximum business benefits won’t be realised. At worst, it may result in very large losses.

Scope creep while trying to fill the gaps

If you have purchased the wrong product, you may discover that the software needs customization or additional modules to cover overlooked needs. Are you going to fund those changes or abandon the product? Unfortunately, once you commit to a product, the sunk cost fallacy often takes over. It is all too easy to spend more money trying to fix a bad investment.

Excess subscription fees

Without careful planning that provides a precise understanding of your needs, you risk wasting money on features or licenses you don’t use. According to Flexera’s 2023 industry report it is estimated that more than 20% of companies SaaS spending is wasted on underutilized subscriptions.

SMEs cannot afford to pay for superfluous features or extra user seats that provide no value.

Complete loss of investment

In a worst-case situation, the product may be abandoned because it does not actually solve any problems, or it creates more problems than it solves. You may be left with contractual commitments for a product that delivers no value.

Forgone future benefits

The costs of project failure are not confined to the wasted outlays. An effective business improvement project will define business benefits over a future time period. If the project is delayed, if it underperforms, or if it fails completely, those future benefits are not realised. The cost of that loss may be very substantial, yet they won’t appear in the financial statements.

Wasted internal effort and disillusionment of your users

If a project has to be abandoned, you will have devoted considerable internal resources to the project, even if it is badly planned. All that effort is wasted. That cost also does not appear in the financial statements.

Further, your users were expecting change that either did not happen or failed. The result is that users become sceptical about change initiatives. The next time you try to start a project, it will be harder to get enthusiastic user participation.

Why software requirements are critical for a SaaS procurement

In all but the simplest procurement projects, the risks I have described can be avoided only by undertaking an analytical process to develop effective requirements that define your business objectives. The level of effort required for that process depends on the project complexity, but it should not be avoided.

Essential features of effective requirements

What then are the essential features of effective requirements for a SaaS procurement project?

For a SaaS procurement, effective requirements must support at least six business objectives:

Define an expected outcome that provides clear business benefits to your organisation.
Be prioritised according to business value so that you can focus on what is most important when assessing solution proposals.
Enable prospective suppliers to assess if their product will fit your needs, and if so, to propose a solution.
Enable you to compare competing proposals from multiple solution providers using different product platforms.
Enable the chosen solution provider to develop a solution without duplicating the costs of analysis and specification previously undertaken by you.
Enable you to assess that the delivered solution meets your requirements.

Software requirements for procurement of software based on an existing product should not:

Anticipate a particular solution provider or product, except where there are constraints imposed by existing systems or lack of competition.
Specify how a solution is to be developed.

Broadly, procurement requirements should define the functional outputs that the business needs and leave it to the solution provider to determine how to deliver those outputs, based on their product platform.

Seven steps to develop a requirements specification for a SaaS procurement

The following topics describe a step-by-step process that should be followed to develop a requirements specification for procurement of a SaaS product, or any other software product.

The seven steps listed here are shown in the accompanying process diagram Requirements analysis steps in a SaaS procurement project (procurement steps diagram). The procurement steps diagram also shows the additional steps required to take you to product deployment.

Following the requirements planning steps will help ensure that by the time you approach SaaS vendors, you have a clear specification of your business needs and a business case that will enable you to assess how much to invest.

Step 1: Define the business problem and project scope

Every successful software project starts by defining the problems or limitations that the business currently experiences. The specific areas of the business that are to be analysed must be defined to set the scope of the project.

It is essential to clearly define the core business problem or opportunity you are addressing. What will be the measure of success? The purpose of this step is to ensure that everyone, from managers to frontline staff, shares a common understanding of the issues to be solved. A well-defined mission or vision statement sets the scope for subsequent analysis.

Step 2: Analyse existing processes

With the problem defined, the next step involves identifying all stakeholders and then identifying and analysing current processes within the scope of the project.

The first stage involves understanding the processes that are involved in the problem area. What are the processes involved in generating the relevant business outputs? The process begins with a functional decomposition and moves to a detailed analysis of relevant processes to document the as-is system.

This step provides the foundation for assessment of improvements in the next step.

Step 3: Identify opportunities for improvement

The as-is processes are analysed to identify where and how things could be improved. What are the root causes of problems? Where is there waste? Where are there lost opportunities?

A common problem is that the same information is recorded multiple times by different people. This is a common problem with spreadsheets. In other cases, desired information may not be captured at all, preventing delivery of an effective service.

Each problem definition should identify the current limitation, a potential improvement and the financial impact of the proposed change. This step ensures that problems are correctly prioritised according to business impact.

This step sets the stage for formulating your business requirements in the next step. It ensures that when you do gather requirements, they will be grounded in real improvements that deliver value, not just nice-to-have features.

Step 4: Develop business requirements and the benefits side of a business case

Business requirements are a step towards development of functional requirements. They answer these questions:

Which business problems are to be addressed
What are the solution objectives, in financial terms
What are the main elements of a proposed solution.

The business requirements document provides the foundation for a business case and for development of functional requirements. The business case sets the targets you will use to measure the project’s success.

Developing business requirements and the business case is an iterative process to establish priorities for the project that will go forward. The process is shown as steps 4A and 4B in the procurement steps diagram.

The draft business requirements must be critically assessed for feasibility. If the benefits are unlikely to justify the expected expenditure on software, the project should be reconsidered or abandoned.

At the end of the iterative process, you should have a set of clear, prioritised business requirements that define changes with clear business benefits.

It can be difficult to establish solution costs for inclusion in the business case at this stage. The detail in functional requirements can greatly affect the assessment of solution cost. Before functional requirements are developed, it may not be possible to obtain reliable cost information. Often you may only have a broad, ball park assessment of the costs to decide if it is worth the effort to go forward and develop functional requirements.

For that reason, it is essential that business requirements are prioritised by business value. Once actual costs are known, it may be necessary to remove lower priority requirements for the overall business case to stack up.

The development of business requirements and the benefits side of the business case enables you to assess the maximum investment that should be made to secure the expected benefits.

Step 5: Develop a change management plan

Before diving into functional requirements or talking to vendors, it is important to prepare for the organizational change that will be required to achieve the business objectives. SMEs often underestimate this part. A change plan outlines how you will implement the new system and adapt processes and people to it.

Key elements include:

Who will be affected by the new software (teams, departments).
What new workflows will look like.
How teams may be re-organised and roles re-defined.
What changes can be made immediately and before procuring new software.
What data cleaning is required to facilitate data migration.
Critical issues in deployment planning such as dependencies.
How you will train users.
How you will get user buy-in.

In a SaaS procurement, you will have to work within the constraints of an existing, general-purpose product and the supplier’s way of working. Final workflows and the deployment strategy may not be known until the new software is selected.

Step 6: Develop requirements specifications

Now it’s time to translate the business requirements into more detailed functional and technical requirements that you will use to request and evaluate solution proposals.

Depending on complexity of the project, you may need to develop multiple requirements documents, including:

Functional requirements that define what the software must deliver to its users to provide the expected business benefits
Non-functional requirements that define the system wide performance and other characteristics that must be satisfied
Technical requirements such as data migration requirements.

The requirements specifications are developed through close consultation with all affected stakeholders to ensure that their needs are correctly understood. Requirements are not a matter of recording user wish lists. Rather, they look behind what users say they want to really understand business processes. It is the job of the analyst requirements writer to define the best way to achieve desired business outcomes.

Functional requirements

The business requirements developed in step 4 provide a high-level description of the proposed improvements. To achieve those improvements, the software must deliver particular results for the business. The purpose of functional requirements is to define those results or outputs in sufficient detail that different SaaS providers can propose a solution based on their product platform. Requirements for a SaaS product will be much less prescriptive than for a bespoke software product.

It is important to appreciate that a SaaS product is designed to meet the needs of a broad set of users. It is unlikely that any SaaS product will deliver everything you want. Many aspects of the product may be inflexible, requiring you to adapt to its way of working.

It is essential to understand your requirements priorities and be prepared to adapt some business processes to the way that the chosen software works, particularly in lower priority areas. Functional requirements should be prioritised according to business value. Requirements that provide lower value but describe nice to have features should be identified as such.

The critical elements that functional requirements must provide to a SaaS provider are:

A description of your business problems and objectives, broken down into distinct business functions
Process flows that describe the particular points at which specific data must be collected and reported
Interactions with existing systems
Detailed descriptions of the information that users require (reports) at particular points in your workflows to accomplish their work and deliver the expected business benefits
Specific requirements related to data gathering and recording.

The form of functional requirements

At the functional requirements level, there are three major approaches to writing requirements:

Traditional “shall” requirements, which state that the system shall provide a particular feature or function.
Use cases, which provide a detailed description of interactions between the user and the system interfaces as a set of workflows.
Epics and user stories, which are short, user-centric descriptions of desired system capabilities or outputs, written in plain language and accompanied by test or acceptance criteria, also written in plain language.

Requirements for a SaaS procurement should be written as epics and user stories. A detailed explanation of the differences and benefits of each approach is a topic for another article.

Requirements in the form of epics and user stories describe the outputs that are required and why, not how those outputs are to be delivered. Expressing requirements in that way enables a side-by-side comparison of competing solution proposals.

Non-functional requirements

Some important business needs are not conveniently expressed in user story structure. Matters such as the number of users who must be supported, system availability, system response times, data volumes, interface requirements (not designs), security requirements, product integrations, migration out requirements, support requirements and other quality and service matters all should be defined in a non-functional requirements specification.

Data migration and other technical requirements

If there are specific areas that require detailed elaboration, they should be defined in a separate specification document. Data migration is a common example.

Step 7: Develop request for proposals

To assemble a complete package that can be presented to prospective solution providers, the requirements specifications should be accompanied by a request for proposals document (RFP). The RFP should tell solution providers what you expect in their proposals to meet the following goals:

Ensure that solution providers set out the full commercial and legal elements of each proposal
Specify the expected response time
Ensure that solution providers clearly identify those requirements they can satisfy and those they cannot
Invite suggestions for alternative approaches to achieving your business objectives where requirements are not directly satisfied
Obtain information in a consistent way that will facilitate comparison of competing proposals.

With a complete requirements specification and RFP, you will have a package that satisfies the six business objectives set out earlier.

With an effective requirements specification, you will be driving the assessment process based on a clear statement of your business needs, rather than being led by vendors’ sales pitches. With your business case will be able to clearly determine if the investment required for a particular solution is justified by the expected business benefits.

Conclusion

There is a clear business case for taking the time to understand and document your business needs before engaging SaaS vendors to provide solution proposals. Skipping or shortcutting the analysis phase is a false economy. The business will be exposed to a high risk of wasted spending on sub-optimal products or outright project failure. Benefits that you should expect may not be realised.

The analysis process does require an up-front investment. You should establish a risk management approach with your business analyst to ensure that you are not committed to work that will not produce real benefits, as described in my article: Overcoming the barriers to using experts for small and medium enterprise software projects.

A systematic, step-by-step approach will equip you to cut through the sales hype and focus on business outcomes. You will be setup to choose a SaaS product that solves business problems, delivers real business value, and should be embraced by system users.