Before proceeding any further I would suggest you to go through previous page (https://dev.to/adahanu074/system-design-1h4m) and get the basic understanding of what is system design and its fundamental. This part we will be focusing on non functional characteristics which describes how the system should perform rather than what it should do. We need to understand terminologies and what are required to build system before moving further in system design.
Non-functional characteristics, in other words we can say Non-functional requirements(NFRs) are a set of specifications that describe the system’s operation capabilities, constraints and attempt to improve its functionality.
Functional and non-functional requirements
Functional and non-functional requirements describe specific characteristics that a product must have to meet the needs of the stakeholders and the business itself. But, as you can tell from the name, they focus on different things.
Functional requirements define what a software product must do: its features and functions. An example of functional requirement for WhatsApp will be something like "A user must be able to edit messages after they are sent"
Non-functional requirements specify the quality attributes of the system, hence their second name — quality attributes. Continuing our WhatsApp example, a non-functional requirement can be "A user should be able to receive the message with low latency also"
key types of non-functional characteristics?
Lets look each characteristics in detail:
Performance
Performance defines how fast a software system or a particular piece of it responds to certain users’ actions under a certain workload. In most cases, this metric explains how long a user must wait before the target operation happens. But it’s not always like that. Performance requirements may describe background processes invisible to users, e.g. backup.
Example of performance requirements:
The landing page supporting 5,000 users per hour must provide 5 second or less response time in a application, including the rendering components and over an LTE connection.
Scalability
Scalability assesses the highest workloads under which the system will still meet the performance requirements. There are two ways to enable your system scale as the workloads get higher: horizontal and vertical scaling.
Example of scalability requirements:
The maximum user of the website must be scalable enough to support 5000 visits at the same time while maintaining optimal performance.
Compatibility
Compatibility, as an additional aspect of portability, defines how a system can coexist with another system in the same environment. For instance, software installed on an operating system must be compatible with its firewall or antivirus protection.
Example of compatibility requirements:
The application must support all the browser that are present in the market
Maintainability
Maintainability measures the amount of time, effort, and money that will be required in order to change or repair your software’s code after it’s been deployed. Even though maintainability doesn’t come into play until the software has already been launched, it should be a consideration during every step of the development cycle in order to prepare for inevitable maintenance needs. Maintainability is often measured with a metric like MTTRS — the mean time to restore the system.(must not be greater than 10 minutes)
Example of maintainability requirements:
After some period/days/months, check for the working of application and it should behave as it was at the time, when it went off in production.
Availability
Availability describes how likely the system is accessible to a user at a given point in time. While it can be expressed as an expected percentage of successful requests, you may also define it as a percentage of time the system is accessible for operation during some time period. For instance, the system may be available 98 percent of the time during a month. Availability is perhaps the most business-critical requirement, but to define it, you also must have estimations for reliability and maintainability.
Example of availability requirements:
The application must be available to end users 99.9 percent of the time every month during business hours.
Reliability
Reliability specifies how likely the system or its element would run without a failure for a given period of time under predefined conditions. Traditionally, this probability is expressed in percentages. For instance, if the system has 85 percent reliability for a month, this means that during this month, under normal usage conditions, there’s an 85 percent chance that the system won’t experience critical failure.
Example of reliability requirements:
The system must perform without failure in 95 percent of use cases during a month.
Portability
Portability determines how a system or its element can be launched within one environment or another. It usually includes hardware, software, or other usage platform specifications. Put simply, it establishes how well actions performed via one platform are run on another. Also, it prescribes how well system elements may be accessed and may interact from two different environments.
Example of portability requirements:
A application running on Windows 10 OS must be able to run on Windows 11 OS without any change in its configuration, behaviour and performance.
Security
Security is a non-functional requirement assuring all data inside the system or its part will be protected against malware attacks or unauthorized access. But there’s a catch. The lion’s share of security non-functional requirements can be translated into concrete functional counterparts. If you want to protect the admin panel from unauthorized access, you would define the login flow and different user roles as system behaviour or user actions.
Example of security requirement:
The payment processing gateway must be PCI DSS compliant.
Usability
Usability is yet another classical non-functional requirement that addresses a simple question: How hard is it to use the product? Defining these requirements isn’t as easy as it seems. Application can be used by as many people as possible with ease, whether this is end-users of a website, or administrators and content editors working with a back-end system
Example of usability requirements:
The error rate of users logging to the application mustn’t exceed 1% percent.
Localization
Localization is the process of adapting messages, imagery, brand voice, features, and products to achieve a linguistic, cultural, and geographic fit for a given audience. The goal is to make user experiences for everyone as comfortable as possible across different cultural and regional contexts.
Example of a localization requirement:
The date format must be as follows: month.date.year. It should be independent of place.
Testability
Covering the levels of test coverage in place, the effectiveness and efficiency of tests, and the quality of testing reporting, the testability quality attribute requirement relates to how confident teams can be that the system will function as intended.
Example of testability requirement
Below cases, the system shall have at least 35% spare CPU capacity and work in normal mode.
- 200 concurrently active users.
- Processing requests determined to be the greatest processing demand on the system.
Feasibility
Feasibility is the process in which we must be confident that it’s possible to complete the work in the time and/or budget dictated. For this reason feasibility touches on a number of other QARs, including time-to-market, total cost of ownership, technical knowledge, and migration requirements.
Example of feasibility requirement:
Without cloud orchestration/services , are we able to use open source and deploy the product in production or not.
Note : Few of the images are just to enhance the mood, don't take it seriously.
to be continued …
Top comments (0)