The system should be easy to use.
The system should be flexible and scalable.
The system should be secured.
….
….
The system should be portable.

Did you read any requirements document and found one of the requirements statement mentioned above? Then, you started to think, what does it mean to make the software ease of use, how can I make that feasible, if I implemented that feature would the software became more usable? would it be acceptable to the customer? What are the metrics and acceptance criteria for that? How to transform these intangible requirements into something tangible can be implemented and measured.

Through the life cycle process and project implementation, you will encounter different types of qualitative requirements, for example, availability, maintainability, scalability, and a lot more, all of these “ilities” which are mainly know as non-functional requirements, define the Software Qualities that are factors that affect system behavior and have a significant impact on the software architecture of a system and its characteristics.

Computer systems are being used in all areas of our lives and become a foundation stone for any business, and they became used in all domains and critical industries which cannot afford failure or failure can cause loss of life, or cause a disaster. Imagine, that you have a software braking system which it took like 1 minute to respond or a missile launch software which it has a different unreliable precision every time. That will be a disaster, right? The role of quality attributes is critical and it shapes the main characteristics of the system and ensures that we will have a workable product we can depend on it during the operation phase of the system.

What are the software quality attributes?

Quality attribute requirements are part of an application’s nonfunctional requirements, which capture the many facets of how the functional requirements of an application are achieved. All but the most trivial application will have nonfunctional requirements that can be expressed in terms of quality attribute requirements.

The nonfunctional requirements define these aspects about the system. (The nonfunctional requirements are sometimes referred to as “nonbehavioral requirements” or “software quality attributes.”)

Non-functional requirements, as the name suggests, are requirements that are not directly concerned with the specific services delivered by the system to its users. They may relate to emergent system properties such as reliability, response time, and store occupancy. Alternatively, they may define constraints on the system implementation such as the capabilities of I/O devices or the data representations used in interfaces with other systems.

As we can notice from these definitions a non-functional property (NFP) is about the criteria that can be used to judge the operation of a system, rather than specific behaviors. Moreover, some quality properties can have an impact on the system behavior in the operations of the system, for example, you can apply security rule dynamically on the system if there is a security threat, for example, limiting some functionalities.

Although all quality attributes are important and someone can say, I will ask for all of them on my requirements document to have a superb system. There is nothing like that, you will have to do trade-off analysis between different qualities because some of them are dependent on each other.

Software engineering institute mention that no one has systematically and completely documented the relationship between software architecture and quality attributes at one its technical reports and this is due to many reasons summarized below:

• No precise definition for most of the quality attributes, for example, modifiability, security, and usability.
• Attributes are not isolated. For example, availability is an attribute in its own while, it affects the security attribute as well (Denial of service attack could limit availability) and usability attribute (Users require no downtime and always available).
• Standardization of Attribute analysis, it is difficult to decide which situations or patterns to analyze what quality.
• Analysis techniques are designed in silos to map to a particular attribute. Therefore, it is difficult to understand how the various attribute-specific analyses interact.

That should inspire us to think about interdependencies between our selected quality attributes and also apply the tradeoffs between them.

Moreover, as we have a software development process, we should apply the software quality process to ensure the applicability and existence of the selected qualities.

I draw the below process to analyze and plan for quality attributes, I think this can be integrated with software quality process and apply some checklist with each deliverable if the deliverable is fulfilling these qualities.

The quality attribute analysis process

Common Quality Attributes examples

Here are some samples of quality attributes, what are the most common requirements for them, also some metrics and strategies to achieve them.

Availability

Availability defines the proportion of time that the system is functional and working. It can be measured as a percentage of the total system downtime over a predefined period. System errors, infrastructure problems, malicious attacks, and system load will affect overall system availability.

Usability

Usability is the degree to which a software can be used by specified consumers to achieve quantified objectives with effectiveness, efficiency, and satisfaction in a quantified context of use, for example, easy to localize and globalize, providing good access for disabled users, and resulting in a good overall user experience.

Performance

The degree to which a system or component accomplishes its designated functions within given constraints, such as speed, accuracy, or memory usage. It refers to responsiveness, either the time required to respond to specific events or the number of events processed in a given interval of time.

It would be helpful as well to look at McCall’s and Boehm’s Quality Models. There are tens of quality attributes and you can find a good list in this link. If you need any help for better understanding of any of them, please do not hesitate to contact me 🙂

References

• Barbacci, M., Klein, M. H., Longstaff, T. A., & Weinstock, C. B. (1995, 12). Quality Attributes. doi:10.21236/ada307888
• Bass, L., Klein, M., & Moreno, G. (2001, 10). Applicability of General Scenarios to the Architecture Tradeoff Analysis Method. doi:10.21236/ada388958
• Gorton, I. (2011). Essential software architecture. New York: Springer.
• Sommerville, I. (2011). Software engineering. Boston: Pearson.
• Stellman, A., & Greene, J. (2006). Applied software project management. Sebastopol, CA: O’Reilly.
• (n.d.). Retrieved August 26, 2017, from https://msdn.microsoft.com/en-us/library/ee658094.aspx

Help to do more!

The content you read is available for free. If you’ve liked any of the articles at this site, please take a second to help us write more and more articles based on real experiences and maintain them for you and others. Your support will make it possible for us.

$10.00