This site uses cookies and other tracking technologies to make possible your usage of the website, assist with navigation and your ability to provide feedback, analyse your use of our products and services, assist with our promotional and marketing efforts, and provide better user experience.

By using the website, you agree to our Privacy policy

Accept and continue

Report a bug

Cancel
61
How-to 12 min read October 16, 2019

How to draw up a development technical requirement specification and what should it be

Author of Serpstat Advanced Tools
Tatyana Boldyreva
Project Manager at AGIMA
Let's suppose you have your own business and you have successfully reached the "We need a website" or even "We need to automate an important business process" phases. You even found guys who would be happy to implement any brave undertakings, but there is one clause: the development team asks to formulate a project technical requirement specification (this is usually called "Give us a clear assignment"). And from that moment, 99% of customers begin to do and write completely not what the contractor asks.
In this article, we will tell you how to independently create a really useful document that will help you understand the problem and not vice versa.

What is the technical requirement specification (and why you do not actually need it)

To begin with, it is the perfect time to figure out the terms: during the process of developing a project we are constantly writing some documents, they all have different purposes and they are written for different sections of the project and different audiences.

At the start of the project, it is important for the team to understand the business task:
  • what business goals should the product under development serve?
  • what tasks should the product solve?
  • who and in what situations will use the product?
  • what are the limitations in terms of implementation?
  • what are the business and product competitors?

Trying to convey the essence of the task to the development team, the customer, in turn, is used to operating with one capacious concept which is the technical requirement specification.

What is a technical requirement specification

This is the document on the basis of which the development team implements the project, and which describes:
  • the purpose of the system to be developed;
  • list of functions and algorithms that should be implemented within the project;
  • interface requirements;
  • integration requirements (including a technical description of the API or any other data exchange format that you intend to use);
  • system architecture requirements;
  • business processes;
  • user cases;
  • development methodology;
  • technological stack (what technologies will be used and why);
  • and many other things.

That is, a technical requirement specification contains comprehensive knowledge about the purpose of the system, functionality and implementation methods and answers the following questions:
1
What components does the system include and how will they interact?
2
What functions and algorithms need to be developed, how and with the help of which technology stack?
3
How should the interface behave?
Obviously, the development of such documentation firstly requires specialized knowledge (therefore, a technical requirement specification is normally written by a system analyst or lead developer), and secondly, an understanding of business goals and objectives.

Conclusion: at the start of the project we do not need a technical requirement specification that describes how to make the system, but a document that answers the question "Why and for whom are we making this system?"

How to formulate business requirements

A document describing business goals and business system requirements is called the Business Requirements Document, or BRD, or business and functional system requirements.

You can draw up such a document yourself if you follow certain algorithms.

Let's consider an example: your customer has a certain business and the feeling (possibly supported by statistics) that the business has started or continues to stagnate.

Business: vinyl record store represented in Moscow by several offline stores.

Issues from the business owner viewpoint: vinyl collectors are not able to regularly visit the store, monitor new items and quickly order interesting goods, and since the business is not automated, all pre-orders are only made by phone, which is inconvenient for both business and the customer.

As a result, the store misses potential profit, increases the load on shop assistants and consultants, has a poor idea of a portrait of its customers and cannot communicate with the audience to the necessary extent to build a further marketing strategy. Plus, some unaccounted residuals constantly appear in the warehouse which distorts the statistics of commodity circulation.

Solution: to develop an online store where a customer can see the entire catalog, pre-order and track the execution of their order, and the seller can ensure timely execution of the order, receive a report on the state of the warehouse gathering statistics on user interests and user behavior along the way.

Well, we have an understanding of the business problem and its possible solutions. It is important here not to start writing a technical requirement specification, but still write the Business Requirements Document (despite the creative itch that encourages you to write a detailed development task).

We start the document with the "Business Goal" item. Our business goals are as follows:
1
Increase the turnover of commodities in stock.
2
Collect data on the target audience for further use in the development of marketing strategies.
3
Reduce the load on store staff thanks to the automated order/payment/delivery functions.
4
Increase the percentage of repeat sales.
If the goals are clear, the objectives of the project also become clear:
1
To provide functions for pre-ordering goods, payment, and delivery.
2
To configure a system for gathering sales statistics.
3
To configure a system for accounting stocks in warehouses.
4
To provide customer return features.
Intermediate result: the list of tasks is formulated where each task is tied to a specific goal (or several ones).

Now we are specifying what the system should be able to do so that each task in the context of each goal is successfully solved. That is, we fixate the main system functions.

The output should look like this matrix:
Objective
Task
System functions
Increase the commodity circulation in stock by increasing sales via the online store
To provide functions for pre-ordering goods, payment, and delivery
  • Manual product listing
  • Downloading goods into a catalog from 1C (automatic)
  • Pre-order by a customer
  • Online payment by a customer
  • Arranging delivery by a customer
Increase the share of repeat sales
To make sure customers return to a store
  • Subscription to the "New Arrivals" newsletter
  • Subscription to the newsletter by genre
  • Subscription to the newsletter by artist
Now the development team understands why the customer needs an online store, what basic functions it should have, and by what parameters the success of the project will be evaluated.

But usually, online stores are not effective if they do not have an interface.

What about the design requirements

Formulating these requirements, many people end up saying something like "I want/I like" format, projecting in this way a personal perception of beauty on a system that first and foremost should be functional and convenient.

It is important to understand that design is not visual art, in relation to which everyone has the right to an opinion "like/dislike", and the interface is not just some kind of interactive picture painted in different colors.

An interface (screens, pages) is just that set of elements (pictures, texts, buttons, checkboxes, interactive forms, etc.), which users will use to interact with your system. And the requirements for it should be justified by the functional purpose of the system and use cases.

To draw a quality design, you need to understand what goals it will serve (the BRD answers these questions), what content will be published, what are the technical limitations on implementation and support.

Interface requirements

Let's say right away — nothing pleases the heart of UI/UX designers and interface designers like references. That is examples of already implemented similar projects.

Designers ask for references not because every creator is a plagiarist in the soul and wants to make their life easier, but because everyone has different perceptions and interpreting formulations like "I want something grassy green and causing a sensation of a summer picnic in my grandmother's dacha" in the context of a specific design tasks is obviously a fortune-telling game on horoscopes, the loss of task meaning and time.

Adding a link to an already working project in BRD is clearly easier than describing each page in detail at the risk of being misunderstood.

Conclusion: it will be much easier for the team to understand the design task if there are the following elements in its description:
1
Description of expectations in combination with a description of the real capabilities of the customer (for example: "we have excellent photos of products in high quality, so we would like to use them in the design"; "we have a beautiful logo and we would like to use its colors in the design of the site"; "we have a lot of good texts describing the advantages of our store, and it would be nice to publish them").
2
The list of restrictions (for example: "do not use the black color"; "there are no high-quality photos of products").
3
Links to popular websites with related topics with a brief description of why you like this or that component.

Remaining within borders

So, we agreed above on what goals our system will serve, what requirements the interface will meet. The next important point is to determine the boundaries of the system and the scope of the project.

System boundaries are a set of system components interacting with each other as part of the execution of relevant business processes.

For example, we understand that the online store will be integrated with some kind of commodity circulation system, from where the online store receives data on stocks and their cost (for example, we have the system "1C: Trade management"), therefore 1C is an important component of the whole system that takes part in such business processes as "Publication of the product catalog on the website" and "Ordering goods by the customer".

The scope of the project is a set of system functions that must be implemented as part of the project "Development of an online store".

If we turn to the example of integration with 1C, then the tasks of integration with 1C fit within the scope of the project, but the tasks of possible improvements of 1C will relate to another project.

Conclusion

1
When formulating the development requirements, we are writing not technical requirement specification, but business and functional requirements.
2
Describe the basic processes which are specific for your business, if possible.
3
When formulating design requirements, we operate with references, and not with personal aesthetic settings.
4
We define the boundaries of the system and the project scope, clearly convey them to the development team and do not go beyond this framework, trying to implement the System-In-The-Broad-Sense-Of-The-Word.
The experience shows that workable systems are released with due quality and on time if these rules are kept.

Learn how to get the most out of Serpstat

Want to get a personal demo, trial period or bunch of successful use cases?

Send a request and our expert will contact you ;)

Rate the article on a five-point scale

The article has already been rated by 0 people on average out of 5
Found an error? Select it and press Ctrl + Enter to tell us

Share this article with your friends

Sign In Free Sign Up

You’ve reached your query limit.

Or email
Forgot password?
Or email
Back To Login

Don’t worry! Just fill in your email and we’ll send over your password.

Are you sure?

Awesome!

To complete your registration you need to enter your phone number

Back

We sent confirmation code to your phone number

Your phone Resend code Queries left

Something went wrong.

Contact our support team
Or confirm the registration using the Telegram bot Follow this link
Please pick the project to work on

Personal demonstration

Serpstat is all about saving time, and we want to save yours! One of our specialists will contact you and discuss options going forward.

These may include a personal demonstration, a trial period, comprehensive training articles & webinar recordings, and custom advice from a Serpstat specialist. It is our goal to make you feel comfortable while using Serpstat.

Name

Email

Phone

We are glad of your comment
Upgrade your plan

Upgrade your plan

Export is not available for your account. Please upgrade to Lite or higher to get access to the tool. Learn more

Sign Up Free

Спасибо, мы с вами свяжемся в ближайшее время

Invite
View Editing

E-mail
Message
Optional
E-mail
Message
Optional

You have run out of limits

You have reached the limit for the number of created projects. You cannot create new projects unless you increase the limits or delete existing projects.

I want more limits