‫Now that we thoroughly explored
‫functional requirements,
‫as well as how to capture and visualize them,
‫let's expand on the next type of requirements,
‫the quality attributes,
‫otherwise known as nonfunctional requirements.
‫This type of requirements has a direct effect
‫on the software architecture.
‫So let's start with some motivation
‫and a formal definition of a quality attribute.
‫Studies have shown that systems
‫are frequently redesigned and restructured,
‫mostly not because they're functionally deficient
‫or because of new functionality requirements,
‫but because the existing system, as it stands,
‫is either not fast enough, can't scale well enough
‫to the growing number of users or volume of data,
‫or the structure of the system
‫makes development, maintenance, or security very hard.
‫And in most cases, after such a major redesign,
‫the system provides either equivalent
‫or exactly the same functionality as it did before.
‫So architecting our system in a way that provides us
‫with the right quality attributes right from the start
‫is extremely important to avoid such major redesigns.
‫Now let's define more formally
‫what quality attributes actually are.
‫Quality attributes are nonfunctional requirements
‫that describe the qualities
‫of the system's functional requirements,
‫or the overall properties of the system.
‫In other words, the quality attributes
‫do not say what the system does,
‫but instead, they provide a quality measure
‫on how well our system performs on a particular dimension.
‫And as we mentioned before,
‫the quality attributes have direct correlation
‫with the architecture of the system.
‫To clarify the definition,
‫let's see how a quality attribute provides a quality measure
‫to a functional requirement.
‫Let's take an example of an online store
‫where users can look for products
‫based on some search keywords.
‫So one general requirement
‫may be that when a user clicks on a Search button
‫after they typed in a particular search keywords,
‫the user will be provided with a list of products
‫within at most 100 milliseconds.
‫So the functional requirement
‫is the action that our system takes
‫when a user clicks on the Search button,
‫and the quality attribute,
‫in this case, in the performance dimension,
‫describes how fast this action is to be performed.
‫Another example that is not tied
‫to a particular functional requirement,
‫but instead pertains to our entire system,
‫is that our online store has to be available to the users
‫at least 99.9% of the time.
‫So in this case, this quality attribute
‫is in the availability dimension.
‫Quality attributes don't only need to satisfy
‫the needs of the clients.
‫Instead, they need to satisfy the quality requirements
‫of all the stakeholders.
‫To illustrate this, let's take another quality requirement,
‫which is, our development team
‫can deploy a new version of our online store
‫at least twice a week.
‫This property also pertains to our entire system
‫and describes how our system performs
‫in the deployability dimension.
‫So now that we got some intuition
‫for system quality attributes,
‫let's discuss some very important considerations
‫about quality attributes in general
‫when it comes to designing a software system.
‫One of the most important considerations
‫about quality attributes
‫is that they have to be measurable and testable.
‫If we can't objectively measure and consistently test
‫to prove that our system satisfies
‫the required quality attributes, then we can't actually know
‫if our system performs well or performs poorly
‫in regards to that requirement.
‫For example, if the requirement we get
‫is when a user clicks on the Buy button,
‫the purchase confirmation
‫must be displayed quickly to the user.
‫Now, if we design a system
‫such that it displays the confirmation
‫within 200 milliseconds.
‫Now, since we couldn't measure
‫what the word quickly really meant,
‫we can't know if 200 milliseconds is good or bad.
‫The second important consideration
‫is that there is no single architecture
‫that can provide all the quality attributes.
‫Essentially, if there was such an architecture,
‫then everyone would use it for every system
‫and the job of a software architect wouldn't exist.
‫The reason it's impossible
‫is that certain quality attributes
‫contradict with each other,
‫so some combinations of quality attributes
‫are either very hard to achieve or are even impossible.
‫That is why our job as software architects
‫is to make the right trade-off,
‫prioritizing some quality attributes over the others
‫and designing the system in a way that will give us
‫the highest chance for success
‫based on the requirements of the business.
‫For example, we may have have two conflicting requirements
‫for our system's login page.
‫One requirement states
‫that a user should log in to our system very quickly,
‫preferably under one second.
‫The other requirement tells us to provide security
‫to protect the user's account.
‫That entails that for the user to log in,
‫they will need to type in some sort of password,
‫and also, to protect that password,
‫we need to use something like SSL,
‫which is a technology
‫that allows us to protect that password
‫from being intercepted by a third party.
‫But making a user type in their username and password,
‫and also making the network request using SSL,
‫makes the login process slower,
‫which goes directly against the first requirement
‫to make the login process as fast as possible.
‫The third important consideration
‫in regards to quality attributes,
‫it's the feasibility of their requirements.
‫It is up to us, the designers of the system,
‫to make sure that the system that we're attempting to design
‫and later build is even capable
‫of delivering what the client is asking for.
‫In some cases, because the client is not technical,
‫they may ask for something
‫that is either technically impossible,
‫or prohibitively expensive to implement,
‫and it is our job to call that out early on in the process.
‫One example of an unfeasible requirement
‫is unrealistic low latency expectations.
‫For example, if the network latency
‫between a client in South America
‫and the closest data center
‫where we run our system in U.S. East,
‫is anywhere between 100 or 150 milliseconds,
‫then we cannot guarantee page loads
‫to be less than 100 milliseconds.
‫Actually, we can't even guarantee a latency close to that,
‫because loading a page using HTTP
‫requires multiple round trips as part of its protocol,
‫as well as potentially loading multiple assets.
‫Another example can be a requirement
‫for 100% availability of the system.
‫This basically means that our system can never fail
‫and we will never have a chance
‫to take it down for maintenance or upgrades.
‫Other examples of unfeasible requirements
‫can be full protection against hackers,
‫streaming high resolution movies
‫in areas where the bandwidth doesn't allow it,
‫or a requirement for our system
‫to increase its storage capacity at an unreasonable rate.
‫So, before approving a requirement,
‫we may even need to consult with people
‫with domain expertise
‫to make sure that we can actually deliver
‫on what we promise.
‫In this lecture, we got the motivation
‫for system quality attributes.
‫We mentioned that the majority of the system redesigns
‫happen because the system, as it stands,
‫does not provide the required quality attributes.
‫We also officially defined quality attributes
‫as a measure on how well our system performs
‫on a particular dimension.
‫And finally, we talked about
‫the three important considerations
‫when defining the quality attributes for a system.
‫The first consideration was the testability
‫and measurability of the quality attribute.
‫The second was the necessity to make trade-offs
‫and choose the right quality attributes over the others.
‫And the third consideration
‫was the feasibility of the quality attribute
‫to make sure we can deliver on what we promise.
‫See you guys in the next lecture.