Creating specifications for valuation and conducting programming work
There is nothing more boring than the specification of IT work. At least until we find out that thanks to it, we can pay two, three, and sometimes four times less for programming work.
And what if I say that it will allow a customer of a development company to earn USD 100,000-150,000 for a small project and over USD 400,000 for larger ones? Does that sound interesting?
If that sounds interesting to you as a customer, read this article 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 handle 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 a product according to our expectations within a given time and budget.
- The requirements specification 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. Combining business analysis and the UX Design process can bring above-average business results.
Let's do this
In the previous article, we described when to use the fixed-price model and when to change for time and materials, as well as the pros and cons of these billing models for programming services.
We learned that the fixed price model (settlement with an IT company with a predetermined price) works best when we have precise requirements and set deadlines.
It is the dream of an entrepreneur, a purchasing manager in a corporation, a marketing director, and the obligation of the public procurement department. But it requires work. In return, it provides cost predictability, transparency, and easy contractor management, as payments for the web development company depend mainly on the percentage of work done.
Value of a Specification
I will return to the topic of financial benefits, 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 a project cost. This allowed us to leave only the elements that we really needed in the specification.
Secondly, even after sending the final product specification to web development companies, we received offers ranging between PLN 50,000-150,000. However, even with the cheapest option, we knew we'd receive the project we wanted.
Specification — main assumptions
The documentation should be programmer-centric. This old rule applies here: if you want someone to understand you, speak that person's language.
You can choose one of several ways to create a specification for an IT project. The most developed version is SRS, i.e., the Software Requirements Specification, which contains all identified business, user, and functional requirements. It applies to 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 how the software will be created. The purpose of commissioned work may be to perform a particular stage of work on the website.
When only a particular 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 billing 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 designs (UI) given to programmers.
The front-end part of the website specification includes the following:
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 the following:
- List of compatible browsers
- Requirements for Responsive Web Design
- UI materials describing the interface (link for a clickable prototype, link to a collection containing graphic designs)
- Materials affecting the content of the application (web fonts, examples of photos, videos)
- All links to files that show the whole project scope.
(2) Base elements that repeat throughout the website:
- Navigation
- Website footer
- Cookie banner
- Favicons and open graph images
- Form styles
- Animations and general styles.
(3) Description of individual website templates:
- Home page
- subpage 1
- subpage 2
- etc.
The back-end part of the website specification includes the following:
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, preferably in the form of a table with a URL structure (routing table).
The data structure of a website 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 put images (rich text), etc.
Each of these models is managed from the CMS level. Describe the type of data that can be included in the properties of the model, the default value, and indicate the values that can be omitted by the CMS administrator, and confirm if the content of the field can be repeated.
While preparing the specification, we must describe in detail the principles of operation 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, keywords, SEO title, etc.
The website administrator should be able to manage the navigation structure (website header, website footer, drop-down 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 expects. Therefore, the principles of website management should be described at the general level and the level of individual subpages.
Forms
Does the form send data to the CMS? Does it do it in the form of an e-mail 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 enters the system? It's logical that they should not, but should we assume this is obvious, or should we inform programmers about it?
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, or SES. They're 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 of this important?
Imagine a project without documentation. What will the 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 postponing the deadline or even preventing the project from starting. What losses will you incur then?
Disclaimer
The sample prices presented in the article do not constitute a commecial offer within the meaning of the Polish Civil Code.
Hero shot: Nicepik.com
Are you looking for a Web Development Company?
