Set requirements for system components, not entire products. Determine which critical interfaces and systems require such requirements. If your users never interact with a part of your product (like an admin panel), setting performance limits for those components can be unnecessary or harmful because your team will put in a lot more effort without obvious profit. In any case, effectively testing non-functional requirements requires some thought and creativity, otherwise expensive heavy testing can increase the risk of significant technical debt or, worse, system failure. 3. Review the non-functional requirements that the API resource model must meet. A payment resource model should (or would have) stricter and stricter non-functional requirements than a sales report resource model. In both cases, there should be a conscious decision on which non-functionals to consider. Even with a minimalist approach, there would be throttling, security, availability, performance, resiliency, logging and monitoring, exception handling, and fault isolation depending on your resource model. The choice of the non-functional should later be a conscious effort and not a mere coincidence. It is good to make a list of requirements (functional and non-functional) agreed with the company. 1.
Approach the functional aspects of APIs from a business perspective. API designs are based on a business resource model. The enterprise resource model symbolizes the business resource being exploited. The business resource can be a sales order or tikkie payments or sustainability reports. You get the idea! Identifying a business resource is very important to ensure that the API is built with a business approach to solving a business problem. It`s good to involve the product owner and solution engineer in asset modeling to have a stage of thinking about design diversity. Start with Google recommendations for regular web pages. Google is very sensitive to desktop and mobile load times. So, if you`re looking for performance guides for regular web pages that all users have access to, check out Google`s page speed information.
The search engine takes into account several scenarios, including connection type, mobile or desktop load, and the type of content displayed. Based on the sum of the factors, it suggests different performance metrics that you can estimate for your website. This is especially important when setting up landing page requirements, as Google may rank your page lower due to its speed. You need to start by defining a standard that best fits your use case and requirements: 7. Think of resilience as readiness. High availability requirements should be treated differently from low availability requirements. Regardless of the infrastructure, whether it is a virtual machine or an application service, availability should be calculated (if possible per operation). Availability can be increased by better infrastructure positioning, such as a higher tier or multiple regions, but availability can also be increased with design patterns such as circuit breaker patterns and pattern patterns. In addition, solutions must be created that fail. Think of self-healing solutions whenever possible.
Approximation estimates during testing and production. You can search for benchmarks for similar products and features, but if this information is not available in the product planning phase, it is difficult for you to provide the metrics. So it`s likely that you`ll be able to articulate these requirements during testing and production before launch. However, you can focus on the quality of the code during the development itself. Because these elements are difficult to measure, you can add additional functional requirements that specify the expected behavior in more detail (for example, maximum response times). Consider architectural constraints. Legacy systems can lead to a loss of quality. While refactoring legacy code is possible, sometimes the current architecture needs to be completely redesigned to meet certain requirements.
If you`ve ever looked at non-functional requirements, you may be aware that different sources and guides use different terminology. For example, the ISO/IEC 25000 normative framework defines non-functional requirements as system quality and software quality requirements. BABOK, one of the most important sources of knowledge for business analysts, suggests the term Non-functional Requirements (NFR), which is currently the most common definition. Nevertheless, these designations take into account the same type of material – requirements that describe the performance characteristics rather than a behaviour of the product. I`ve been working on creating an API platform for a few months, and here I wanted to share my experience with her. The decisions taken have been taken into account, some of which have been the subject of much discussion. I`ve had to admit that my experience might be a stubborn approach, but it`s supported by the experiences of a few organizations, some of which are mission-critical, so nothing short of top-notch acceptance is. Most of the work of creating the API platform was/is below the surface and therefore special attention was paid to non-functional.
My experience is also enriched by the more conscious creation of the API platform in a public cloud environment (Microsoft Azure).