We often meet clients with a great idea when they approach us to discuss the solution they want us to build. Some of these clients are already well-prepared when we have the initial conversation, and can clearly express their needs, and how they plan to integrate the new system into their IT environment.
From time to time however, we have a coffee with two or more stakeholders, and when we ask specific questions, it turns out that their idea has not been thought through well enough. When it comes down to the nitty-gritty, sometimes individual stakeholders even have a different understanding about their requirements.
This article gives you some useful advice on how you can prepare yourself and your team before approaching a digital agency such as Cerebrum. It gives you an insight into the questions a professional development partner will (or at least should) ask, to fully understand your requirements. You’ll learn which areas these questions may cover, and what documents you can prepare to support this process — even before you have your first meeting with them.
One of the most important points is that you need to be clear about what you plan to achieve. A strategy paper is neither a comprehensive document, nor the outcome of a business requirement analysis. It aims to outline your strategy, not the requirements. When writing a strategy paper, you should focus on measurable achievements: what will you try to achieve with the new system? When do you want to achieve it? Try to prioritise these points and think about an MVP (minimal viable product). What achievements are required as a minimum to classify the product build as “successful”? What can be delivered in later stages, and which features are simply “nice to have”, but not mandatory? Keep the strategy paper short, and involve all those in your organisation who have a stake in the outcomes in the creation, review and approval of the document.
Do not make the mistake of mixing up this strategy paper with a business requirements document. The strategy paper is about the strategy, not the requirements. It lists what you try to achieve in the mid and long term; it does not list what is required to achieve this, and neither does it provide answers as to how the problem should, or will, be solved.
Another document comes into play once the strategy is clear to all stakeholders. This document describes the outcome of a business requirements analysis. Based on the strategy (the plan for what you’re trying to achieve), this explains what’s needed to attain your goals.
In many cases, it makes sense to work with the agency who will also be developing the product to document these requirements. When you’re at this stage, be careful not to pre-empt or determine any technical solutions. It’s important to focus on clarifying the business requirements, while being neutral towards the technical outcomes.
From our experience, it can be advantageous to work with the same agency that develops the product when establishing the business requirements. The fact that they will fully understand the requirements provides a platform to make better informed decisions when developing technical solutions. On the other hand, we have come across business requirements analysis documents that already assume specific technical solutions. Be aware of this, as it could impede a successful solution if the requirements are not determined from a neutral stance. You have to be certain that the outcome is not influenced by predilection.
A technical specification is a must-have before development commences. That said, designing a solution that meets your requirements should be the responsibility of the developer — and this includes specifying the technical solution.
Our advice when you plan your project with a development agency is this: if their project plan does not contain a proper technical specification phase, find someone else! The development of software without a clear specification is like building a house without a construction plan.
These days, you don’t build one monolithic beast of a solution that does everything. Systems are highly optimised for a specific purpose. You can easily have one system that powers your public website, another system that stores and manages your product data in a central place, and a third system that generates reports. They all communicate with each other and share data; this is called system integration. We often build solutions for clients which smoothly integrate into their business workflow. Our custom-developed systems access product data from one system, use single sign-on (SSO) to authenticate users, and push data to a customer relationship management system (CRM) for reporting.
In most cases, it is beneficial to identify which existing components need to be replaced, and which systems should remain in place – perhaps because they fulfil their purpose and they provide a suitable interface to exchange data. This also applies to new systems (or newly custom developed solutions). Without a modern and secure method to integrate with other systems, they can cause problems in the long run. We often see this with proprietary software: if vendors of closed systems do not offer interfaces that allow developers to integrate with their software, users are locked-in and are unable to exchange data between applications. This is in contrast to open-source software, where developers can review the source code of the software, customise and extend it as required, and even suggest changes to the original developers.
The questions you should ask when you’re planning your next project include:
What systems and solutions already exist in your environment?
Which of these systems provide data that needs to be “consumed” by the new application?
Which systems require data that is generated?
If developers face the task of integrating with existing systems, they require details about the interfaces of these systems (e.g. the type and technology used for the interfaces). For example, what formats can be used to exchange data, and how are the endpoints secured (the authentication method, etc.)? This brings us neatly to the next section.
Any existing documents, outcomes of a requirements analysis, technical specifications etc., help developers understand your situation, your IT environment and the systems that are already in place.
If the new software aims to replace an existing system, manuals for the application are essential to understand its purpose, and how users are currently operating the system. If you aim for an integration with other systems, a technical specification that describes the interfaces (also called API — application program interface) is crucial. If you don’t have these documents on file, contact their vendor or the service provider who set up the system for you.
Desktop and web-based systems feature a UI (user interface). In most cases, you want the visual appearance of these interfaces to reflect your corporate identity and brand. Sometimes this is less important if your end-users are internal staff and are only very limited, but as soon as the system is publicly accessible and accessed by your clients and partners, its appearance should use specific colours, font types, images and your company logo, to name just a few elements. Your organisation may have a style guide and/or a brand guide, documenting the requirements for the visual appearance in detail.
Once built, tested and approved, the new system needs to be deployed somewhere, whether the application will be hosted by your own IT department (this is called internally hosted) or by an external entity. The latter has some benefits: the agency who built the site usually knows the framework inside-out, as well as the exact requirements and best setup for the hosting environment.
They can set up an infrastructure which is tailored to your needs, scalable, highly available, and often integrated with their deployment workflows, which makes maintenance updates straightforward.
However, under certain circumstances you’ll want to host the new system yourself. In this case, you should make sure that your IT staff have the knowledge and resources to maintain the software (e.g. monitoring and deploying security updates as required), and can meet its requirements. Alternatively, you can turn it around, and define the hosting environment as a requirement that the software must meet. However, this approach may limit the number of potential solutions.
Further preparations, or issues which you can clarify before engaging with a digital agency, include the domain name and TLS certificate. A domain name is, of course, a must-have if you plan to build a website or web application. Do you need to register a new domain? Who takes care of purchasing a TLS certificate that provides HTTPS for the system, and what type of certificate is required?
Being prepared is essential before commencing development of your solution. The bigger your team is, the greater the number of involved stakeholders will be. This inherently leads to more opinions, and possibly too many different ideas on how exactly what the intended system should be. By specifying and documenting your strategy and requirements, you can make sure that everyone is on the same page.
Gathering existing documentation and technical specifications for system integration helps a developer immensely. These documents describe the systems, their interfaces and the complexity of data they process. This allows the developer to design a solution that interacts with them as efficiently as possible.
Cerebrum works with clients — small and large — defining business requirements, designing a technical solution and developing your products. These include professional websites, sophisticated web applications and business critical systems.
We are proud of the recent work we have done with Magic Mobility, consulting, developing, and maintaining a wheelchair quoting and ordering system. We are also excited about the launch of an online application for another client, which lets wholesalers manage and order hundreds of tons of agricultural products.
Are you looking for a professional partner? Do you know someone from your network who is in need of a custom solution, or consultancy on how to improve their processes? Give us a call, and let’s catch up for coffee to explore what Cerebrum can do for you.