Non Functional Requirements in SAFe
In the present situation, businesses face huge competition. So, a particular product of a business should have unique features and should work properly. Only then, the product will reach the target audience. To help businesses develop products with unique properties, non-functional requirements can come in handy. You can design a system that rightly meets the requirements of your end-users. You can do this when you understand non-functional requirements and how do they work. You are here to know about SAFe non-functional requirements.
Meaning of Non-Functional Requirements
The non-functional requirement in general is a term used for denoting any needs that explain how the system carries out a particular function. You can understand better when saying that a non-functional requirement will explain how a system should behave. They provide details about the points that evaluate the functioning of a system as against behaviors.
When functional requirements talk about user requirements and product features, non-functional requirements talk about user expectations and product properties.
Non-Functional Requirements in SAFe:
Non-Functional requirements in SAFe or SAFe NFRS explain attributes of a system. These attributes include usability, scalability, maintainability, performance, dependability, and security of a system. The purpose of non-functional requirements is to serve as restrictions or constraints on the system design across varied backlogs.
Otherwise called system Qualities, non-functional requirements are crucial like stories, features, capabilities, and epics in SAFe. The reason is that they make sure of the effectiveness and usability of the entire system. When a system fails in any one of these things, it cannot meet the market and user needs. Even, it cannot meet the internal business requirements. The system cannot meet the compulsory requirements that standard agencies impose. In some instances, non-compliance can lead to considerable legal issues as well. Legal issues can arise pointing safety, security, and privacy of the system.
Non-Functional Requirements are persistent constraints and qualities that are typically visited again and again as part of the Definition of Done. It is done for each Release, Program Increment and Iteration. They encompass all backlogs including portfolio, solution, program, and team.
It is crucial to rightly implement and define non-functional requirements. However, when they are over-specified, there are chances of the solution being viable as it can turn very costly. On the other hand, when they are under-specified or under-archived, the system can turn out to be insufficient for the purpose of development. Therefore, it becomes important for Agile teams to implement, define and explore NFRs in an incremental and adaptive fashion. In fact, this is a skill that they will have to develop for ensuring their success.
Functional requirements are explained in capabilities, features, and User Stories. They denote most of the work in developing solutions that release worth to the user. Of course, Non-functional requirements are subtler compared to functional requirements. Nevertheless, they explain crucial operational qualities needed for the release.
NFRs are not backlogged items themselves:
When talking about SAFe non-functional requirements, many people believe that they are backlog items. But, they are not backlogs themselves but they occur with all backlogs. Rather they are limitations on development that restrict a certain level of design freedom for the team engaged in building the system. These limitations are generally explained in the acceptance criteria for many backlog items. For instance, Single Sign-on (SSO), which is SAML-based is a need for all products in the suite. Here, SAML is a limitation, while SSO is a functional need. In its acceptance criteria, any backlog item that is being built sign-on functionality would refer to the SAML limitation.
Certain quality attributes are important here. They are shortly referred to as FURPS. Here, S stands for supportability, P for performance, R for reliability, U for usability, and F for functionality. In a SAFe environment, the NFR list is generally long. It encompasses many things like accessibility, privacy, resilience, security, compliance, and many others.
NFR Occur With Every Single Backlog:
When it comes to the SAFe environment, NFR occurs with all backlogs as you can understand from the picture below:
Source: Scaled Agile
As NFRs are considerable elements of the solution that Value Streams and Agile Release Train create, they often have an effect on solution trains and ARTs. These NFRs are to be defined by architect-engineers and Solution and system experts in an organization. These teams put these capabilities and features into practice. So, NFRs get into the discipline team-level backlog items list. For quickening the NFR testing and to ensure its continuity, teams use built-in quality practices. They encompass the appropriate Non-Functional requirements into their DOD. Then, they use them as constraints on local implementation and design decisions. Thereafter, they take the responsibility for a certain level of NFR testing themselves.
Even when you take the case of portfolio backlog, they need NFRs. It is something applicable for cross-system qualities like single sign-on. Other examples encompass regulatory standards, security requirements, and open source usage.
Backlog Constraint Role of NFR:
NFRs are modeled as backlog restrictions in the SAFe framework as you can understand from the image below:
Source: Scaled Agile
Non-functional requirements can require many backlog items in the SAFe model. To make sure that the system goes with the requirements, NFRs should have one or more system quality tests.
NFRs can start as enablers that build infrastructure and explore design alternatives to support the limitation. Once they are put into practice, non-functional requirements then require the system and fresh backlog items.
Effect of NFR on Solution Development:
When it comes to SAFe non-functional requirements but also it can have a considerable effect on solution testing. Not only solution testing, but they can also affect solution development as well. Developers and architects should cautiously specify these requirements. In many instances, applying a set-based design will be a good idea. The reason is that it will keep the options open. It will do it by specifying NFRs as a range.
Teams scout the solution space and gain extra knowledge. In turn, they become capable enough to arrive at better economic decisions. The value can indeed be rated at 99.999 dependability. Otherwise, lesser dependability may be more cost-effective with changes made in the operational atmosphere of the system anywhere. Physical limitations like voltage work, volume, and weight can affect solution development in the same ways. Postponing decisions for better knowledge gaining on value and costs can contribute to better economics. The economic framework of the solution should encompass criteria for the evaluation of Non-Functional Requirements. You should see these requirements in the context of trade-offs not only with prices but also with other considerations. Even, these requirements can have an effect on the concerns and knowledge of suppliers.
In SAFe NFRs, Solution Intent is the sole source of the veracity of the solution. So, it encompasses NFRs and functional needs. It also encompasses traceability associations between NFRs and other needs they impact. Even, it encompasses tests used for evaluating them. NFRs play a major role in gaining knowledge of the economics of variable and fixed solution intent.
Like other requirements, some NFRs are fixed and known in advance. On the other hand, others improve with a solution. Non-Functional requirements can have an impact on a wide range of system functionalities. So, it is crucial that you should consider them when you plan and build the architectural runway. Also, you can consider using NFRs for evaluating business features, capabilities, and epics. They can help you with refactoring so that you can gain better knowledge of the solution domain. Further, you can get help with imposing restrictions on maintainability, installation, support, deployment, and production.
Approaches to Implement Non-Functional Requirements:
Many SAFe Agile non-functional requirements recommend that some additional work must be done. These works are to be carried out either presently or in the future. Only then, you can satiate them. However, at times, all your NFRs should be implemented at the same time. On the other hand, in some instances, teams decide to follow an incremental approach when implementing NFRs. The implementation approach that an organization can follow will be decided by the trade-offs explained in the economic framework. To identify the right level of NFR, it is better to make sure that the implementation happens in a manner that will permit different learning cycles.
The implementation of non-functional requirements is affected by the way Agile Release Trains are organized. The Agile Release Trains built around architectural layers will find it hard to execute and evaluate an NFR wholesomely. Nevertheless, trains organized around capabilities will find it easier to maintain, test, and implement systemic NFRs.
Non-Functional Requirements Testing:
Similar to other system requirements, SAFe recommends that non-functional requirements should be tested as well. You can get to learn more about NFR tests from the 4th quadrant of the Agile Testing Matrix. Particularly, you can get to know it under the category of system quality tests. As they have a better scope, NFR tests generally need association between the Agile and System Teams. To brace building quality, teams should make sure to follow the automation approach wherever possible. In turn, they can run tests either on-demand or continuously.
References
- https://www.indeed.com/career-advice/career-development/non-functional-requirements-examples
- https://reqtest.com/requirements-blog/functional-vs-non-functional-requirements/
- https://www.scaledagileframework.com/nonfunctional-requirements/
