An easy way to organize requirements at the requirements gathering stage (or the first step to forming a comfortable backlog)

Why, who needs it, what to do

More than once I wondered: how would it be comfortable to organize incoming system requirements - at the stage when requirements are only collected, when questions are formed and answers are voiced, but everything is constantly changing and being revised, and even when several systems are involved in the implementation, and and more ...
In this case, I would like to:

• see link: demand ➝ question ➝ change in demand ➝ new demand;
• avoid duplication of requirements / issues;
• track involved in the implementation of the system (from the opposite: that a representative of each system saw the requirements, the implementation of which at least somehow relates to its system);
• receive confirmation for each request - yes, the requirement is understood and stated correctly that implementation is possible;
• to trace the connection with the requirements of another, very similar to our project project - in order to have the knowledge that this is already implemented there, and we will simply use the work done;

And in general.

But if you have already solved all these tasks on your project, then the text below is useless to you, perhaps, but by all means share in the comments - how?

Immediately, I’ll make a reservation that everything described below solves the problems of collecting the requirements of the project, where the idea of ​​all this originated, if your project differs from the one described below, then you don’t solve all your problems with this tool - you have to think a little what you want and change the proposed scenario to your needs. But the information below can be the basis for creating your own tool and push ideas for its implementation.

In my case, this is a project:

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

Another important note: the following was done using Google Tables - a tool that enables:

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

Of course, the service gives somewhere and more opportunities, but here I listed important for solving the problems described in the article.
So,
')

How to make it

In a regular table file on two sheets: Requirements and Questions.
Let's sort each of them separately (and then together).

Requirements

Below are the columns in the table on the "Requirements" sheet.
Date when the requirement is fixed. Well, there is no need to explain anything, everything is clear and true. The only thing is, here you can also indicate the source of the requirement (letter, meeting, personal communication, etc.) if you then plan to somehow use this information.
Block. Requirements need to be broken down into blocks - well, that's obvious. But what is really very important: that everyone has the same understanding of the boundaries of these blocks - both the performers and the customers.

For example, different participants have a different understanding of the process of “Ordering”. Someone includes the formation of a user basket here 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 this or that” (from the customer) or “we will give you such and such data” (from another system) may have a different meaning for everyone.

In parallel with the collection of requirements, we immediately drew a PBX on our project, and we had the blocks according to the scheme names. In the file I made in the cells of the column just such a drop-out:


In Google Spreadsheets, this is done like this: Data ➝ Check. In the “Criteria” field, select the “List of Values” item, in the field to the right, comma-separated, we list the block names (in my case these are the names of our PBXs).

This is very convenient: when forming requirements, it is immediately clear to which process the requirement relates. Plus, you can filter by blocks (display only the requirements related to a specific unit - I will tell you more below). And also when parsing schemes, you can also immediately introduce new requirements.

The essence of the requirement column, in fact, contains the text of the requirement itself. And I propose to make all the requirements as soon as they are announced and fixed in their heads in some form. Then they can penetrate, form new requirements based on them, ask questions (on the “Questions” sheet).
I believe that it is better to split up the requirements (up to reasonable limits, of course) and distribute them in different lines (there should not be two requirements in one line - this complicates work with them in the future).
Link with project% project name%. Well, this column is responsible just for what I mentioned above: it helps to trace the connection with the requirements of the parallel project, which is very similar to our project.

It indicates that: 1) the same functionality is implemented within another project, or 2) the functionality in this requirement is related to the functionality in another project. You can put a concise “is” or detail - depending on the needs.

In the Question column is the question number, on request (more details about the “Questions” list below).
There is a column Confirmed - in it the author and the direct performer put their confirmation (yes, the requirement is formulated correctly). On the project, I proposed doing this for two days after the request was made (see the “Date” column). And after two days, assume that the requirement is true, even if the mark is not worth it.

Of course, this is not a mandatory column, but personally I feel so comfortable - to know that all participants have a common understanding of the requirements.

System - indicates the system requirements involved in the implementation.
The number of the new requirement from the same document associated with the current one is entered in the Amended column (the requirement has changed, has become irrelevant, and what is then relevant). More information about the column is mentioned below in the article (in the script in the "Questions" section).

In this list, you can also include the column Author Requirements , but I did not do it myself, because in my case the author was alone, or the demand was voiced and formulated immediately by all. But when demands are collected from several people, I still need it, I think.
You can make a Status column, and specify, for example, the status of the requirement implementation (useful when the project does not assume documentation with requirements, and tasks are formulated based on backlog or development occurs simultaneously with the formation of requirements): statuses are also formed based on the needs of the project - here I will not list the possible options.
I do not recommend displaying the status of the relevance of the requirement separately. These columns do an excellent job of changing (if there is a new requirement, then it is clear that this requirement is no longer relevant, you can still make the font crossed out - for sure) and Confirmed .
And you can also make a column where the priority of the implementation of the request will be indicated - also a very useful attribute. Or a column with the name of the wiframe / layout where you can peek at the visual design.
You can include a column with the task number in the bugtracker. Or, or call the top-level tasks in the bugtracker by the name of the blocks (schemes), and then, filtering on the “Block” column, you can immediately display all the requirements within the task.

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

In Google Spreadsheets, this is done like this: Data ➝ Filter. First you need to select the filtered area (filtering is carried out by columns).

Questions

Contains columns:

• The date when the question is fixed;
• Block;
• Question;
• Responsible;
• Status;
• Answer;
• Connection with the requirement.

Some of them are discussed above in the “Requirements”. The content of the part is intuitively understandable (for example, “Answer” and “Responsible”). I'll sign for a bit my sequence of work with questions and requirements using an example:

1. Recorded the requirement on the sheet “Requirements” (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 “Questions” sheet, 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 it is line 55 ) to which the question relates.
3. For the requirement on which the question arose, in the Questions column indicated the question number on the Questions sheet.
4. Received the answer, recorded the answer opposite the question.
5. We formulated the requirement based on the answer, put it on the “Requirements” sheet (for example, line 60 ). For the requirement in line 55 in the “Modified” column indicated line number 60 .

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

In this scenario, we:
Recorded the requirement, asked questions about it, recorded the answer (paragraphs 1-4).
Formulated a new requirement (the old requirement has become irrelevant - paragraph 5).
And now we can trace the change in the requirement (and even by dates).

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

In the course of work, each project will have its own nuances of work in the tables - consider them and enter them into your script, change the tables according to them. Do not forget to ask yourself what you need, what is missing now, and then ask again - why do you need to do this, what problem will it solve, will it make it easier or will it complicate the processes.
Successes :)