Did you know that software requirements could be related to the success or failure of digital products? This happens because they represent the functions, properties, and restrictions that the software must have to achieve its objective. Within the area of Software Engineering, a requirement is defined as a description of what a given system must perform: it reflects the business need for the digital product.
The software has a set of requirements that are divided into Functional (FRs) and Non-Functional (NFRs). This classification makes it easier to understand them, as we will see below.
Do you need help defining your Software Requirements? Fill in the form so we can help you.
Let’s build exceptional software solutions together!
Experience having a reliable partner to your IT challenges. Let’s talk about our unique approach to discover and deliver outstanding solutions.
Functional Requirements
Functional requirements concern the functions and information that the software must have, that is, its behavior: how it must react to specific inputs, how it will behave in certain situations, and even establish what the system must not do.
For example, an application for a financial institution must be able to carry out transactions, payment slips, and make investments. These are three digital product requirements that allow users to perform such functions.
Functional Software Requirements can still be classified according to their level: the most common differentiation is in relation to business requirements, user requirements, and technical requirements.
Non-Functional Requirements
Non-Functional Requirements can refer to the criteria that qualify the functional requirements: they are related to specific qualities and restrictions that the software must meet, that is, they do not refer to functionalities themselves, but are part of the product’s scope.
Non-Functional Software Requirements are sometimes called quality attributes, which means that they are a structured and categorized definition of what is needed to express that a product has quality, according to its specific context.
Like Functional Requirements, they are subdivided into product requirements such as reliability, efficiency, portability, usability, performance, and space; organizational requirements such as delivery, implementation, and standards; and external requirements such as interoperability, ethical, security, privacy, and legislative requirements.
We can exemplify by citing compliance with the GDPR (General Data Protection Regulation), which is a very common NFR nowadays. Another example is stating that software needs to be cross-platform, operating on Android and iOS. Yet another is when we define that a solution needs to use encryption because it handles sensitive user data.
The Transversality of Non-Functional Requirements
For the team building the product, Non-Functional Requirements can be restrictions, standards to follow, or requiring very specific solutions. It is normal, for example, that they need to be resolved at the software architecture level and not in programming because NFRs are “transversal”, that is, they affect all functionalities.
Once, we developed a product that had a very critical Non-Functional Requirement in relation to availability: the application needed to operate 24×7, for three months, as it was one of the applications used in the operation of a reality show. For this type of requirement, an architectural analysis is needed: you need to identify and remove points of failure, create fallback (plan b), and self-healing solutions. The requirement even affects the hardware and infrastructure, which need to work with high-availability solutions so that maintenance can be carried out without affecting the availability of the software.
Where Are the Requirements?
Have you noticed that, despite being one of the central concepts in Software Engineering, it is not so common to hear about requirements? This happens because they ended up associated with a waterfall workflow model, which is bureaucratic and predictive.
It’s not the requirements that are to blame, it’s the professionals: analysts who expected the customer or user to define their requirements and then stick with that list until the delivery. There was no room for learning, feedback, or strategic changes.
This behavior became meaningless when the technology market evolved towards agile, product-focused approaches. The area sought other tools that would help change the relationship between the team and stakeholders, adopting concepts such as OKRs (Objectives and Key Results), product metrics, business objectives, user stories, BDD (Behavior Driven Development), and acceptance criteria.
However, that doesn’t mean the “end of requirements’. These tools represent yet another evolution in the way of defining them, as well as other techniques that had previously appeared. Regarding current tools, they have the following advantages:
● Data-driven and more focused on business impact;
● User-centered – focused on people;
● Less verbose, more focused on interaction than documentation;
● More collaborative, because the work is less centralized in an analyst, as it is more distributed in an interdisciplinary team;
● More change-friendly, that is, they create a dynamic that better accepts product changes and evolutions.
Who Defines the Requirements and When?
This depends on the type of process and life cycle adopted; two concepts that also come from Software Engineering. In an older lifecycle, the norm was for requirements to be defined all at the beginning of the project. It was common to use the term “collect” or “elicit”, that is: the idea was that a Systems or Business Analyst would obtain requirements from users.
Nowadays, in current methods, we start from slightly different assumptions. We understand that for innovative products it is impossible to discover all the requirements at the beginning of the project; that the user needs to provide usage feedback; and that it is the product team’s job to translate that feedback into requirements.
For this reason, building requirements is a collaborative process. The configuration varies a lot, but we can have a Product Manager (PM) working at the business level, defining the product vision, metrics, and business objectives. The Product Owner (PO), who is in direct contact with the development team, facilitates the process of turning big goals into user stories. Finally, the team participates in this refinement, as it is responsible for defining the technical solution that will meet the proposed needs.
