🔀 ⏯️ 👎🏼 Educational program for technical specifications 👩🏻‍⚖️ 🌠 🌛

Benefit: gain knowledge of what TK is and how to compile it. Enrich your vocabulary with words: conceptual model, data flow, mind card, user flow. use cases, wireframes, ER-model, client-server, API.

For whom: novice developers and those who want to be understood (by customers, startups and managers).

Reading time: 7 minutes.

Starting point - requirements

I want a cake, then ice cream!
Vovka in the Far Far Away Kingdom

There is a common misconception that it’s enough to say: “You need an application for a museum / cat / plant” and it will immediately become clear what you need.

Unfortunately, this is not so simple. Imagine that you need to build a house. You go to the builder, and he gets to work. You did not provide him with any drawings or plot, you did not even say what color the fence should be. But they gave everything about everything for six months and a significant amount of money.

Spoiler

Terribly true? The budget has already been spent and the deadline has expired.

To prevent this from happening, all the requirements for the product are fixed, this is what any development begins with.

Convenient type of requirements - TK

Knead and chop!
Vovka in the Far Far Away Kingdom

Good. There are requirements. Now the developers will definitely understand you. But here comes the pitfall # 1: humanity has not yet learned to read minds. Therefore, it is necessary in some form to transmit information and the best way for this is the Terms of Reference.

It is also called TK, SRS, PRD - all these are the names of the document in which the product requirements are fixed in the correct form.

Pitfall No. 2: a person’s memory is not unlimited, it is always better to have one place where all your wishes and requirements are fixed (not correspondence in a telegram or phone call). Therefore, TK is a printed text document with the application of diagrams and infographics, not written by hand or photographed. Best in .PDF or Google Docs format.

Recipe for competent TK

The terms of reference for developers is a kind of recipe for a successful product. A successful product is one that is easy to maintain, can be developed and changed, it does not fall apart when a developer changes, and makes a profit in any form. Do you want your project to be complete? Fine. Write a good recipe for this. The classic ingredients (according to the international standard IEEE-830) are:

Conceptual model
Functional card
User path
User interface
Software interfaces
Non-functional requirements

The last 2 points are specific, I advise them to pay attention to readers close to development.

Below I will analyze in detail each of the items. For those who do not want to understand in detail, I leave a link to the international standard with a technical task template: link to a document.

Conceptual model

This item includes a brief description of the product, it reflects the purpose of the project and its distinctive features.

For example: “A dating application where you can watch short videos in user profiles and chat.” It’s also nice to say a few words about the product’s audience, so the project team will be able to understand its features and give you some useful tips. Tell us about her age, character and territorial location, some features that should affect the project.

For example: “These are young people who go abroad for leisure and are interested in communication outside the language barrier, who like to take photos and videos.”

It is worth talking about the types of users and their key differences.

For instance:“The application should have regular users and moderators who receive complaints from users about content or profiles. Moderators can view the chat of ordinary users after a complaint and block an account that violates the rules in the service. ”

And finally, tell us about the components of your product.

For example: admin panel used by moderators; A mobile application that the user uses to register, add content, participate in chat, etc.

Aerobatics will be done by the so-called data flow or context chart, which will reflect how users interact with the product, its components and with each other.

Functional card

The functional map displays the general concept of the project with the level of detail necessary to assess the scope of work and prioritize. In a traditional format, such a map resembles a site map. But it is most convenient to display it in the form of a mind card (mind cards, intelligence cards). Often, managers draw words at the meeting on a blackboard or piece of paper and the connections between them, and so, this is the mind map. This can be done conveniently in free services (coggle, draw.io and mindmeister) or simply in Office Word.

It is very important to reflect all user features in the functional map. In a first approximation, this is simply a set of product features.

For instance: “The application should include registration by mail, creating and filling out profile data, the ability to upload and edit photos and videos, a list of other users' accounts with various types of filters, text chat, and contacting support.

User path

The so-called user flow, or user path, is a sequential list of actions or screens that the user can go through when interacting with the product. Describe how the user will interact with the product in your presentation. Very conveniently this can also be done with a mind map or just a list of actions.

For example: “A user logs in to meet peers. He fills his profile with data and uploads photos and videos. Then the user enters the feed and filters it according to some criteria. As a result, he receives a list of relevant profiles, can look at them and write to another user in the chat.

The user path is a general algorithm for working with the product. There are also use cases (use cases) - this is a detail of user flow. In the case of a mobile dating application, you created the user’s path through the screens, and then describe what the user can do on each screen.

For example: on the registration screen, the user can:
go to the authorization screen, register via social networks (Facebook, Twitter), enter the email, password, then repeat it and confirm the registration in the email.

User interface

The product should not only work, but also look nice. Let's move a little away from the subject matter of applications, so as not to force you to download them for review. Better look at cute sites:

We looked at an example of poor design, now wipe the blood from the eyes and move on to the discussion of the interface. In this part of the technical task, it is worthwhile to attach referees - examples of how you want to see your product. It can be analogues of similar developments or just examples whose design you liked.

Describe in general terms how you want to see your product, what colors it should have, what elements to use, what animation you want, etc. If you have a corporate identity or brand book, excellent, refer to them.

Designers will thank you very much if you specify an interface design style, such as flat design or material design.

Aerobatics will add wireframes (wireframes) - prototypes of the product interface in the form of approximate circuits.

Software interfaces

This section is for professionals. If you are confident in your abilities, then continue reading. The best technical task also describes the architecture of the product, that is, what software components it consists of. In the case of a client-server dating application, the service is divided into a part of the server that stores data and processes it, performs some logical operations and a part of the client that displays the data.

The server is decomposed into modules: databases, authentication, chat, etc. The client communicates with the server through APIs (data transfer interfaces), you should indicate its type (REST, WEB, RPC, etc.) and describe the methods, responses and error handling.

Data is usually stored in the database in the form of special structures, most often tables (for relational databases) and json structures (for non-relational). The developers will thank you very much if in the technical task you specify the database entities (ER-models) and describe the stored fields, indicating their data types (string, int, etc.), keys (primary, foreign), mandatory (required ) and nullable.

Non-functional requirements

These are general product requirements. They can be divided into technical requirements, security requirements and performance requirements. The technical requirements indicate wishes for devices and the operating environment, for example, for dating applications, these are Android 7.0+ and JDK 8+, iOS 11.0+ and Swift 4.2.

In the security requirements, you can specify that the data transfer in the chat should be done using SHA-1 encryption and that when registering, the password complexity should be at least 8 bits. to read a chat message for no more than 1 s and that the application partially stores the cache and can work offline for a limited time.

Advice

PDF, . , .
, , , .
-, , .
, , .
. , .
Get ready to spend more than a few days or consult a professional to write a paper. Competent terms of reference will save you from long discussions of details with the developers and outline clear criteria for the delivery of the project. For example, a full-fledged TOR according to the IEEE-830 standard, attached to the development contract, is an argument in court in case of failure to comply with the requirements.

Educational program for technical specifications