• Home
  • Blog
  • Specification of an IT project – how to write and why is it worth doing?

ORGANIZATION, PROCESS AUTOMATION

17.08.2021 - Read in 9 min.

Specification of an IT project – how to write and why is it worth doing?

17.08.2021 - Read in 9 min.

Innovative companies come up with numerous ways of solving problems. The problems might concern both their employees and potential clients. Irrespective of whether an idea is revolutionary, with a potential to win thousands of users, or just a simple improvement and automation of a process: in order to work, an idea must be put on paper.

Specification of an IT project – how to write and why is it worth doing?

What is a project specification?

A specification of an IT project is a document consisting of a description of what is required of a product.

A specification defines: 

  • the assumptions of an application that is being developed, 
  • its main functionalities, 
  • and problems it is supposed to solve.


Creating it is an introduction to cooperation with a software house, because it allows you not only to present an idea, but also to specify your requirements concerning its execution and implementation.

 

Why should you create a specification of an IT project? 

  • A good specification of an IT project allows a software development company to initially estimate the amount of work, assemble a team, determine what tools will be needed and to preliminarily calculate how much time developers will spend on delivering your project. 
  • A software house will make you an offer on the basis of these assumptions. Thus, at the very beginning, you will be able to decide whether the project lies within your budget.
  • A specification also provides a software development company with information on what values the client upholds and on what market, and in which industry, they operate. This way both parties can decide whether they are suited for cooperation.
  • The analysis of needs and requirements allows a software house to verify whether they have necessary experience, resources and technology required to execute the project.

What is more, a well drafted specification defines goals of a project. It allows a software company to analyse its competition, anticipate potential problems and better decide whether the project should even be pursued.


A specification should not only include the scope of functionalities that are supposed to be implemented, but it should also identify elements that – although not specified – may prove instrumental in its success (e.g. changes in law, the availability of intermediate products, tools, technologies, etc.).

What should a specification of an IT project consist of?

What should a specification of an IT project consist of?

Ok, by far we have talked about the goal and advantages of a well drafted specification. But what should it actually consist of? How precise should be the descriptions of functionalities so that they do not leave too much room for interpretation, at the same time not limiting the pool of applicable technological solutions?

  1. Description of a project

    A well drafted specification does not answer the question of HOW a user interface should look like, how particular components should function or what ready-made elements should be used. It is focusing on the problem and the WHAT that allow a software development company to offer optimal solutions and right technology. (e.g. the company may suggest to use a ready-made solution or to create custom software).

    A general description of a project allows the stakeholders to understand the context and business domain in which the product will function.

    It is a right moment to specify:

    • main needs and the goal that the product is supposed to achieve;
    • a target group (employees of a company, accountants, HR department in the case of an internal solution or users looking for dental treatment in the case of a generally available application).

  2. Functional requirements

    Functional requirements are a description of key functionalities of a new product. They work best when presented in the form of so-called “user stories”, because it allows to present the perspective of different users and recognize the existence of problems that might have been left unnoticed.

    User Story is a popular way of defining requirements. It is based on user history, which is a model of: Who? What? Why?

    Examples of user stories:

    • I am a user of an e-library, who wants to find a book by its title in order to borrow it;
    • I am a potential client of a bookstore, who wants to read reviews of books to decide which one to buy;
    • I work in a warehouse of a clothes shop and I want to see a list of products in an order to know whether the order is complete.

    Creating functional requirements on the basis of user story allows us to look at the product from the perspective of different users, through the lens of their individual needs. It also allows us to create a simple diagram of relationships between particular functionalities and define next steps that the user should take when using the product (user flow).

    When listing functional requirements you might realize that there are so many of them that they should be prioritised. Some of them will be crucial for the achievement of the basic goal of the product, while others will differentiate the product from the competition or just make the users go “wow”. Some of the ideas will be put on the back burner and fulfilled when the budget and time allow for that. 

    A well drafted project specification must address key subjects, which is why you should prioritise them and focus on the most important ones in the first place. At the end of this article you will find a list of the best tools to prioritise.

  3. Non-functional requirements

    While functional requirements are defined as the specification is developed (which seems logical as they describe particular action stemming from the use of the product), non-functional requirements might be somewhat more difficult do define.

    They do not define a function. They focus on quality and everything that takes place “in the background”.
    They appear as less “sexy”, but omitting or ignoring them might result in a product that is attractive, yet useless.

    Non-functional requirements focus on efficiency, compatibility, usability, safety or maintenance.

    They might include:

    • the speed of the app, reactions to particular action taken by the user expressed in numbers;
    • the way in which data are secured (e.g. login data, documents storage);
    • the maximal number of users using the app at the same time;
    • the maximal size of a file;
    • supported Internet browsers and operating systems;
    • deadline and budget – that is right, they are all non-functional requirements;
    • requirements and technological limitations (e.g. typical to a country where the product is to be launched).

    It is extremely important that both functional and non-functional requirements be defined in a clear and detailed way, not leaving too much room for interpretation. It should be borne in mind that instead of phrases such as “little/few”, “many/much”, “fast”, “slow”, a person drafting a specification quotes precise numbers and figures, e.g. the name and size of the font, how many seconds it should take the server to respond, and the size and colour of a button.

    By clearly defining your requirements you will enjoy much better cooperation with a software house and minimise the risk of misunderstanding or the need to hold additional meetings, thus minimising financial losses.

  4.  Design

    My experience in work on IT projects has taught me that the appearance of layouts, the distribution and colour of buttons are a matter of life and death to a client who presents a project to a software house. However, the time spent on design does not always translate into conversion, i.e. the satisfaction of users.

    It is essential for a product to follow the latest design trends, because it makes it attractive and helps differentiate it from the competition. It is worth remembering, though, that well-defined as well as clearly described goals and functional requirements are decisive in whether our solution will reach the users and respond to their needs.

    It is good practice to get a designer to prepare UI mock-ups with specific views, a list of fonts, icons, and colours used in the project. It will make the future implementation much easier.

    So, you already know what a well drafted specification of an IT project looks like and what it should consist of. But how to make sure that you do not go to extremes ? Is it possible to write too much?

Size of documentation RST Blog

Size of documentation. Is 50 pages too long?

Well, as you might expect the answer to this question is “it depends”.

My experience has taught me that a specification might well be both X and Y pages long. Its size will depend on the size of a project and complexity of a problem that you will intend to solve.

Documentation should consist of key information and prioritised requirements, which is why I would strongly recommend you to analyse which of the ideas gets you closer to reaching the goal of the product.

You need to take into consideration the fact that every idea or functionality is another pound, dollar or euro that you will have to spend on the project, and another day added to its original launch date.

 

 

How to define and prioritise requirements? Useful tools

When developing documentation and defining requirements you might use the help of a professional Business Analyst, who will define requirements using appropriate tools, or holding a few sessions of workshops. One of such workshops might be User Story Mapping.

User Story Mapping

The aim of a workshop is to draft a map of a product, define particular functionalities, steps and spontaneous ideas that are later translated into the language of User Story and prioritised. Inviting to the meeting various representatives of business or a potential partner representing a software house might yield unexpected results, such as new ideas and a possibility to present the vision to a group of potential users or creators.

 

MoSCoW

In order to maximise the value of a product that will be able to be implemented within the specified time and budget, a specification of an IT project must bargain for prioritisation of requirements.

MoSCoW is a technique commonly used in business analytics. It prioritises each functionality of a product:

  • Must have,
  • Should be,
  • Could be,
  • Won’t be (this time), meaning „it does not have to be now, but we may come back to it in the future”.

Applying this method will help you prioritise your tasks and even abandon some of them, as at this stage you might decide they are not as important. But do remember that tasks at “the bottom” will be first to “fall out” when you find it problematic to meet the deadline or stay within the budget.

 

Eisenhower Matrix and Action Priority Matrix

The MoSCoW technique will help you identify key elements, but it is equally valuable to learn about other tools that might prove helpful in gaining a broader perspective and making better decisions.

 

One of the most versatile of such tools is the Eisenhower Matrix. It can be modified in many ways, depending on the needs. One of its huge assets is the possibility of objectively judging each functionality in terms of its value added and a quick answer it offers to the question of how to address particular subjects.

I recommend you take a look at this version of the matrix created by guys from Agile Force:

The Action Priority Matrix is another version of the Eisenhower Matrix and it is used to assess the amount of work and influence. This method works best in situations when effectiveness is the key. You can use it when you do not have enough time to do everything, but you want to make the best possible decision.

In the Action Priority Matrix you analyse tasks according to two criteria:

  • the amount of work required to perform a task. 
  • what can be benefited from the task.
Action-Priority-Matrix

Feature Buckets Prioritization

Adam Nash (one of ex bosses of Dropbox) came up with another method facilitating the choice of the best solutions, called Feature Buckets Prioritisation. It assumes that all ideas can be assigned to one of the four groups:

  • Improving the metrics – functions that will have a positive impact on quantitative goals that we have defined, i.e. solutions that increase the number of users, lengthen the time they use the services, etc. They are quantitative, because their results can be quantified.
  • Clients’ requests – suggestions from the “market”. Our users demand that a particular solution be implemented and they inform you about it in no uncertain terms.
  • Extras – innovations and other marvels that are cool, extraordinary or fashionable, but not really necessary. It is hard to quantify their success, but they make you stand out from the crowd and add sparkle to your work.
  • Strategic – finally, ideas that are related to a long-term idea for development. They match the vision and future needs, but not necessarily what is here and now. 
Feature-Buckets-Prioritization

What should you do about them? Once you have divided everything into groups, try to maintain balance, implementing one idea from each group at a time. Yes, you want to strike a golden mean. Be moderate and do not get preoccupied with innovations and metrics. The strategy, vision and ideas of the client are all equally important.

 

Summary

Drafting a good specification of a project, time consuming and demanding as it might be, is crucial from the perspective of product development and relationships with partners. Therefore, use the services of professionals (e.g. a business analyst or a UX/UI designer), because the cost of translating a vision into a specific and comprehensive description of functionalities is incommensurable with the risk of misunderstanding resulting from inaccurate descriptions or incomplete requirements.

A thorough specification addressing most important needs is the key to the success of your product.

Article notes

Share

Marika Witek-Dyrduła

Marika Witek-Dyrduła

Scrum Master

Highly trained individual knowledgeable in Agile methodologies with over 6 years of successful experience in international environment. Certified Scrum Master promoting cooperation, transparency and problem solving, focused on effective communication both in a team and with stakeholders. Considered expert in prioritizing tasks and optimizing workflows. I have proven track record of delivering high-quality software, on-time and within budget.

Our website uses cookies to work correctly. Using this website with current settings means that cookies will be stored in the browser’s memory. Cookies settings can be changed in the browser’s options. For more information please visit Cookies policy.