by Valerii Belaventsev (vebelaventsev@edu.hse.ru)

For the successful development of almost any software product, it is necessary to correctly follow a large number of processes. Requirements capturing is one of the most important and key steps since it determines the vector of further development and what (and how) the final product will do. And a mistake during this process can lead to the fact that a completely different product will be developed. Or the product will not be what the customer wanted indeed, so it will not bring any value for him.

Both functional and non-functional requirements are equally important. But a large number of methods, rules, and strategies are described to collect exactly functional requirements. So, non-functional requirements often remain undisclosed. Therefore, this essay will consider the approaches for capturing non-functional requirements.

IEEE gives the following definition of the non-functional requirement: “In systems engineering and requirements engineering, a non-functional requirement (NFR) is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors. They are contrasted with functional requirements that define specific behavior or functions. The plan for implementing functional requirements is detailed in the system design. The plan for implementing non-functional requirements is detailed in the system architecture because they are usually architecturally significant requirements” [1].

In other words, non-functional requirements describe how the system does, while functional requirements describe what. Also, they are called system qualities [3]. The main types of non-functional requirements are performance, availability, security, data retention, usability, stability, compliance, reliability, recoverability, serviceability, data integrity, scalability, capacity, accessibility, and so on [5].

First of all, for both functional and non-functional requirements, it is important to identify all the stakeholders. Then analyst should ask all of them to elicit requirements. Some non-functional requirements are implicit by nature, meaning that people assume them to exist without being asked [5]. This is the main difficulty of this process, so it is crucially important to ask all the aspects explicitly because stakeholders may assume that some requirements are obvious. Usually, companies use a list of trigger questions to ensure that important aspects are not forgotten. List of example questions [4]:

• Are there any speed, throughput, or response time constraints on the system?
• What kind of documentation is required and who will be the users of the documentation?
• How should the system respond to input errors?
• Is there data coming from (going to) external systems?
• What are the restrictions on the format that must be used for input or output?
• What data managed by the system must be secure?
• Who, when, where should be able to access the system?
• What data must be saved in case of a disaster?
• How quickly after a major disaster must the system be up and running?
• What is the acceptable system downtime per 24-hour period?
• What national, state, or local laws apply to this system, if any?
• What are the projected user growth numbers for the application in the lifetime of the application?

Starting with the list of questions, the discussion can go then into details. Of course, the list may vary from company to company and from project to project. Moreover, for some products, not all questions from the list will generally be acceptable.

One more practice for capturing non-functional requirements is the analysis of market trends or competitive systems. If the system under development has competitors, it makes sense to analyze their strengths and weaknesses. And based on the analysis, possible non-functional requirements can be elicited, which can then be discussed with the customer.

Non-functional requirements can be captured in different ways [2]:

1. As user stories. Some requirements may be defined within the user story. For instance, “As a user, after launching the application, I want to see the main screen within 5 seconds”. This method is good for complex requirements as it allows to skip the requirement implementation for some time, sprints, or releases.
2. As acceptance criteria. For instance, let us have a user story: “As a user, after launching the application I want to see the main screen”. And one of the acceptance criteria is the following: “System displays the main screen within 5 seconds after launching the application”. This method is most suitable for simple requirements which apply to the specific user story.
3. As definitions of done. This method is best for requirements that are applicable for all the solutions or most user stories, like requirements for usability, performance, security, and so on.
4. As separate non-functional requirements specification. This way is most suitable for the waterfall model.

Capturing non-functional requirements is a non-trivial task. These requirements are implicit by nature, so many customers, analysts, and developers do not pay due attention to them, or just skip, considering them obvious, which can lead to misunderstanding between the client and the development team. The non-functional requirements are as important as functional ones, so the analyst must elicit, capture these requirements in the right way. The primary recommended practice for eliciting is just to ask all the stakeholders with comprehensive questions. Of course, it is easy to forget something, so companies usually provide a set of necessary questions. Also, it may be a good practice to analyze the market and the competitive systems if they exist.

There are some practices for capturing and tracking non-functional requirements: as user stories, as acceptance criteria, as definitions of done, and as a separate non-functional requirements specification. There is no good or bad practice. Each of them is suitable for different development models, requirements, and conditions.

[1] Chen Lianping, Ali Babar, Muhammad, Nuseibeh, Bashar, Characterizing Architecturally Significant Requirements, IEEE Software, 2013, pp. 38–45

[2] Lightning Cast: Non-Functional Requirements in Agile, Dave Saboe, 2019, https://masteringbusinessanalysis.com/lightning-cast-non-functional-requirements-in-agile/

[3] Nonfunctional Requirements, Scale Agile, 2021, https://www.scaledagileframework.com/nonfunctional-requirements/

[4] Nonfunctional Requirements, UNIVERSITY OF MARYLAND, BALTIMORE COUNTY, https://www.csee.umbc.edu/courses/undergraduate/345/spring04/mitchell/nfr.html

[5] Non-Functional Requirements, KnowledgeHut, 2021, https://www.knowledgehut.com/blog/agile/non-functional-requirements