Guide to setting requirements for WordPress & WooCommerce projects

Procuring a WooCommerce project can be complicated. What should the requirements look like and how do you select suppliers?

Within your own organisation, there is a lot of knowledge about the business values you want to get out of your e-commerce, but rarely expert knowledge about what processes you should expect from your supplier.

In this guide, we will go through how to think when writing a requirement specification for a WordPress or WooCommerce project to be successful and to choose the right type of supplier.

Before we begin, it is important to say that this guide is primarily for projects whose outcomes are intended to be used daily for a couple of years. This means that in addition to implementing the project, it needs to be professionally operated, managed and developed throughout its lifecycle. If the intention is to implement a project that is then discarded within 3-6 months, this guide is not applicable. Furthermore, the guide is aimed at e-retailers who actually sell things and where it is important that the solution always works. If you feel that it does not matter that the checkout on the site is down for a few days, this guide is not applicable.

Outline of a requirements document

The outline of a requirement can look a bit different, but as a rule, these different ingredients should be included:

• Background
  • About the product/service
  • About the organisation
• Business objectives
• User stories
• Terms of delivery
  • Calendar time
  • Requirements for working method
  • Guidance on documentation and reports
  • GDPR and other legal requirements
• Management
  • Expected traffic profile (number of visitors/month)
  • Operation requirements
  • Technical maintenance requirements
  • Requirements for further development
• Appendix: Documentation of third party systems (if applicable)

If you want, you can also write proposals for different personas and different use cases, but the above layout and content should work for most projects.

Requirements are always based on business objectives

In all projects, there is always a basic idea of what business value you expect to get out of the project you want to run. The project should always be based on these objectives and then broken down into more specific requirements.

Guidelines on business objectives to be achieved are normally set by the company’s management and can look something like this:

• We will increase the number of leads
• We will increase turnover per person
• We will increase the number of job applications

These business objectives are then broken down into functional and non-functional requirements. Modern projects often use user stories, which are a simple way of defining requirements so that both client and supplier understand and agree.

What are user stories?

A user story is a concise specification of a functional or non-functional requirement. For example, a specification for an e-commerce site might mention having a shopping basket. This is called an Epic. An epic is then broken down into several smaller User stories which in turn have Acceptance tests. A User story is usually expressed in the form “As I want to “

Example of a User story:

As a visitor, I want to receive a visual notification showing how many products I have in my basket when I add a product to my basket. This feature is important because it makes it clear to the visitor how many products are in the basket.

Acceptance criteria

• When I click “buy” on a product for the first time, a number appears next to “Basket” in the menu.
• If I remove all products from the basket, the number in the menu disappears
• If I add or remove products from the basket, the counter increases and decreases to reflect how many products the basket contains

Even non-functional requirements can be expressed as User stories. For example;

• As a visitor, I want the website to be available 99.9% of the times I try to use it, so I don’t get frustrated and find another website for my purchase.
• As a visitor, I want to be able to use the site with a speech-to-text emulator.

For further reading, we recommend User Stories Applied by Mike Cohn.

Who should be the internal claimant?

In the long term, the organisation should own the outcome of the project and hopefully use it in its daily operations. This means that the quality of the requirements can only be ensured by those who know how to use the system.

Therefore, the project is best served by having the requirements defined and tested by different units within the organisation. For example, an IT organisation is an expert in requirements based on technology and systems, while in an e-commerce project, the sales and logistics departments can be experts in the functionality you want. Using multiple departments minimises the risk of blind decisions compared to if the entire requirements definition comes from a single unit.

For the requirements gathering process to succeed, 5 things are needed;

1. Review roles, responsibilities and mandates.
2. Create a requirements strategy that describes how the requirements management work should be done.
3. Facilitate workshops with different stakeholders to establish priorities.
4. Establish a model for how requirements work and prioritisation will take place.
5. Establish a plan for how the project is reported in your organisational structure and culture.

Set requirements for project work processes

There are many different ways to run projects. It may be comfortable for you as a buyer to have a fixed price for a project, but this way of working will rarely produce the best results. Instead, you should look for a supplier who is used to managing to targets and who works with so-called agile working methods.

Iterative work process

In an agile approach, you work towards achieving business objectives rather than delivering exactly on the requirements specification you agreed at the start of the project. The knowledge acquired by all parties during the course of the project is extremely valuable and should be utilised to the full. Implementing the project according to agile principles is therefore the most beneficial for your organisation.

At the same time, it should be said that it also requires you to set aside time to be involved in the project. If you do not engage in the project, the project will not be better than the original requirements specification that you came up with. Read more about how agile WordPress projects work.

Demand modern development methods

If you are to get a good delivery, modern development methods are extremely important and requirements should be set for what internal processes the supplier has. This can be crucial to the long-term success of the project and can protect you as a customer from many expensive problems.

Version management

All modern, self-respecting suppliers use version control. This means that every change can be tracked and creates opportunities for many people to work on the same project at the same time without disrupting each other. Today, GIT is typically used, but SVN is also a system widely used in the WordPress world.

Local development environments

When developing, you want to follow a strict process where the individual developer works on their own computer in a copy of the “real” environment that they will use later. This allows several developers to collaborate at the same time. If you do not use local development environments, it can be problematic for several people to work at the same time, which slows down and greatly increases the risk in the project.

It is also important to ask questions about how this is managed. How long is the set-up time per person? Some providers may have 4-8 hours of set-up time for a development environment while others may have 30 minutes. While this may seem insignificant at the time of the project, it can add up to huge costs later on.

VPN and acceptance environments

After the developers have worked in their local environments, what they have done must be presented to you as a customer and approved. This is often done in separate environments and with a database that resembles as closely as possible what it will look like when it is ‘finished’. These may be called “test environments”, “development environments” or “staging environments” or similar, but usually they have roughly the same function.

Under no circumstances should these environments be publicly available on the Internet, regardless of whether the content of the website is secret or not. If they are publicly available, they can be attacked during development, but they can also be indexed by search engines – which can be a disaster for your digital marketing. For these reasons, we recommend that they are only accessible via VPN.

Construction jobs and component management

When working with multiple people, it is important to have a process that separates standardised process actions – build jobs – from the individual’s computer. These actions need to be done as part of the overall infrastructure, otherwise it will be very difficult for multiple people to collaborate. These build jobs can then be used to, for example, optimise and analyse code on an ongoing basis in order to create high quality in the ongoing work.

In these build jobs, component management is often an important principle. This is normally done with a software called Composer and is a structured and modern way to ensure that all components used in the project are retrieved from the right source and are signed.

In addition to this, the build jobs can consist of a variety of other process actions such as implementing SASS or performance enhancements like webpack. As long as there is a process and an existing standard that is documented and/or version managed, you can be pretty sure that this will be done correctly.

Deploy tools

When code is to be deployed, it is advantageous if it is deployed in a controlled and automated way. This is especially important if you have a high load and need to deploy code to many parallel environments simultaneously. Having an automated process also reduces the risk of errors.

Tools that you want to be available here are primarily Capistrano, which is the largest, but there are also many other technologies such as Deployer, Rocketeer, Ansible and others.

Automated tests

When changes are made in a complex project, a change in one place can have consequences in five others. To ensure that this does not happen, it is important that there are automated tests that ensure that it is simply not possible to deploy things that make important functions not work.

Visual comparison tests

A small change can cause small errors here and there. It can be very difficult – if not impossible – for a human to detect if these details have gone wrong somewhere. This is why visual comparison tests are used. What you do in practice is that, in an automated way, you take screenshots of the website in a variety of screen sizes before and after the change – and then you calculate the difference. This difference is then presented in a report to the developer, who can then decide whether the changes were intended or unintentional.

This prevents a huge number of errors from being detected well before they reach your visitors – your end customers – and cause loss of revenue and prestige.

GDPR

The GDPR (General Data Protection Regulation) is the EU’s new data legislation that regulates how personal data can be stored. Personal data is a relatively broad term and actually covers most things that can be traced back to an individual – including email addresses.

It is not only important that the supplier is aware of how the legislation works, but also of paramount importance that the supplier handles personal data correctly. For example, it is not allowed to copy data from the production environment to a test environment without anonymising the user data in between. This requires an automated process for this both in the project and during ongoing management. Working with a web agency that doesn’t have a process for this will put your business at risk.

Set requirements for delivery terms

One of the most important considerations is when delivery can take place. Here it is important to consider that you as a customer must also have a lot of bandwidth yourself to be able to get a fast delivery. It will be impossible for you to set an exact timetable this early in the project, but an approximate guideline based on your business needs is of course necessary.

Payment terms

Depending on your and your supplier’s liquidity, slightly longer periods on each invoice may be important. 30, 60 or 90 days? This should be made clear early on so that it doesn’t become a problem later on.

Reporting requirements

Do you have an internal client who is authorised to make decisions on new functions and not just to prioritise within the project? Then it is important that there are requirements for reports. It is important to be able to follow via meeting minutes when additions are made and what is prioritised in the project.

Set requirements for further development and operation

Once the project is completed, it will end up in a kind of further development/management phase. This is where you start to actively work with the tool and where it adds the most value to your organisation and where you see the fruits of your investment.

In this phase, it is important to constantly iterate and evaluate to ensure that as much value as possible is added to the organisation. This usually requires a multifaceted knowledge. Using data analysis, statistical tools and user testing (along with listening to your customers and prospects), you can find out if there is anything that needs to be clarified and/or changed.

This process is important and will help you increase your ROI and lower your cost to achieve your set goals. Therefore, it is important to include it in your requirements for the project and the supplier.

Operations and technical management

Once the project work is completed, it will be operated. The problem with operations is that many times the operations company has little control over how the application is to be operated and is completely cut off from the process of developing the application.

Modern development methods require a streamlined work process and this means that this separation between those who develop the application and those who operate it can be dangerous. A high level of collaboration is required for the application to scale well and add the intended value to the organisation.

SLA and penalties

The most important question to ask when setting operational requirements is what SLA levels apply and what response time to expect when something goes wrong. Penalties are also important to set requirements for. An SLA without white requirements is a useless SLA. A reasonable SLA is a basic requirement and is just as important as how the solution is designed. If the supplier cannot provide a reasonable SLA, it is just as well to opt out of the supplier.

Load balancing

If the solution is to scale or cope with visitors to any great extent, there must be load balancers in the operating solution. This means that the load is balanced out between several different servers so that the solution does not go under when there are large amounts of traffic.

Cache and performance optimisation

In order for the application to be fast and handle a lot of traffic, cache and ongoing performance optimisation are needed. Normally, it is very difficult for someone who has not been particularly involved in the project to easily optimise performance. If you are really unlucky, this perspective has not been taken into account at all before running the project, and it can be very problematic.

Log monitoring

When visitors access the website, the website generates logs. As, for example, PHP is updated or new versions of WordPress & WooCommerce are added, minor problems may arise. There may also be inbuilt bottlenecks that have been difficult to detect during ongoing development work that cause the site to become extremely slow or simply stop working under certain specific conditions. This can lead to a loss of business for the website owner, so it should be taken very seriously.

In a thousand uses of the site, this might only happen once, leaving them hiding in a mountain of data. With the help of log monitoring, it is possible to easily follow up on patterns and anomalies in the huge amount of data in order to do something about it.

Security scanning

When critical security updates arrive, they need to be applied quickly. Therefore, it is important to have an automated solution in place to check and alert for security vulnerabilities in the components used on the website. A good check usually uses the WPScan Vulnerability Database.

Technical management

Open source makes use of open components. This is a tremendous strength that allows you to get much more for your money compared to choosing proprietary systems. This means that security updates and functional updates are often available free of charge. However, these updates must be installed and checked carefully before they are added to secure the functioning of the website or e-commerce.

How to narrow down the choice of possible suppliers?

Finding potential suppliers to include in the tender can be challenging. In most cases you will work with an agency, but if you have a large enough organisation you may be working with an in-house team of developers and need the support of an expert resource to guide the in-house team.

There are more aspects to looking for a good supplier than just googling “web agency stockholm”. When you make the selection, be more specific. Is it an e-commerce you are going to do? Google “WooCommerce web agency”. Is it a marketing website? Google “WordPress web agency”. These, along with the recommended suppliers in WooExperts, can be a good starting point for your procurement.

Geography, location and language

Today, the Internet and digitalisation have created a world where it is possible to collaborate over long distances. This has created opportunities that weren’t possible before, but ultimately there are things that are still worth considering.

Is it possible to meet the supplier for physical meetings?

Although collaborations today work well over large physical distances and physical meetings are not needed as much, it is still valuable to be able to meet.

If the supplier is more than 20 miles away from the nearest office, physical meetings can be difficult to organise. This is definitely worth taking into account.

What legal recourse is there if something goes really wrong?

If a supplier is located abroad, this supplier does not operate under the same legal framework as Swedish companies. This can affect, for example, how personal data and sensitive data are handled at the company. In Europe, from 25 May 2018, all companies must comply with the EU’s data protection rules, the GDPR (General Data Protection Regulation). This means that choosing a supplier outside the EU who is not fully aware of the legislation can cost your company huge sums in fines.

In practical terms, the GDPR means many different things, but for example, the supplier must anonymise order data when processing it to the various testing and acceptance environments in an automated way.

What language does the supplier communicate in?

What usually goes wrong in a project, no matter how well the requirements are written, is always communication. Therefore, it is important to try to prevent possible problems in communication as far as possible. The easiest way to do this is to set requirements for the language in which the supplier communicates.

Does the provider have the right range of services and size?

An important aspect when choosing a supplier is whether the supplier’s service offering is simply compatible with what you want to do and whether the supplier is capable of delivering throughout the lifecycle. This is normally related to the size of the company as very small suppliers and individual freelancers are not able to spend the time and energy on process and skills development that a larger company is able to do.

Does the agency have a diverse range of expertise?

Different agencies specialise in different things. To carry out really good projects, it is good if the agency has many different competences that contribute to the overall competence of the company. Even though it may be that the system administrator or AdWords expert will not be doing much in your particular project, it is still valuable for the future that this expertise is available at the supplier. Knowledge tends to spread when clustered together and this will help ensure that the advice and decisions taken favour the success of the project.

Does the agency do everything between heaven and earth?

Does the agency have a clear focus, or do they do just about everything? It is not uncommon to see suppliers working with EpiServer, WooCommerce, Magento and Umbraco. There may be a danger in choosing a supplier with too diverse a technology offering, as there is a great risk that there is limited platform expertise.

Does the agency seem the right size?

For businesses that need to be nimble and able to respond quickly to changes in the world, bandwidth is important. If you run a smaller business, it is often natural to look for another smaller business. Smaller businesses are often very responsive and easy to work with, and it is often possible to negotiate a good price as there is no large overhead in the organisation. The downside here is often that you rarely have a well-developed work process for the whole life cycle – you are good at a few things and not very good at many others.

Does the supplier have the right experience?

Experience can manifest itself in a couple of different ways. It can range from the number of years in the industry to the types of customers you are used to working with.

Estimates and spikes

Many of the requirements can take a considerable amount of time to research and therefore cannot always be estimated by the supplier. The fact that the supplier does not know does not necessarily mean that they do not have the experience and expertise, but may instead be because they want to do the right solution rather than make up a figure out of thin air. Conducting small surveys, known as “spikes”, is a common approach. After a selection has been made so that you have 1-2 suppliers left, don’t be afraid to give them time to do a paid survey – it can pay off.

Look for similar work in the portfolio

The first thing to look at when researching a supplier’s experience is to see if there are similar projects among the company’s previous work. WordPress and WooCommerce are incredibly flexible and modular pieces of software and they can be used for a variety of applications. If you are looking for an agency that specialises in WooCommerce E-commerce for example, this is one aspect you are looking for, if you are looking for a web agency that focuses on WordPress LMS implementations, this is something you should look for.

About Certifications, Partnerships and Reputation

WordPress and WooCommerce are built on open source code. This means that just because a vendor claims to be an expert doesn’t mean it’s true. Every time someone mentions that they are an expert, you should take it with a pinch of salt and check if it is actually true.

Certifications and partnerships

In practice, certifications do not exist in WordPress and WooCommerce. What does exist, however, is WooExperts, which is the partner programme for WooCommerce experts. It is not possible to enter this programme without being approved by Automattic, the company that runs WooCommerce and WordPress. This partner programme is the only similar certification available in our industry and should be taken very seriously. It is simply safer to choose a provider that you know has been approved by Automattic.

Number of Open Source projects

Another quality mark you should look at is how many open source projects the supplier has been involved in. The first thing to look for when procuring a WordPress or WooCommerce project is whether the company has contributed improvements to either WordPress or WooCommerce core. If they have done this, it often means that they have a very deep knowledge of the software.

The next thing to check is how many plugins and themes the provider has made available. This is best checked by looking for a wordpress.org profile or a company github account. The advantage of looking at the wordpress.org profile is that there you can see an estimate of how many users a specific plugin has. Normally, if the provider has one or more plugins with many users, they are used to making well-tested solutions that also add a lot of value for their users. These are characteristics that you probably want to take advantage of.

Last in order is to investigate how many projects you have been involved in outside the WordPress and WooCommerce sphere. Perhaps there is an interesting project that utilises exciting technology or is groundbreaking? The fact that it’s publicised means the provider isn’t afraid of being scrutinised at the seams by others even on their side projects.

Participation in industry meetings

Within WordPress and WooCommerce, there are official industry meetups. These are called WordCamps and WooConfs. These are sanctioned by the WordPress foundation and follow strict requirements and guidelines to use this brand. As such, these tend to have committees that decide who gets to give talks based on its perceived value to the audience. Having lectured or organised such an industry event is highly meritorious.

Conclusion

Choosing the right supplier can be extremely difficult. We hope this guide helps you navigate the procurement jungle and find a vendor that will help you take your WordPress ecommerce to the skies.

Want to understand how the GDPR affects your website? Check out our guide on GDPR and your website to ensure you’re compliant and protect your users’ privacy.

Good luck with your e-commerce!