‍

I think everyone in IT knows this drawing. Personally, I love it 🙂 Few things show how complex it is to create projects and understand the perspective of others. So what is requirements analysis? Today we have a small script for you on this topic.

‍

A bit of theory.

‍

Analysis of requirements, to put it simply, agreeing on customer requirements and their analysis. The goal is to determine, above all, the scope of work, execution time, and costs of a given project.

‍

There are 3 types of requirements. Referring to the BABOK definition, we have:

1) Business requirements

2) Stakeholder requirements

3) Solution requirements

‍

Let's look at them one by one.

‍

1) Business requirements - are the basis and the resultant of the initiated change. They are related to the needs and goals of the organization. Therefore, we will learn from them what the company wants to achieve with the new system or product, what are the expected benefits and what problems are to be fixed.

Business requirements may include:

- increasing operational efficiency,

- improving customer service,

- reducing costs, increasing profits,

- automating business processes,

- and many, many more.

‍

2) Stakeholder requirements – these are stakeholder requirements that must be met to achieve business requirements. They are something like a bridge between business requirements and solution requirements (description below). They must support business requirements. Importantly, they are often written together with the writing of business requirements. Everything depends on the complexity of the structure and the number of stakeholders.

Who can be a stakeholder? Clients, management or project team.

‍

‍

3) Solution requirements - these are requirements described in much more detail that allow you to talk about the possibilities and features of the solution.

They are divided into:

‍

- Functional requirements

- Non-functional requirements

‍

Functional requirements - they answer the question of what will you get as a result of the operation of a given system/application? So how will the functionality behave? What processes will it implement? What information will it manage? The functional requirements describe what the system should enable users to do.

Important note

Good requirements documentation should not impose a specific architectural solution. The analyst should talk about the system and describe it in such a way as to present the available functions and capabilities of the application without undue technicalities.

‍

Non-Functional Requirements - these requirements do not describe what the system will do, but how it will do it. Under what conditions will it work effectively? What standards should it meet?

Examples of non-functional requirements include, for example, system response time, scalability, ease of use, data security, compatibility with other systems, availability on different platforms, etc.

‍

‍

Additionally...

In addition to functional and non-functional requirements, we can also find, for example, the following requirements:

- technological - these are requirements related to the technologies used, platforms, programming languages, databases, etc. Technological requirements specify which technologies should be used to build the solution. To give an example, a technological requirement may indicate the use of the Java programming language, the Spring framework and the MySQL database.

‍

- integration - these are requirements for integration with other systems, services or resources. Integration requirements describe how a system should communicate and interact with other systems. They may include integration with external systems using APIs, data exchange in a specific format, data synchronization, etc.-

‍

performance - these are system performance requirements, such as response time, throughput, support for a large number of users, etc. Performance requirements therefore specify the expected performance parameters that the system should meet.

‍

As you can see, there is a long way to go before starting development work 🙃 The clash of expectations and verification of possibilities takes place at almost every stage of the project, but what we collect at the beginning is our base, the starting point.

‍

And promised practice 🙂

This is how the theory looks like. And what do practitioners say? What is really important when collecting business requirements? Here are some tips.

‍

1) Communication.

Develop an attractive and understandable communication and information process. We are talking about both tools (you can use Murals, Miro and others), i.e. the layout of the information provided, sections for recipients, but also communication channels. It is important that access to the requirements is wide, so that stakeholders can view them, "reflect their thoughts".

‍

2) Process maps.

The result of the former may be process maps. It is known that people are visual creatures. Showing something on a graph, a mind map, often allows you to better understand the needs, context, dependencies and influences.

‍

3) Model. And how to write in detail? This of course depends on what function/system we are working on. Sometimes it is enough to write/draw something on the map at the level of a given system, sometimes it will be necessary to look at the problem more broadly, looking at the system as if from the outside.

‍

4) Know where you are going.

It is worth building a feeling that what we are writing down and talking about now will affect the success of the entire project. The purpose of creating systems and applications is to build working software that will respond to the requirements of the client (i.e. people who will use it). You do not know the needs, you will not create a good product for the customer.

‍

5) It's not time for technicalities yet, but ...

Requirements may be independent of technological guidelines. However, it is important to remember that every situation is different. It may happen that the system or part of it already functions in some ecosystem. Then the assumption that requirements can be collected without a technology benchmark is a mistake. However, as a rule, the requirements are to answer the question of what functions the new system is to provide, so it is enough to describe it in a language understandable for business.

‍

6) Listening.

Sounds like a cliché? Not necessarily. The new system, the application is to be the result of the needs of many people and groups. Therefore, if it is to meet multiple expectations, it is necessary to listen to the needs of stakeholders. What does it mean? Make sure what you hear is the same as what the other party thinks. For this purpose, we may ask auxiliary questions or paraphrase the statements of the other party. Because the thing is not in writing the documentation, but in understanding the problem facing the client.

‍

7) The simpler the better.

Exactly. Written requirements do not necessarily win the Nobel Prize in Literature. But they are supposed to be simple, consistent, and answer the most important questions. Their arrangement and logical sequence are important. Too much detail can interfere with the capture of priorities.

‍

8) The only constant is change.

Unfortunately. As we know, everything flows. However, there's nothing to be offended by. There will be some arrangements that need to be established as relatively unchanging in order for the process to move forward, set in time, but sometimes a flashback, or the proverbial sleep on the subject, can give a really good new perspective. Besides, the outside world is constantly changing, the competition never sleeps. Sometimes you just have to make a decision to change course - it's worth being ready for it.

‍

‍

So much for the introduction. In the following articles, we will go into the details of this process. Be sure to follow our blog.

... And we hope that the penultimate picture won't happen 😆

‍