Website functional specification example. Hiring a web development company for a fixed price
14 May 2019
Creating specifications for valuation and programming work
There is nothing more boring than the specification of IT work. Once we understand this fact we are able to pay two, three, and sometimes four times less for programming work. If you consider that a client of a programming company will allow it to earn PLN 100,000–150,000 for a small project and over PLN 400,000 for larger ones, does that sound interesting?
If as a customer this sounds familiar, read below to find out how to prepare a specification of requirements for programmers, or immediately go to the end of this article and hand over this task to someone that wants to deal with it.
When do we need specifications?
- Always. When we work on any digital product - web application, mobile application, SaaS, dedicated software, corporate website and even a smaller website.
- When we want to receive the product we care about within a given time and budget.
- The specification of requirements is an essential part of the process called business analysis or IT business analysis, i.e. the stage of analyzing the client's goals and needs and planning the work required to achieve them. The combination of business analysis and the UX Design process can bring above average business results.
Let’s do this
In an earlier entry, we described when to use a fixed price and when to charge for your time and materials, as well as the pros and cons of both models of billing for programming services.
We learned the fixed price model (settlement with an IT company at a predetermined price) is possible when we have clear requirements and set deadlines.
It is the dream of an entrepreneur, a buyer in a corporation, a marketing director, and the obligation of the public procurement department. But it requires work. In return, it gives cost predictability, transparency, and easy contractor management, as payments to the software house depend mainly on the percentage of work done.
I will return to the topic of financial benefit, which I mentioned at the beginning. When working on one of our projects, thanks to the preparation of a detailed specification, we saved over PLN 100,000. How?
First of all, when asking programming companies about the project valuation, we also talked to them about how much the individual elements of the project cost. This allowed us to only leave in the specification for the elements we really needed.
Secondly, even after sending the final product specification to software houses, we received offers in the range of PLN 50,000-150,000.
Specification - main assumptions
The documentation should be programmer-centric. The old rule applies: if you want someone to understand you, speak that person's language.
You can choose one of several ways to create specifications for an IT project. The most developed version is SRS, i.e. the Software Requirements Specification, which contains all the identified requirements - business, users, functionality. It is applicable in any IT project. However, it requires the involvement of a business analyst and software architect.
When dealing with websites and corporate websites, we can use the short version of SRS, and it's best to focus on accurately describing the operation of the website based on graphic designs.
What should the website specification contain?
To answer this question, you need to determine the means by which the software is going to be created. The purpose of commissioned work may be to perform a certain stage of work on the website.
When only a certain stage of the website is required, planning can be based on user stories, i.e. providing functionality according to how users use the program.
The fixed price settlement model assumes the creation of a specific version of the program. Therefore, in 90% of cases, the specification of the programmers work will consist of two main parts: front-end and back-end.
Below is a simple case study: specification of the website as a comment to graphic projects (UI) given to programmers.
The front-end part of the website specification includes:
We divide the documentation into three parts:
- (1) General assumptions and requirements that apply to all front-end work;
- (2) Base elements that repeat in all templates of the implemented website;
- (3) Description of individual website templates.
(1) A description of the general assumptions and design requirements includes:
- list of compatible browsers;
- requirements for Responsive Web Design;
- UI materials describing the interface (link for a clickable prototype, link to a set containing graphic designs);
- materials affecting the content of the application (webfonts, photo examples, video);
- all file links that show the whole project image.
(2) Base elements that repeat throughout the website:
- website footer, also called "footer";
- cookie bar;
- favicons and opengraph images;
- forms styles;
- animations and general styles.
(3) Description of individual website templates:
- subpage 1;
- subpage 2;
The back-end part of the website specification includes:
Information about the structure of the website, data structure, rules of operation of forms, server infrastructure and information about external applications that the web application will be connected to.
A few words about what this means. The website structure (or site map) can be expressed in a visual form using the FlowMap application, and preferably in the form of a table with a URL structure (routing table).
The website data structure consists of logical units or models. Data can be of different types: short text without formatting up to 255 characters (string), any text without formatting (text), any text with formatting and the ability to place images (richtext), etc.
Each of these models is managed from the CMS level. Describe the type of data that can be found in the model properties, the default value, indicate the values that can be omitted by the CMS administrator, confirm if the content of the field can be repeated.
While preparing the specification, we must describe in detail the principles of cooperation with images and video files, which are mandatory elements of any website.
It’s good if the specification contains information about SEO - both at the level of the website itself and its subpages. Each of them needs an individual configuration - title, description, key words, seo-title etc.
The website administrator should be able to manage the navigation structure (website header, website footer, expanded menu). This might seem obvious, but if this is not discussed, it may not be implemented in the CMS (Content Management System) or implemented differently than the customer imagines. Therefore, not only should the principles of website management be described at the general level, but also at the level of individual subpages.
Does the form send data to the CMS? Does it also do it in the form of an email notification? Or maybe it connects to an external system, e.g. Mailchimp or Salesforce? All of this should be included in the specification along with validation or authorization rules. For example, can a CMS administrator edit the content of a query that goes to the system? It’s logical that he should not, but should we assume this, or should we pass it to programmers?
Infrastructure, i.e. the server environment in which the website will operate.
The Story bases its services and applications on Amazon AWS cloud solutions. In principle, every website uses EC2, RDS, CloudFront, SES. It is connected to external analytical systems (Google Analytics, Hotjar, Yandex Metrica) and sometimes to external data processing systems (Mailchimp or Salesforce, as mentioned above).
Why is all this important?
Imagine a project without documentation. What will the end result be? A website without CMS and content management capabilities? Without navigation management? Without SEO management capabilities?
Each of these elements adds or removes work for programmers. It makes the work shorter or longer, sometimes by several minutes, sometimes by several dozen hours. But the customer can only find out about this when they see the finished work received from the software manufacturer.
Each of the elements described above may turn out to be particularly important for the project you manage, they could lead to you having to postpone the deadline, or even prevent it from starting. What losses will you incur then?
Main photo: Nicepik.com