Perhaps, after reading this article, you will catch yourself thinking that I am writing about commonplace things that everyone knows. But in 10 years I have changed only 3 IT companies, in two of which these "banal" practices were not used to the full, the software development process suffered greatly from this. In addition to my personal experience, I was prompted to write the article by the stories of analysts I know who work in the IT field and almost everyone is faced with organizational and communication problems that need and can be solved.
For the last 3 years I have been working as a systems analyst in the InfoWatch group of companies and in this article I want to share with you the practices of working with requirements that we use. The company develops Enterprise products to mitigate information security risks, protect and analyze corporate data. For such products, high requirements are put forward regarding their reliability, performance, fault tolerance, as well as requirements for certification. Due to the peculiarities of the information security market, our solutions are not cloud-based, but are installed on-site at the client. Therefore, we work in a large release mode several times a year. To reach the assigned goal and shorten the release time, we work according to the principles laid down in the Agile methodology.To start development, we do not prepare absolutely detailed system requirements, but start with a high-level description of the most important aspects of the new functionality. That is, we make decisions that most of all affect the volume and complexity of improvements and provide the development team with the necessary information to start work on architecture design and writing code (for small features). Then, in the course of development, we gradually detail the requirements and bring them to a level of detail sufficient for writing detailed test cases. This approach allows you not to spend a lot of time to start work and reduce the risks that the requirements will have to be significantly reworked if any new technical limitations come to light.which most of all affect the volume and complexity of improvements and provide the development team with the necessary information to start work on architecture design and coding (for small features). Then, in the course of development, we gradually detail the requirements and bring them to a level of detail sufficient for writing detailed test cases. This approach allows you not to spend a lot of time to start work and reduce the risk that the requirements will have to be significantly reworked if any new technical limitations come to light.which most of all affect the volume and complexity of improvements and provide the development team with the necessary information to start work on architecture design and coding (for small features). Then, in the course of development, we gradually detail the requirements and bring them to a level of detail sufficient for writing detailed test cases. This approach allows you not to spend a lot of time to start work and reduce the risk that the requirements will have to be significantly reworked if any new technical limitations come to light.sufficient for writing detailed test cases. This approach allows you not to spend a lot of time to start work and reduce the risk that the requirements will have to be significantly reworked if any new technical limitations come to light.sufficient for writing detailed test cases. This approach allows you not to spend a lot of time to start work and reduce the risks that the requirements will have to be significantly reworked if any new technical limitations come to light.
If your development process is similar to ours, or you want to move to this combined process, most likely the practices described below are suitable for you. But even if you have a different process, chances are that the practices presented will be useful to you. In any case, I suggest you familiarize yourself with them, especially if you work as a systems analyst in an IT company.
Requirements for the product being developed is the main area of responsibility of a systems analyst. The practices described below aim to simplify requirements management and, as a result, simplify the product development process:
- documentation and versioning;
- notification of changes;
- review;
- rallies / meetings / statuses;
- discussion / solution of open questions;
- logging of discussions;
- validation of new functionality;
- presentation of new functionality.
Documenting and versioning requirements
It is convenient when the description of the product in the form of functional and non-functional requirements is fixed in one document, the requirements are broken down by functional areas, interconnected by grouping, transitions through links, etc. When any changes within the framework of the description of features or as a result of fixing defects are reflected in the corresponding version of the requirements.
The versioning of requirements is the same as for the product itself, which allows you to see the increase in functionality with each new release. And also get quick access to information on how this functionality worked in previous versions and for what reasons it was changed.
In some companies, it is necessary to spend a lot of time to obtain such information, since it is necessary to review all the tasks that are associated with a particular functionality, delve into their description, and view comments. By the way, a faster way to get the information you need is to ask the developer to look at the changes in the code, but in this case it will take not only your time, but also the developer's time, which will cost your employer more. Describing the requirements in one place allows you not only to find the information of interest, but also to immediately understand the context.
We use Confluence, which is a handy tool that you can tweak a little for yourself. A colleague of mine talks about our experience with Confluence in detail in his article “ How We Use Confluence to Develop Product Requirements . " Interestingly, many IT companies have this tool, but not everyone uses it to document product requirements.
Notification of changes in requirements
It is good practice to notify all stakeholders of changes to requirements, which also allows you to monitor when and for what reason the requirements were changed. If above I said that it is important to reflect in the requirements all changes as a result of fixing defects, then here we are talking about notifying the team about these changes.
It is important to understand that requirements are the data that development teams, test teams, technical writers use for their work, and that any changes in requirements need to be supported in the implementation, test cases and documentation.
Failure to notify the teams involved will likely face the following issues:
- the implementation may not meet the requirements;
- ;
- .
Until recently, our team of analysts notified everyone interested about changes in requirements in the following way: after making changes to the requirements, they left a comment on the problem, sent a letter that contains a link to the problem, a link to the requirements and a brief description of the changes. At the end of last year, we automated this process: we finalized the issue-tracker (we use JIRA) and now, after making changes to the requirements, in the task in which these changes were made, we click the "Notify about changes" button, select the interested teams and make a short Description of changes:
Screenshot # 1 The
letter that is automatically generated after clicking on the "Send Alert" button has the following presentation and contains all the necessary information:
Screenshot 2
In addition to the letter, a comment with similar information remains in the problem.
Review of new requirements
It is mandatory to review new requirements by the leads of all teams involved in the development of the feature. We are not talking about changes within the framework of defects, but about completely new functionality, the description of which you are making. Getting feedback is extremely useful, as the right questions may arise that will help to reveal in detail the possibilities of the new functionality. When you develop a thought in one direction for a long time, identify a need, problems, develop different concepts and describe a solution within the framework of the product, the eye may get blurry, and it may seem that there are obvious things that do not have to be fixed in the requirements. The review helps, including through questions from specialists who immerse themselves in the topic through the information they receive in the requirements, to understand what points need to be clarified or disclosed.The review also helps to hone the clarity of the wording, to make changes so that they are unambiguously interpreted by everyone.
To do this, we also improved the issue-tracker, added a separate type of "Review" task, which is launched by the responsible analyst for each feature on all team leaders. Managers independently or delegating to their subordinates make proofreading of requirements, ask questions or make clarifications through comments and agree on the changes made.
Screenshot # 3
Rallies / meetings / statuses
Daily meetings of the team working on the feature is a great event for small teams, as long as they use frequent sprints. Otherwise, daily meetings will take up the whole team's time and will not be of any benefit. However, you should not completely abandon meetings, you just need to correctly determine the frequency of their holding. And then you can keep your finger on the pulse, understand whether the team is moving in the right direction in the implementation of the conceived concept, as well as identify at the early stages problems that can be solved or limitations that need to be agreed.
Naturally, when developing requirements, you need to communicate with the team, as you can learn a lot of useful information. Important moments that happen somewhere in the “black box” can greatly influence the concept of new product features, communication with colleagues helps to draw attention to moments that are interesting for their roles. For example, communication with testers makes it possible to take into account alternative scenarios that are planned to be tested in the requirements and it is important that they are initially laid down and taken into account in the development, and not discovered during the testing phase.
Discussion / solution of open questions
I would like to highlight communication by voice as a separate item, since I consider it important to have live communication, because in the new realities there is no way to discuss issues face to face.
Messengers are more often used, they are well suited for personal correspondence, in which you can use smiles, gifs, etc. to express your emotions. But for work activities this is not entirely acceptable, and as a result, a dry faceless text remains that is difficult for the recipient to interpret, because the perception of this text depends on the mood of the person, his personal attitude towards you, involvement in the dialogue and other factors that do not depend on you.
Therefore, I prefer to resolve issues in the discussion "by voice", that is, to call and discuss, to agree on something. The call will help you find out if you understood the context correctly, immediately ask questions and get answers. The voice conveys intonation, allows you to place the right accents, to pay attention to what is really important. Plus, voice communication saves time for all participants and allows you to concentrate on a specific topic, since voice communication (and not chat) requires participation and understanding to resolve the issue.
Discussion logging
It is absolutely customary and obligatory for everyone to record discussions of decisions with the customer in the form of a TOR, which is repeatedly deducted “to the point” and agreed upon by all interested parties. I would like to draw your attention to the fact that in addition to the official documentation in software development, the written fixation of agreements can be useful not only within the framework of communication "customer-developer", but also within the company / team.
We practice logging team communication when discussing solution concepts and system functionality. Since when working on a feature, several solutions may arise, from which it is necessary to choose one, naturally, questions arise for the team, which, in fact, are discussed at meetings.
As a rule, we keep the protocol in a question-answer format. The protocol also justifies why such a solution was chosen, it is recorded who made these decisions and who coordinated them. But it is important to understand that this is our internal document used in our work, which is not regulated by anything or anyone. The minutes record a discussion on a specific topic and on a specific date, that is, it is needed in order to understand why certain decisions were made or rejected, which questions in general arose and which of them are closed, and which require research to get an answer. ... This is important because in multitasking mode, it is difficult to keep all this information in your head, plus, all interested team members should be aware of and have access to this information. Also, after a long time,you can reread this protocol and find answers to questions in it, or perhaps you will have new thoughts based on the answers. Or you will once again make sure of the correctness of the chosen solution.
Validation means checking the implemented functionality for compliance with business requirements. Before the start of functional testing, the analyst responsible for the feature conducts validation: he checks whether the main scenario has been implemented and whether the behavior of the system meets expectations. This is an important practice that must be used just before the transfer of functionality for testing, since if the main script is not executed, then there is no point in checking other cases. To perform validation, an acceptance scenario is written, containing the steps that must be performed and the expected response of the system in order to ultimately solve the business problem for which the functionality was developed. Within the framework of validation, it is possible to identify, first of all, the failure of the main scenario, the inconvenience of the user interface, as well as gross functional defects.If the main scenario is executed, then the feature is considered validated and can be submitted for testing. Testing is already more detailed, in accordance with test cases, it checks the implemented functionality.
Presentation of new functionality
Another cool practice, in my opinion, is the presentation of functionality before writing test cases or issuing a feature for testing. The presentation is for performers who are not immersed in context the way their leaders are, because they did not participate in the stages of working out the solution. As a rule, this is a short story about what basic and alternative scenarios for solving problems are implemented, what settings in the product need to be made, what technological features this solution has and what limitations. As a result, a general understanding of the new functions of the product is formed and a number of questions that may arise from a person who is not immersed in context are removed.
After testing the functionality, before the official release of the technical release, we conduct a presentation and demonstration of the new functionality for the employees of the departments who are implementing the product at the customer. This makes it possible to get feedback, preliminary designate features and limitations, announce the further development of the functionality. It is important that everyone has a common understanding of the new functionality and does not have false expectations.
Above, I described a small list of practices that my colleagues and I use in our work. I find them useful, so I share them and want to recommend you to build a process for working with requirements using these practices. In the next articles, we plan to talk about the substantive part of working with requirements - in more detail about what practices we use to identify the needs / problems of customers and formulate solutions that will fully cover them.
If you have questions or want to share your experience, please leave your comments.
Author: Venera Abbyasova AbbyasovaVenera
* All pictures for the article are taken from open access on the Internet.