Non-functional requirements in the Application Development Process

Within the development process, non-functional requirements emerge as a pivotal factor. The challenge lies in effectively gathering and processing these requirements, ensuring clarity and direction for every member of the IT team. Join software developer and emagineer Kamil Naja as he tackles non-functional requirements in this article.

Kamil Naja, Warsaw, 24. August 2023

While developing a web application, we typically discover a series of specific functionalities that the application should exhibit.

Some of these might seem obvious to some members of the IT team working on the solution, but others prefer to have them documented in a detailed form to ensure that all of them are implemented or tested. Non-functional requirements can include feedback from the client, their observations regarding the application’s performance, as well as internal agreements among the developers.

To maintain consistent performance and deliver the best possible product, a good approach is to document non-functional requirements in a shared document.

How to gather non-functional requirements

Requirements should be documented in a document accessible to a broader group, which can then be edited and supplemented by stakeholders – individuals directly involved in building and developing the application.

The document can be divided into sections concerning various GUI elements. It’s beneficial to use language that is understandable to all team members. Additionally, examples of implementing specific solutions and functions can be added.

Many functional requirements will pertain to multiple layers of the application. For instance, requirements regarding a table must be implemented in both the front-end and the back-end simultaneously.

An advantage could be adding a description to each functionality, explaining why it’s implemented in a specific manner and what benefits the chosen solution offers.

Many functional requirements will pertain to multiple layers of the application. For instance, requirements regarding a table must be implemented in both the front-end and the back-end simultaneously.

I’d like to emphasize that requirements should be a very specific set of information about how individual user interface elements should function. Let’s avoid statements like ‘the system should have a professional look and respond quickly to user actions.’ This is too generalized an approach to the chosen problem.

The more details and guidelines, the faster and more efficient the implementation process.

It’s also crucial to remember that non-functional requirements are not set in stone. They should evolve and be supplemented with new information, even from the testing phase. A good opportunity for editing arises when answering the question of how a specific functionality should precisely work. Non-functional requirements can help resolve these uncertainties.

Sample non-functional requirements concerning the GUI

Through these specifications, we avoid ambiguities and errors related to pagination:

Table.

The table displays paginated data, fetching only one page from the back-end at a time.

After changing pagination to any page greater than 1 and modifying filters, the table and pagination should once again display page 1.

The initial pagination size is set to 20 records. The user can set the page size to 20, 50, or 100 records. This decision was made in consultation with users.

After deleting a record from the table, we display a loading screen and then show the data again fetched from the back-end.

What are the benefits of non-functional requirements?

Primarily, they make information about the user interface’s functionality available to all project participants. Non-functional requirements can also serve as a checklist to verify successive emerging functionalities. This ensures the application works cohesively, saving users time in learning new features. Testing also becomes simpler.

The team can focus on solving more complex issues without needing to rediscover the application’s operation each time. We eliminate guesswork and highlight the desired interface behaviors.

Knowledge isn’t scattered among team members; everyone has access to it in one place. This will be particularly important when introducing new individuals to the project.

Documenting non-functional requirements also simplifies the creation of subsequent tasks. A developer knows that implementing a functionality also involves meeting non-functional requirements. This way, we avoid repeatedly making the same mistakes.

If we’re concurrently developing several applications that need to be cohesive, non-functional requirements provide an additional advantage. They can be referenced as a collection of best practices when creating GUI. Of course, some knowledge regarding non-functional requirements can be drawn from the team’s experience in previous projects.

Non-functional requirements for a specific application area might suggest that it’s worthwhile to implement it as a shared component. This way, we won’t need to configure it multiple times.

In my opinion, documenting requirements should occur right from the beginning of the project. The amount of work in creating and maintaining the document is minimal, and the benefits we gain from it are significant.