Business analysis – gathering requirements and managing them

Business analysis is needed for the smooth functioning of every enterprise. The success of many IT projects run by the company, its development and the results obtained depend on it. If it is carried out in a correct and meticulous way, it will certainly facilitate the performance of many duties. However, if it is done unreliably, it can have a lot of negative consequences. To prevent this from happening, it’s worth finding out how to conduct a proper business analysis of a company. In this, pay attention to collecting requirements and managing requirements.

  
What is collecting and organizing requirements?

Business requirements or system requirements are an important element in IT projects. For this reason, analysts have made a lot of effort to develop the right techniques for obtaining them. The ones that will work in various projects – more or less detailed. Thanks to the acquired requirements, i.e. information about what needs should be met by the IT system and what to include in it, they can start conducting the analysis. This type of information requires a deeper reflection on how the reported needs relate to the overall requirements and principles of the entire project. It may turn out that the new requirements relate to a completely new functionality or radical changes to an existing product.

There are a lot of different requirements in every project. Especially in medium and large projects, where their number can be from one hundred to one thousand requirements. For this reason, they should be sorted first. Organization of requirements is based on adopting a specific description structure. One that all sides of the project will understand and that will facilitate later work on the requirements. Practice shows that this type of structure most often included a description consisting of specific attributes. For example, in the form of a document containing tables. Currently, more often the form adapts to agile methodologies. It can therefore include a User Story in which acceptance criteria are set and for which a mockup is developed. And also issue in a JIRY-type tool, where the implementation method is described. Organizing requirements is a time-consuming task that is not yet work with requirements in itself.

Modeling

The collected requirements should be specified, i.e. create a list of them in any form. Models are also often developed along with specifications. Modeling uses two types of diagrams that are most useful. This is Agile modeling, the opposite of older methods using UML, where all possible diagrams were placed in the project documentation.

In the design documentation, therefore, there is a section of the class diagram describing the entity to which Story relates at a given moment, a business process model or its slice, and most importantly, prototypes that are most significant when communicating with stakeholders. All diagrams are used during ongoing work. If they become outdated, you can simply delete them. There is no need for long-term storage.

Requirements verification

At the moment when the requirements take form, we begin to have a kind of package that we will implement. It is then necessary to verify our requirements. It involves monitoring the quality of the requirements that should be implemented. After all, according to timeless standards, the requirements must be correct – error-free, mutually indisputable, unambiguous, technically feasible and testable. Regardless of how you describe the requirements, these attributes always apply. After creating the requirements specification, check their compliance with the adopted structure and whether they meet the standards of good requirements. If this is not the case, they will need programming improvement soon.

Validation

For agile projects, validation is an integral part of project management. This is because the opportunity to evaluate the product used was appreciated as a way to show the fatal value of the solution and its compliance with the business need of the end user and other company representatives.

Validation is also performed during other stages, e.g. during a refinement or planning session. Its purpose is therefore to confirm whether the requirements are appropriate and whether they meet the business need well. The checked requirement may be correctly written, but it may not accurately describe the real need. Thanks to validation, we are able to catch these types of errors and eliminate subsequent loss of time over the implementation, testing or analysis of the impact of this requirement on others.

How does requirements management work?

Requirements management primarily refers to systems or applications that are built and developed. It is the whole of the activities that are carried out to make the requirements usable, current and available to all interested parties.

Maintenance of requirements

The most important thing is to maintain your requirements. Despite the prevailing trend to create the smallest documentation, not create it at all or only on a regular basis as a result of the need for development without its longer storage. Documentation with requirements is needed in many projects because the participants change, who need to know exactly what to do. The same code or ready application will not provide them. Sometimes, you have to go back to certain functionalities to be able to develop, modify or model them in creating new opportunities. Regardless of the form in which the requirements will be collected – a model, description or prototype, it is necessary.

Setting priorities

Setting priorities, in other words, prioritizing, applies to both traditional and modern projects. It is extremely important in agile methodologies when you have to choose between two requirements. This may be due to various factors. In the case of waterfall projects, it may be necessary to limit the scope so as to fit in the budget and the planned implementation time. Agile projects are primarily about determining the functionality of the nearest application increase. This means that the application should work at the end of the iteration. Therefore, one chooses the scope that will be the most important from the point of view of business value and possible to implement. Prioritization is the responsibility of business stakeholders, and therefore to the Product Owner. However, he needs the role of an analyst who is most often aware of the need to determine the order and also provides the appropriate techniques for it.

Requirements tracking

Vertical and horizontal links should be maintained for all requirements. Vertical are those between requirements. They are very important when analyzing changes in requirements. Horizontal relationships are those between requirements, their implementation and a single test that checks the implementation of the requirement. By tracking this type of relationship in both directions, you will not overlook any phenomena that occur along the way. You will learn all the problems and efforts that you need to make to correctly implement aspects that meet your business needs.

Communicating requirements

Communicating requirements is about informing stakeholders about a change in requirements or about the fact that none of them has appeared at all. This is extremely important information for developers, especially if they are in development, because it means that they will have to implement the functionality in a different way. Communicating requirements is also important for the business side of the project. Here, the message from developers is important. For example, that some functionalities cannot be realized as expected. These types of situations really happen often. That is why it is important to maintain transparency of every situation and for all interested parties.

Requirements status, i.e. the life cycle of the requirements

It concerns the aspect of horizontal relations and maintenance. Most often in projects we deal with a huge number of requirements. Fortunately, we can equip ourselves with the right tools to help us manage them. These include, for example, JIRA or a dedicated tool for managing requirements only. Status programs can be managed without any problems. For example, product blacklog (blacklog is used in projects carried out in accordance with the SCRUM methodology and scrum-like) stores all information about what to do in the product. It is therefore important to know exactly what needs to be done, what is in progress (and at what stage – is it a stage of development, internal testing, or maybe acceptance?), As well as what has already been done and what is archival requirement. What’s more, some statistics that can be kept are also becoming important, e.g. the work efficiency of the development team for a given number of requirements of specific sizes, statistics used to compare product versions in terms of size or the same number of requirements and for other parameters.

Requirements management is a complicated stage of business analysis. However, it is very important because it is an integral part of the life cycle of the entire product. If the product is alive – it is used, there must be requirements for it. In turn, the analyst operating them must be ordered in order to be able to easily use them and improve their work.