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.

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. 

O post Software Requirements for the Success of your Digital Product apareceu primeiro em SoftDesign.

So, in this article, we will clarify which occasions require Software Development and which require Software Architecture Consulting. To start, let us clarify who the professionals involved in these services are.

What is the difference between a senior developer and a software architect?

 Many people believe that software architect is synonymous with senior software developer. The architect is indeed a developer, but his vision has become broader through the experience he has gained, so he has a complete sense of how solutions work at different levels.

This means that both the developer and the architect master certain programming languages (according to their specialty), but the architect understands more deeply, for example, about how that language interacts with the computer’s memory or how it will behave when using multiple server instances, among other cases. That is, the developer is a user of technology while the architect also understands the mechanism and its inner workings.

It is worth noting that software architects are not all the same. Like developers, they trace their own paths that provide them with knowledge about certain technologies or areas, which makes them experts. From these areas, they understand the deep criteria of functioning, for example: some architects are specialized in cloud services and microservices, others are more knowledgeable about databases, and there are also those specialized in security.

What are functional requirements and non-functional requirements?

One way to distinguish Software Development and Software Architecture Consulting services is to bring them closer to the requirements incumbent on them. Requirements are descriptions of what a particular system must perform – they reflect the client’s need for that specific digital product. There are functional requirements and non-functional requirements.

• Functional requirements: are about what functions the software should have, how it should react to specific inputs, how it will behave in certain situations, and even establishing what the system should not do. An example would be to say that the software must be able to issue bills or that it should allow the user to subscribe to a service. The construction of functional requirements is the responsibility of software developers and, therefore, they are met by the Development service.
• Non-functional requirements: are related to specific qualities and restrictions that the software must meet. There are product requirements such as reliability, efficiency, portability, usability and performance; organizational requirements such as delivery, implementation, and standards; and external requirements such as interoperability, ethics, security, privacy, and legislation. An example of a non-functional requirement is when we say that the software must have an Uptime (availability time) of 99%, or that it must be able to support up to 10,000 concurrent users, or that it must ensure that sensitive data is encrypted to prevent its disclosure. When there is a challenging non-functional requirement that needs planning to be done, then we need Architecture Consulting.

May startups and established companies need both services?

 The differences between the professionals of these services and the requirements with which they work show us that Software Development is suitable for new digital products or services for companies and startups, and also for expanding existing software (which need new features to be developed) in controlled environments. This service has specific methods to help refine functional requirements, define them from a user experience perspective, and quickly deliver the new functions desired.

However, when the problem involves a bottleneck or point of failure in an existing software, or even a major technical challenge at the beginning of a new product, before development it is necessary to analyze and strategically think about the ideal set of technologies and tools for this situation. In this case, Software Architecture Consulting is responsible for providing the answer.

This means that this service will rarely be offered to an early stage startup, as in these cases the innovation is usually not in technology, but in a business model. Now, when the startup starts to grow and is not prepared for this – which sometimes happens exponentially and quickly – it may need Consulting to evolve its technology, increase the capacity for new users, new transactions, to absorb peak usage moments or even to reduce costs caused by vertical scaling.

Examples of real cases

Therefore, the Software Architecture Consulting client, in most cases, already has a digital product in operation, but it needs more than just evolve the functions of that product; it also needs to correct flaws and bottlenecks that already exist or will exist in the future.

Flaws that already exist may be related, for example, to technology gaps. In one of our recent clients, we were called on to help understand why the internal management web system frequently crashes, shutting down the operation and generating losses. The problem was in the database that became incompatible with the updates of the operating system, causing pool connections to crash and, consequently, the whole system crashing. The incompatibility was low-level and difficult to diagnose: it had to do with how the database used the server’s processor. To solve the issue, our team of architects presented some options and guided the client’s team in executing the fix.

Regarding bottlenecks that will exist in the future, these are usually linked to the business growth forecast. We served a client of a financial institution who knew that its number of digital transactions would increase and the software it owned would not support it. Our architects suggested a new stack (set of technologies), including not only the exchange of the programming language, but also of the entire architecture – migrating from monolith to microservice, and with a phased roadmap for the inclusion of API Gateway, Load Balancing, Tracing, Logging and Queues solutions. Each one of these solutions becomes necessary as the company continues to grow, and in this case, our development team was called upon to apply these changes.

Specific teams for each service

It is also worth emphasizing how different the teams in these two services are. At SoftDesign, the Software Development team is composed of developers, designers, testers, product owners and scrum masters, who build software and improve digital products and services using agile methods. In Software Architecture Consulting, the client has a dedicated project architect who makes a diagnostic chart, identifying solutions and planning execution. This can be the responsibility of the SoftDesign team or the client’s own team.

The architect who is working in Consulting also holds frequent meetings with our other architects to explore the issue and exchange knowledge. In other words, the client has access to our entire pool of architects, each with their specific experiences, who can contribute in different ways to the solution of the issue.

Now that you know the best service for your needs, just fill out the form to request a contact from a consultant.

O post Software Development or Software Architecture Consulting? How to choose? apareceu primeiro em SoftDesign.