Perhaps after reading this article, you’ll catch yourself thinking that I’m writing about trivial things that everyone knows. But in 10 years I changed only 3 IT-companies, in two of which these "trivial" practices were not used to the fullest extent, this made the software development process suffer a lot. Besides my personal experience, I was inspired to write this article by the stories of my fellow analysts who work in the IT sphere and almost all of them face organizational and communication problems which must and can be solved.
I’ve been working as a systems analyst at InfoWatch Group for the past 3 years, and in this article I want to share with you the requirements practices we use. The company develops Enterprise products for information security risk mitigation, protection and analysis of corporate data. Such products are subject to high requirements related to their reliability, productivity, fault tolerance and certification requirements. Due to peculiarities of information security market our solutions are not cloud-based, but are installed on-site at customer’s site. That’s why we work in the mode of releasing big releases several times a year. To reach the set goal and reduce release schedule, we work on the principles laid out in the Agile methodology. To start development, we don’t prepare absolutely detailed system requirements, but begin with a high-level description of the most important aspects of the new functionality. That is, we make the decisions that most affect the amount and complexity of improvements and provide the development team with the necessary information to start working on architecture design and code writing (for small features). Then, as development progresses, we gradually refine the requirements and bring them to a level of detail sufficient for writing detailed test cases. This approach allows us to avoid spending a lot of time on the start of work and reduce the risk that the requirements will have to be significantly reworked if any new technical constraints are identified.
If your development process is similar to ours, or if you want to transition to such a combined process, the practices described below will probably work for you. But even if you have a different process, chances are that the practices presented will be helpful to you. In any case, I suggest that you familiarize yourself with them, especially if you work as a systems analyst in an IT company.
The requirements for the product to be developed are the main area of responsibility of the systems analyst. The practices described below are aimed at simplifying the requirements process and, as a result, simplifying the product development process:
- documentation and versioning;
- change notification;
- discussion/resolution of open issues;
- Minutes of discussions;
- validation of new functionality;
- presentation of the new functionality.
Documentation and versioning of requirements
It is convenient when the product description 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, cross-references, etc. When any changes within the description of features or as a result of the correction of defects are reflected in the appropriate version of the requirements.
The requirements versioning is the same as the product itself, allowing you to see the increase in functionality with each new release. As well as getting quick access to information about how this functionality worked in previous versions and for what reasons it was changed.
In some companies to get such information you need to spend a lot of time, as you need to review all the tasks which are associated with one or another functionality, delve into their description, look through the 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 not only take your time, but also the developer’s time, which will cost your employer more. Describing the requirements in one place not only allows you to find the information you’re interested in, but also to understand the context immediately.
We use Confluence – it’s a handy tool that you can "tweak" a bit to suit yourself. My colleague talks about our experience with Confluence in detail in his article " How we use Confluence to develop product requirements ". What’s interesting is that many IT companies have this tool, but not all use it to document product requirements.
Notification of changes in requirements
Notifying all interested parties of changes to requirements is a good practice that also allows you to monitor when and for what reason the requirements have been changed. If I said above that it is important to reflect in the requirements all changes based on the results of defect correction, then here it is about notifying the team of these changes.
It is important to understand that requirements are the data that development, testing, and technical writing teams use for their work, and that any changes to requirements need to be supported in implementation, test cases, and documentation.
If you don’t notify the teams involved of the change, you will likely encounter the following problems :
- implementation may not meet the requirements;
- expected test result may not meet requirements and implementation;
- documentation may not match the implementation.
Until recently, our team of analysts notified all stakeholders about changes to the requirements as follows: after making changes to the requirements, we left a comment on the task, sent an email containing a link to the task, a link to the requirements and a brief description of the changes. At the end of last year we automated this process: finalized issue-tracker (we use JIRA) and now after making changes to the requirements, we press the "Notify about changes" button in the task, in which these changes were made, select the interested teams and make a brief description of changes:
The letter, which is automatically generated after clicking on the "Send Alert" button, has the following representation and contains all the necessary information :
In addition to the letter, a comment with similar information remains in the task.
Review of new requirements
It’s mandatory to have the new requirements reviewed by all the teams involved in the development of the feature. We’re not talking about changes within defects, but about a completely new functionality that you’re doing a description of. Getting feedback is extremely helpful, as the right questions can arise that will help you uncover the features of the new functionality in detail. When you’ve been thinking in one direction for a long time, identifying a need, problems, working out different concepts and describing a solution within a product, the eye can get blindsided and it can seem like there are obvious things that don’t need to be captured in the requirements. The review helps, including by asking questions from experts who are immersed in the topic through the information they get in the requirements, to understand what points need to be clarified or uncovered. The review also helps to sharpen the clarity of the wording, to make changes so that they are unambiguously interpreted by everyone.
For this, we also fine-tuned the issue-tracker by adding a separate "Review" task type, which is run by the responsible analyst for each chip on all team leaders. The managers themselves or by delegating to their subordinates, proofread the requirements, ask questions or make clarifications via comments, and approve the changes made.
Daily meetings of the team working on a feature are a great activity for small teams, as long as frequent sprints are used. Otherwise, daily meetings will take time away from the whole team and be of no use. However, you should not give up meetings completely, you just need to properly determine the frequency of them. And then you can keep your hand on the pulse, to understand whether the team is moving in the right direction in the implementation of the concept, as well as to identify in the early stages of the problems that can be solved or limitations that need to be agreed upon.
It is natural to communicate with the team when developing requirements, as you can learn a lot of useful things. Important things that happen somewhere in the "black box" can strongly influence the concept of new product features, communicating with colleagues helps to pay attention to points that are interesting for their roles. For example, communicating with testers allows you to incorporate alternative scenarios that are planned to be tested into the requirements, and it’s important that they are initially laid out and addressed in the development, rather than discovered during the testing phase.
Discussion/resolution of open questions
Voice communication I would like to single out as a separate item, as I think it is important to live communication, because in the new realities it is not possible to discuss issues face to face.
More often used messengers, they are well suited for personal correspondence, in which you can use emoticons, gifs, etc. to express your emotions. But for work activities it is not quite acceptable, and the result is a dry impersonal text, which 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, his involvement in the dialogue and other factors that do not depend on you.
That’s why I prefer to resolve issues in a "voice" discussion, i.e., call and discuss, agree on something. The call helps you find out if you understand the context correctly, ask questions right away, and get answers. The voice conveys your intonation, allows you to set the right accents, to pay attention to what really matters. Plus, voice communication saves time for all participants and allows you to focus on a specific topic, as communication by voice (and not in chat), requires participation and understanding to solve the issue.
It is absolutely customary and obligatory for everyone to record discussions of solutions with the customer, in the form of TOR, which is repeatedly proofread "to the comma" and agreed upon by all interested parties. I want to draw attention to the fact that in addition to formal documentation in software development, the written recording 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 there may be several solutions to choose from, naturally, questions to the team arise, which are actually discussed at the meetings.
As a rule, we keep minutes in a question-and-answer format. In the same way, the protocol justifies why this particular version of the decision was chosen, records who made these decisions and who coordinated them. But it’s important to understand that this is our internal document used in our work which is not regulated by anyone. The minutes record the discussion on a specific topic and on a specific date, that is, they are needed to understand why certain decisions were made or rejected, what 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’s hard to keep all this information in your head, plus, all interested team members need to be aware of and have access to this information. Also, after a long time has passed, you can reread this protocol and find answers to questions in it, or perhaps you’ll have new thoughts based on the answers. Or you might be reassured once again that you have made the right decision.
Validation of new functionality
Validation means checking the implemented functionality against business requirements. Prior to functional testing, the analyst responsible for the feature conducts validation: checks whether the underlying scenario is implemented and whether the system behavior meets expectations. This is an important practice which must be used exactly before sending the functionality for testing, because if the main scenario is not implemented, there is no point in checking the other cases. In order to perform validation, an acceptance scenario is written which contains the steps to be performed and the expected response of the system in order to eventually solve the business task which the functionality was developed for. As part of validation, you can identify, first of all, non-fulfillment of the basic scenario, user interface inconvenience, as well as gross functional defects. If the basic scenario is met, it is considered that the feature has passed validation and can be submitted for testing. Testing already checks the implemented functionality in more detail, according to the test cases.
Presentation of new functionality
Another cool practice, in my opinion, is the presentation of functionality before writing test cases or releasing a feature into testing. The presentation is given to implementers who are not immersed in the context as much as their supervisors because they didn’t participate in the solution development stages. As a rule, this is a short story about what basic and alternative scenarios for solving problems are implemented, what adjustments need to be made in the product, what technological features this solution has, and what limitations there are. As a result, a general understanding of the new product features is formed and a number of questions that may arise from a person who is not immersed in the context are removed.
After testing the functionality, before the official release of the technical release we hold a presentation and demonstration of new functionality for the employees of the departments involved in the implementation of the product at the customer. This gives us an opportunity to get feedback, preliminarily designate features and limitations, and announce further functionality development. It is important for everyone to have a common understanding of new functionality and avoid 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’m sharing them and want to recommend that you build a process for working with requirements using these practices. In the next articles, we’re going to talk about the requirements gathering part, in more detail, which practices we use to identify customer needs/problems and create solutions that will fully address them.
If you have questions or would like to share your experiences, please leave your comments.
Author : Venera Abbyasova AbbyasovaVenera
* All pictures for this article were taken from the Internet.