Meteor partnership

How to prepare the specification for the project.

Specification, design, valuation

The initial form of documentation of the future IT product is the specification of the project, describing its basic features, assumptions, and objectives. Its preparation is particularly important in the case of solutions with a large scope, whose correct implementation is very important for the company's operations. In order for the cooperation with the contractor to run smoothly, the initial outline of the project should be carefully presented to its employees. How to properly prepare such specification and what information must be included in it? Let's start from the beginning and ask yourself the most important question.

What is the specification of an IT project?

The specification is a document containing all key issues related to the IT project, the implementation of which will be outsourced to the software house team. It allows the programmers, graphic designers, project managers to present an initial outline of the project (including its most important features and goals), as well as a detailed description of the functionality of each element of our product.

This applies to both the overall appearance and basic functions of the final product as well as the technologies used in it. To simplify it, the specification of the IT project describes how the software should work and what actions the end user will be able to perform. However, the goals of preparing this type of documentation are much more. Looking closer to the next elements of the documentation, you can distinguish a number of sections with a specific value for contractors.

What is the content of the project specification?

via GIPHY

A typical specification primarily contains a general description of the project, including the scope of activities that will be carried out within it. It should also include any additional materials, preferably in the form of convenient attachments - e.g. links to texts, graphics or mock-ups. The technical requirements necessary to prepare a given product remain an important issue.

The specification should specify which devices and operating systems the software will be intended for, as well as what integration they intend to use. When writing about integrations, I mean, for example, a connection to an external invoice system, CRM, storage system or marketing automation tool. It is good to describe how these connections should work and what data should be passed between them.

Another aspect is communication between the front-end (that is, the visual layer - what the user sees in the browser or application) and back-end (the server and operating part). In the specification, it is worth underlining which data sent to the server will be critical to the operation of the application. This makes much easier to design the entire system.

The specification also takes into account the advanced features of the application, that is its individual component modules, actions that can be performed and information contained in the content. The documentation also includes all additional elements that go beyond the standard scope of the project - most often it concerns aspects prepared by other employed entities, dealing with, for example, issues related to hardware support.

Why the project specification is necessary?

Developing projects of software, applications, systems or websites without a proper specification usually fails. This state of affairs is most often the result of the lack of sufficient involvement, improper planning of work or the choice of inappropriate technology, and above all, insufficient communication between the investor and the contractor. All these factors directly contribute to the inability to prepare good project documentation. In many such cases, the customer retains the most important assumptions of the dream product exclusively in his own head, so most details remain unclear to the members of the executive team. Individual tasks and instructions should, therefore, be properly formulated and clearly defined in the form of a properly prepared specification. Otherwise, all communication between the client and the contractors and users will be insufficient, which will negatively affect the flow of information also at the stage of product implementation.

How to convey your vision to the software house team?

via GIPHY

Many elements of the specification should be established at the initial stage of project planning. The basis of this action is above all a skillful determination of the user's needs, to which the final product is directed. For example, in the case of custom-made office software, a team of software house programmers should know the exact scope of the actual needs of office staff in order to be able to determine how the software they create will be helpful for future users.

If, however, the subject of the project is a commercial or service application, the market to which it is directed should be precisely defined - this applies both to a general presentation of the conditions prevailing in a given industry and to specify the products or services offered within it. The specification should, therefore, include all the requirements that the project must meet.

How to determine and meet the needs of users?

An IT product created on the basis of the design should meet the specific needs of users. The specification must, therefore, take into account all the ways that allow it. At this stage, the person ordering the software should be involved in the implementation of the final vision to the same extent as the contractor. However, software house members can provide the necessary support in the process of shaping the concept, providing advice and presenting their own ideas.

In order to provide the team with better conditions to understand the objectives set out in the documentation, it is a good habit to provide the client with market research carried out in relation to the project's assumptions. An important stage in the preparation of project specifications is also the SWOT analysis. It belongs to the basic methods of strategic analysis of the company, allowing to assess the strengths and weaknesses of the project, as well as the opportunities and threats occurring within it. At this stage, the identification of competition and the ways in which the new application will be refined is crucial.

What is the Software Requirements Specification?

via GIPHY

The Software Requirements Specification (SRS) is a useful analytical document which contains all identified, functional and non-functional user requirements. The purpose of its presence in the complete specification is to provide the programmer with the real assumptions of the product based on the project with precise and comprehensible understanding.

The process of preparing SRS is based on a series of analytical interviews conducted with clients, managers, and other shareholders. Next, the available documentation and project-related legal issues are thoroughly analyzed. Team members can at any time refer to a concise, clear and transparent document that is a real help in the preparation of a good quality product.

What information should be provided in SRS?

The Software Requirements Specification should be prepared only after delineating the main assumptions of the project. Its content, however, must take into account several equally important aspects. What matters is not only the purpose of the software being used but also the way its external interfaces operate. The expected product performance, as well as its main functions, are also taken into consideration. The specification should take into account the presence of improvements, for example, related to facilitating access to technical maintenance or increasing the level of user safety and privacy. Not without significance are any restrictions imposed by the investor's will, resulting, for example, from applicable standards, rules regarding the integrity of databases or insufficient resources available.

Why is it worth to prepare an SRS?

A correctly made specification of software requirements is not only a complete source of knowledge, but also a solid basis for the contract concluded before the actual start of work. It is a reference point at the stage of forecasting deadlines and costs of implementation, and at the same time, it gives the possibility to significantly reduce the necessity for additional work by the software house.

Preparation of software requirements specification also makes it easier for the team to define their own requirements and thus reduce the need for any changes in the code.

The investor can also present in the SRS specification an early idea of the software interface, including a verbal description of each module. It is very useful to create additional user activity paths - this means that each functionality can be described in accordance with what customers expect from it.

When is the automation of the specification creation process possible?

Automation of the specification creation process is a good solution for repetitive and previously implemented projects. Automation also works when the documentation does not require any unique, specific or rare information to be included. Shortcuts are not always possible. It is not uncommon that a project only makes assumptions an identical impression, whereas in practice it requires, for example, manual adding of SWOT analysis results - separate for each application or requirements of a specific industry.

You should also remember that the automation of creating specifications allows you to reduce many mistakes made during the staged preparation of documents, and also saves the valuable time of the investor. In order to properly carry out the automation of the project documentation preparation process, you can use the services of an external company. Many such enterprises provide templates of the most commonly used specifications on their platforms.

What is the management of the specification creation process?

via GIPHY

To ensure the maximum value and effectiveness of project specification, you must manage the creation process in a skillful way. If the company's resources allow it, it is worth developing an internal documentation system for future IT products and creating a team structure that will deal with related obligations.

Managing the process of creating specifications requires, above all, formulating guidelines that will facilitate the preparation and testing of such documents. For individual stages of the process, it is also good to define specific goals, targeted, for example, to detect defects in the prepared content. It may be helpful to develop a clear, common performance standard in the team that deals with the preparation of specifications for the IT project.

Therefore, employees who develop good solutions should be rewarded, and those who provide insufficiently optimized content should be sent to appropriate training. The information contained in the documentation should be obtained from reliable sources, eg from users who belong to the potential target group of the software or applications being developed.

What tools can be used to prepare specifications?

When preparing the specification, you must equip yourself with the appropriate tools. In addition to the automation platforms and free templates, it is worth using graphic elements and other forms of visual aids. A good solution is to take into account simple tables and diagrams, and depending on the project assumptions and individual possibilities, also photos and screenshots. All diagrams and graphs are able to present to developers the desired way of working of the IT solution being developed.

A good project specification differs from the poor also by the appropriate style and form of the text. It should not be written in a sophisticated literary language, because it remains primarily a technical and utility document. The overriding principle is to maintain the appropriate hierarchy and structure of content.

The specification should be written concisely and supplemented with a large number of bullets. It is worth using defined and unambiguous terms, especially when quoting prices and limit values. In this way, you can effectively avoid denying the clarity of the message with unambiguous expressions. The content should be above all complete - it should be checked several times if no sections are missing key information.

Is it worth determining the project budget in the specification?

via GIPHY

In the specification for the project, it is very useful to determine the available budget. In this way, the client presents the contractor with the maximum amount that he can devote to the preparation of the order. Based on the estimated budget, the software house team is trying to create the best possible final product. The financial framework should be determined as early as possible to avoid unnecessary misunderstandings at subsequent stages of project implementation. It is not without significance whether the company implementing the project applies hourly rates or fixed prices. Any time limits should also be taken into account. The specification should, therefore, specify exactly when the project should be completed.

How to make a project valuation without specification?

The detailed specification allows you to receive a complete valuation from the contractor. Available input data also give the opportunity to quickly determine the necessary technology. However, a lot depends on whether the project concerns already existing software and issues related to its development, or whether it involves creating a completely new digital product from scratch. For budgetary reasons, it is not uncommon to refrain from preparing specifications.

In this situation, it is best to send a regular inquiry to the software house. It should define the purpose of IT product creation, its target group, and overall vision, together with business logic. It is also worth immediately concretizing on what platforms and devices will be implemented software or application. The scope of the planned project, including defining the need to prepare a graphic side and specifying the completion date, is not without significance. These data allow the company to pre-define the overall shape of the project, which is usually enough to make an estimate.

How to check the correctness of the specification?

via GIPHY

Applications and other products developed by the software house team are unfortunately not tangible. Their value is relatively elusive, and the actual usefulness of the solutions used can often be assessed only during direct use.

At most stages of developing project specifications, it is necessary to handle very abstract issues and then dress them in clear words for members of a given team. To check whether the documentation created by yourself, by the employee or subcontractor meets the basic requirements, it is worth asking for the most competent person to be assessed. Developers can, for example, verify that all key information is clear to them after reading the specification. If possible, it is also a good idea to consult potential end users of the software or application being developed. They are able to provide valuable advice, for example by suggesting what additional features and solutions would be a great convenience in handling a ready-made solution.

Conducting these activities usually allows you to save many hours of additional analysis. Thanks to the consultations, it is also possible to effectively prevent the possibility of conducting work in the wrong direction, as well as to avoid the risk of overlooking important functions of the final product.

How to proceed after passing the specification?

In the beginning, it is best to discuss in detail the order of the programmer's team manager. In this way, you can explain all concerns related to communication and ongoing processes. The project manager should first and foremost be asked how new ideas can be submitted to him. Both preferred communication tools and the structure of its flow are important.

It is also worth specifying the type of model on the basis of which cooperation will be based. Issues related to the management of the work organization, including the form of notifications in the case of delays or unexpected issues, remain important. During the conversation, you can also find out which software house employees will be responsible for the project and what customer requirements are they able to meet.

Another thing worth checking is how the priorities of a given project translate into estimates, iterations or processes initiated by team members. The way in which the final product will be distributed and how the client can help in the process of its development is not without significance. Before starting a conversation, you should also prepare for questions asked by the project manager. Usually, they relate to issues related to owning servers, suggesting the use of preferred tools and the possibility of consulting a technical director or another technical employee of the company.

When will the project development start?

via GIPHY

The project specification should include a complete set of information on the course of the entire implementation process. Before the inaugural start meeting, it's worth making sure that all team members have access to key data. This applies first of all to information related to the possible division of duties - a team of programmers may, in fact, carry out all work, or share a part of the project with another team. In the latter case, the good organization of work between these two groups is crucial.

You must also include all available communication channels. The best solution is to combine weekly calls and daily updates using various project management tools. Sending summaries by email can cause problems, and later finding a conversation history in our email program is very problematic.

The start-up meeting itself is usually very similar. The software house team is introduced in detail in the subject, which allows assigning specific roles to individual employees - main programmers, the project manager responsible for communication and software testers who will detect any possible project errors. At this stage, the first issues related to the application architecture as well as the choice of communication tools are discussed. In the end, an intermediary server is created, which both members of the development team and the client have access to.

Why is it worth creating a project specification?

via GIPHY

Preparation of a good project specification requires a bit of theoretical knowledge and practice. Much also depends on the skills of the team of employees who are involved in the preparation of the initial documentation.

However, it is very important for every software house employee to prepare well for the client project. In turn, the customer has the full right to know all the processes involved, including the organization of work on the commission entrusted to the team. Only appropriate communication routes can help, which significantly improve cooperation within all stages of developing an IT product. However, they are not able to function without a precisely developed specification of the project. The entire process should, therefore, be carefully planned - thanks to this, all employees will get to know the objectives, assumptions and necessary functionalities of the prepared software or application, and the client will gain full insight into the implementation of the work.

Sample project specification

1. Introduction

1.1 Purpose, reason

Identification of our product whose requirements have been specified in this document. Describe the scope of the product, application, website that will be covered by this specification.

It may happen that this document covers only a certain range of functionality. So it is part of a larger system, application, or just its individual module. For example, when we have a ready facilities booking app, and we plan to do a micro-service that integrates it with accommodation booking systems, e.g. Booking.com. All this should be described in this specification.

1.2 Conventionalities used in the document

At this point, it is worth describing all the standards used in the specification we create. We assume that they will be respected when writing this document. It is worth mentioning when such things as underlining or "highlighting" have a special meaning.

It should also be noted what are the issues of priority inheritance. Are the priorities of the main point (parent) inherited for its sub-points (children). We can bring this to the login example. When our system must have a registration and login system, the highest implementation priorities may have the functions of registering a new user by means of an e-mail address and password. And much lower, not requiring implementation at the very beginning of creating applications, registrations using social media - because these are not a key aspect of the operation of the entire site.

Of course, this is only an example and the priorities may be determined by you, or with the help of a software house with which you establish cooperation.

1.3. Recipients of the document

Describe exactly for whom this document was created. Was it prepared for programmers, project managers, marketing employees, users, testers or perhaps its creators and should not see the light of day. Thanks to this you will avoid unnecessary complications. When a document is written in technical language, it may not be readable by people who are to deal with marketing or sales. And, without any major problems and ambiguities, it is read by administrators or programmers.

1.4 The scope of the project

This is a place where you should give, of course in a short and customer-friendly way, a description of the software, and its purpose. It is also worth adding the benefits that its creation will bring. For example, reducing the time needed to enter data from various departments that do not stick to standards, to our CRM. Or to get more contact details of potential customers from the form.7

If there is a separate document about the vision that guides the planned production of the software, please refer to it (instead of reproducing its content). If the SRS we are currently working on determines the next version of the product being developed, it should contain our own description of the scope we are to implement. That is a description of only those functionalities that are to appear above what is in the existing system.

1.5 References

At this part, list any other documents or website addresses referred in this specification. These can be descriptions of the user interface, agreements, standards, or specifications of server requirements, devices on which the application sections are provided, etc. Sufficient information should be provided so that the person who will read this document can access a copy of each of the resources mentioned here without bothering people who may not have a clue about it.

2. General description

Write this point so that people who read it can easily understand what your application should do.

Generally, predicting or defining a product's behavior should be avoided to allow future interface designers and engineers to use their expertise to provide an optimal solution.

It is also worth mentioning that usually this point is created from the point of view of the user, customer or marketing department of the company (in the second case it can also be called a marketing requirements document). The requirements are then analyzed by the (potential) creator/provider from a more technical point of view.

2.1 Product requirements

This is the place where we describe whether the product to be developed is another element that is to enter into the family of already existing products, maybe it is to replace the existing application or to be a new independent solution. This will allow the people who read the documentation to determine what topic are they going to face and how to set their thinking.

If in SRS we describe an application that is to enter as an element, the component of an already existing larger system, we have to provide a reference to the requirements of the parent and describe the connections between the new and old system. A good practice is to present here a diagram showing the main components of the system, and the connections that exist between them. When there are or should be connections with external systems, eg with CRM, ERP it is worth to describe it here.

2.2 System interfaces

Describe the environment in which the software will function, including the language(s) of programming, technology, hardware, operating system and all other components or applications with which the solution should co-exist. If you do not know the technology, leave this part for the software house.

2.3 User interface

This is the place where we can write individual views (ie our interface). This may include sample screen images, any standards, layout restrictions, buttons and functionalities that will be displayed to users.

Here you can find information such as keyboard shortcuts, standards for displaying error messages or positive actions. The detailed scope and description of the views should be documented in a separate specification.

2.4 Software interface

Describe the connection between the product being created and other specific software components, including databases, operating systems, tools, libraries and external tools such as CRM, storage systems, or SMS gateway.

2.5 Hardware interface

Describe the logical and physical connections between the software interface and the hardware. This may include supported device types, the nature of the data being processed, and the interaction between software and hardware. You do not have to do this if you do not know what to place here.

2.6 Communication interface

Describe the requirements for the communication features required by this product. It may happen that we want to establish a connection with e-mail, an external SMTP protocol or a web browser.

Identify any communication standards that will be used in the software, such as FTP or API. It is also worth to specify all communication security, encryption and data transfer speed, as well as possible mechanisms used to synchronize data between other systems. For example, connections with Allegro (Polish online e-commerce platform similar to Amazon) or an invoice system.

3. Application functions

This is one of the most important places in the document. We describe features and requirements for a specific product here. In the simplest terms - how to do what we want to create. Then we describe it point by point, view by view.

This section should be the most extensive section of the entire specification. It can be organized according to use cases, user type, mode of operation etc. There are no major restrictions here. Try to ensure that everything you give here can be read later and your recipient can understand, clearly what you meant.

3.1 The first function of the application

This can be, for example, registration, or the homepage of our website. Try to describe it whole - element by element, or function after function.

Each of these items as a separate sub-point.

3.1.1. Priority for implementation.

Regarding the priority, it should be determined whether it is high, medium or low. You can also specify here things such as costs and risks associated with the creation of this part of the project and rate them with a scale from 1 to 5, or 1 to 10.

3.1.2. Sequences of activities

Describe step by step what the user is doing and what are the components of the view on which he operates.

For example, a user after entering the site sees a form consisting of fields:

  • First name and last name
  • E-mail
  • Password
  • The field for acceptance of the terms and conditions
  • The field for accepting the consent for data processing

Specify what fields are required, what is not and what will happen when the user clicks on the submit form button.

3.1.3 Functional requirements

List detailed functional requirements related to the operation of this functionality. List the details of the possibilities in which the case occurs.

For example, to perform this function, the user must have an account in the system and be logged in. Describe how the application should react to errors and incorrect data entered by the user. Requirements should be formulated in a concise and unambiguous manner.

4. Other elements

All other elements that have not been previously described in the document, and which are necessary for the task.

Good luck! And if you have any questions, you can always contact us!

Adam Trojańczyk

CEO of Cat In Black Software House (a software house that builds awesome apps). He was employed by the largest digital agencies. He is also the founder and CTO of Tap To Speak (the award-winning worldwide application).

Let's estimate your project together

Contact us
in case of your project

Call+48 512 483 112
use the form or write to: agent@catin.black

Agent John

Software House Cat In Black

Headquarters:
(+48) 512 483 112 Adam Trojanczyk, CEO
Adam Trojanczyk
In the case of ongoing projects:
(+48) 690 561 365 Maciej Sielecki
Maciej Sielecki
Agent John contact box:

Copyright® Cat In Black 2018