JellyTech Perspective -> Requirements Analysis – Introduction
Requirements in IT projects. This is where it all begins 🙂 Well, it begins in the head of whoever initiates the change, but requirements are where it all gets written down. Or at least should be. When working in other industries, I always envied IT for having everything so well described and planned. Having worked in this industry for several years now, I understand why it has to be that way. Of course, in practice, not everything is so rosy 😉 And you don't always start a project with a ready-made requirements analysis. But there is a high level of awareness of the need to document them.
Almost everyone in IT knows this picture. I personally love it 🙂 Few things show as clearly how complex project creation and understanding others' perspectives can be.
So what is requirements analysis? Today we have a little script on this topic.
A bit of theory.
Requirements analysis, in the simplest terms, means agreeing on and analyzing client requirements. The goal is above all to define the scope of work, the timeframe, and the costs of a given project.
We distinguish 3 types of requirements. Referencing the BABOK definition, we have:
1) Business requirements
2) Stakeholder requirements
3) Solution requirements
Let's look at each of them in turn.
1) Business requirements — form the foundation and resultant of the initiated change.
They are related to the needs and goals of the organization. From them we learn what the company wants to achieve with the new system or product, what the expected benefits are, and what problems need to be fixed. Business requirements may include:
- increasing operational efficiency,
- improving customer service,
- reducing costs, increasing profits,
- automating business processes,
- and many, many others.
2) Stakeholder requirements — these are the requirements of stakeholders that must be met in order to achieve the business requirements.
They serve as something of a bridge between business requirements and solution requirements (described below). They must support business requirements. Importantly, they are often documented together with business requirements. Everything depends on the complexity of the structure and the number of stakeholders.
Who can be a stakeholder? Customers, management, or the project team.
3) Solution requirements — these are much more detailed requirements that describe the capabilities and characteristics of the solution. They are divided into:
- Functional requirements
- Non-functional requirements
Functional requirements— answer the question: what will you get as a result of the system/application's operation? In other words, how will the functionality behave? What processes will it carry out? What information will it manage? 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 describe the system in a way that presents the available features and capabilities of the application without delving into technical details unnecessarily.
Non-functional requirements — these requirements do not describe what the system will do, but rather how it will do it. Under what conditions will it operate efficiently? What standards must it meet?
Examples of non-functional requirements include: 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 may also encounter, for example:
- Technological requirements — these relate to the technologies, platforms, programming languages, databases, etc., to be used. Technological requirements specify what technologies must be used to build the solution. For example, a technological requirement might mandate the use of the Java programming language, the Spring framework, and a MySQL database.
- Integration requirements — these concern integration with other systems, services, or resources. Integration requirements describe how the system should communicate and cooperate with other systems. They may include integration with external systems via APIs, data exchange in a specified format, data synchronization, etc.
- Performance requirements — these concern the performance of the system, such as response time, throughput, handling a large number of users, etc. Performance requirements therefore define the expected performance parameters that the system should meet.
As you can see, there is a looooooong road ahead before starting development work 🙃 The clash of expectations and the verification of possibilities happens at almost every stage of the project, but what we gather at the beginning is our base, our starting point.
And the promised practice 🙂
That's the theory. What do practitioners say? What is truly important when gathering business requirements? Here are a few tips:
- Communication.
Develop an attractive and comprehensible communication and information-sharing process for all parties. This refers both to tools (you can use Mural, Miro, and others) — meaning the structure of the information shared, sections for different audiences — and also communication channels. It is important that access to requirements be broad, so that stakeholders can review them and "reflect their thoughts."
- Process maps
A natural outcome of the first point may be process maps. It is well known that people are visual. Showing something on a graph or mind map often allows for a better understanding of needs, context, dependencies, and influences.
- Model.
And how detailed should the writing be? That depends, of course, on what function/system we are working on. Sometimes it is enough to write/sketch something on a map at the level of a given system; sometimes we need to look at the problem more broadly, viewing the system as if from the outside.
- Know where you are heading.
It is worth building a sense that what we are now documenting and discussing will influence the success of the entire endeavour. The goal of creating systems and applications is to build working software that meets the Client's requirements (i.e., the needs of the people who will use it). If you don't know the needs, you cannot create a good product for the client.
- Not yet time for technical details, but…
Requirements can be independent of technological guidelines. Nonetheless, one must remember that every situation is different. It may happen that a system or part of it already exists within some ecosystem. In that case, the assumption that requirements can be gathered without a technological benchmark would be a mistake. Nevertheless, as a general rule, requirements should answer the question of what functions the new system is to deliver — so it is perfectly sufficient for this to be described in language that is understandable to the business.
- Listening.
Does this sound like a cliché? Not necessarily. A new system or application must be the resultant of the needs of many people and groups. So if it is to meet multiple expectations, you need to listen carefully to the needs of stakeholders. What does that mean? You need to make sure that what you heard matches the other party's vision. To do this, you can ask clarifying questions or paraphrase the other party's statements. Because the point is not to produce documentation, but to understand the problem the Client is facing.
- The simpler, the better.
Exactly. Written requirements don't need to win a literary Nobel Prize. But they should be simple, consistent, and answer the most important questions. Their structure and logical flow are important. Too much detail can obscure the capture of priorities.
- The only constant is change.
Unfortunately. As we know — everything flows. But there's no point getting upset about it. There will be certain agreements that need to be established as relatively fixed, to keep the process moving forward and to anchor it in time. Nevertheless, sometimes a retrospective, or proverbially sleeping on something, can give a genuinely good new perspective. Moreover, the external world constantly changes and competitors never sleep. Sometimes you simply need to decide to change course — it's worth being ready for that.
That is all by way of introduction. In subsequent articles, we will look more closely at the details of the described process. Be sure to follow our blog...
And we hope that the second-to-last image won't be happening 😆
