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 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"
Lets look each characteristics in detail:
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 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.
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.
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)
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.
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.
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.
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.
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
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.
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.
- 200 concurrently active users.
- Processing requests determined to be the greatest processing demand on the system.
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.
Note : Few of the images are just to enhance the mood, don't take it seriously.
to be continued …