A simple way to organize requirements at the stage of collecting requirements (or the first step to creating a cozy backlog)

Why, who needs it, how to do it

More than once I asked myself: how would it be so comfortable to organize incoming requirements for the system - at the stage when requirements are only collected, when questions are raised and answers are voiced, and everything is constantly changing and revised, and even when several systems are involved in the implementation, and yet, and also ...
I would very much like to:

• see the relationship: requirement ➝ question ➝ change in demand ➝ new requirement;
• avoid duplication of requirements / questions;
• to track the systems involved in the implementation (from the reverse: so that the representative of each system sees the requirements, the implementation of which is at least somehow related to his system);
• to receive confirmation for each requirement - that yes, the requirement is understood and recorded correctly that implementation is possible;
• to trace the connection with the requirements of another project very similar to our project - in order to have the knowledge that this is already implemented there, and we will simply use the achievements made;

Anyway.

But if you have already solved all these problems on your project, then the text below is useless for you, perhaps, but you will certainly share in the comments - how?

I must say right away that everything described below solves the problem of collecting requirements within the project, where the idea of ​​all this arose, if your project differs from the one described below, then you will not solve all your problems with this tool - you will have to think a bit about what you want , and modify the proposed scenario to fit your needs. But the information below can become the basis for creating your tool and come up with ideas for its implementation.

In my case, this is a project:

• in which several systems are involved (website, CRM, ERP, system for sending letters, etc.),
• accordingly, several executing contractors,
• in which one customer
• and even now a similar system with a similar set of functionalities is being implemented, and we can use these developments (ideas, customer requirements, code) in our work.

Another important note: described below was done using Google Sheets - a tool that provides opportunities:

• simultaneous access of all participants to the document;
• real-time document changes;
• data filtering.

Of course, the service gives a lot more opportunities, but here I have listed the important tasks for solving the problems described in the article.
So,

How to arrange it

In a regular table file on two sheets: Requirements and Questions.
We will analyze each of them separately (and then together).

Requirements

Listed below are the columns in the table on the Requirements sheet.
Date when the claim is fixed. Well, there is no need to explain anything, everything is clear and so. The only thing here you can also specify the source of the request (letter, meeting, personal communication, etc.) if you later plan to use this information somehow.
Block. Requirements need to be divided into blocks - well, this is understandable. But what is really very important: so that the understanding of the boundaries of these blocks is the same for everyone - both for performers and customers.

For example, different participants have a different understanding of the “Checkout” process. Someone here includes the formation of a user basket too, and someone considers these processes separately (because the basket is a separate process with its own set of data exchange scenarios). And then the phrases “at the stage of placing an order, we display such and such” (from the customer) or “we will give you such and such data” (from another system) may have a different final meaning for everyone.

On our project, in parallel with the collection of requirements, we immediately drew the PBX , and we have blocks according to the names of the schemes. In the file, I made this drop-down in the cells of the column:


In Google Sheets, this is done as follows: Data ➝ Validation. In the “Criteria” field, select “List of values”, in the field on the right, we list the names of the blocks separated by commas (in my case, these are the names of our exchanges).

This is very convenient: when forming requirements, it is immediately clear which process the requirement relates to. Plus, you can filter by blocks (display only requirements related to a specific block - I’ll tell you more below). And even when parsing the schemes, you can also immediately make newly appearing requirements.

In the column Essence of Requirement, in fact, contains the text of the requirement. Moreover, I propose to make all the requirements immediately, as soon as they are voiced and fixed in the heads in some form. Then you can delve into them, form new requirements on the basis of them, ask questions (on the “Questions” sheet).
I think that it is better to split the requirements (to reasonable limits, of course) and put them in different lines (there should not be two requirements in one line - this complicates the work with them in the future).
Link to project% project name%. Well, this column is responsible for exactly what I mentioned above: it helps to trace the connection with the requirements of a parallel project very similar to our project.

It is indicated here that: 1) the same functionality is implemented in the framework of another project or 2) the functionality in this requirement is related to the functionality in another project. You can put a laconic "eat" or detail - depending on needs.

The Question column contains the number of the question, on demand (more about the “Questions” sheet below).
There is a column Confirmed - in it the author and the direct executor put their confirmation (yes, the requirement is formulated correctly). On the project, she proposed to do this within two days after the requirement was made (see the column “Date”). And after two days, consider that the requirement is true, even if the mark is not worth it.

Of course, this is far from an obligatory column, but it’s personally more comfortable for me to know that all participants have a common understanding of the requirements.

System - indicates the requirements of the system involved in the implementation.
In the Modified column, the number of the new requirement is entered from the same document associated with the current one (the requirement has changed, it became not relevant, but what is relevant then). More details about the column are mentioned below in the article (in the script in the "Questions" section).

You can also include the Requirement author column in this list , but I didn’t do it myself. in my case, the author was alone, or the demand was voiced and formulated immediately by all. But when requirements are collected from several people, then he is still needed, I think.
You can make the Status column , and in it indicate, for example, the status of the requirement implementation (useful when the project does not require documentation of the requirements, and the tasks are formulated on the basis of backlog or development occurs simultaneously with the formation of requirements): statuses are also formed based on the needs of the project - I will not list possible options here.
I do not advise displaying the status of relevance of the requirement separately. The Modified columns do an excellent job of this (if there is a new requirement, then it is clear that this requirement is no longer relevant, you can also make the crossed out font - for sure) and Confirmed .
And you can also make a column where the priority of the requirement implementation will be indicated - also a very useful attribute. Or a column with the name of the wiframe / layout, where you can see the visual design.
You can include here the same column with the task number in the bugtracker. Or, or the upper-level tasks in the bugtracker can be called by the name of the blocks (schemes), and then, filtering by the “Block” column, you can immediately display all the requirements within the task.

Speaking of filtering. It is very cool! Filtering by blocks (so that, considering the PBX / task in the bugtracker, you can see all the requirements that apply to them), by the system (to see the work in a particular system and form your backlog based on them), something else in the table.

In Google Sheets, this is done as follows: Data ➝ Filter. First you need to select the filtered area (filtering is carried out in columns).

Questions

Contains columns:

• Date when the issue is fixed;
• Block;
• Question;
• Responsible;
• Status;
• Answer;
• Communication with the requirement.

Some of them are discussed above in the “Requirements”. The content of the part is intuitive (for example, “Answer” and “Responsible”). I will write a little of my sequence of work with questions and requirements using an example:

1. We recorded the requirement on the “Requirements” sheet (for example, line 55 ), filled in the information about it in the columns.
2. There was a question about the requirement, recorded the question in the sheet “Questions”, filled in the information in the columns; in the column “Connection with the requirement” indicated the number of the requirement from the sheet “Requirements” (in our example, this is line 55 ) to which the question relates.
3. For the requirement on which the question arose, in the column “Questions” indicated the number of the question on the sheet “Questions”.
4. We got the answer, recorded the answer opposite the question.
5. We formulated the requirement on the basis of the answer, entered it on the sheet “Requirements” (for example, line 60 ). For the requirement, line 55 in the “Modified” column indicates line number 60 .

Well, do not forget to change the status of the question itself throughout the process (you can use the statuses Open, Given answer, Resolved).

In this scenario, we:
Recorded the requirement, asked questions about it, recorded the answer (paragraphs 1-4).
A new requirement was formulated (the old requirement was no longer relevant - paragraph 5).
And now we can trace the change in the requirement (and even by date).

And, of course, do not forget about the filtering options: by blocks, requirements, responsible, status, etc.

In the process of working on each project, the nuances of working in tables will arise - take them into account and add them to your script, change the tables in accordance with them. Do not forget to ask yourself what you need, what is missing now, and then ask again why you need to do this, what problem it will solve, whether it will facilitate or complicate the processes.
Good luck :)