Software Engineering Quality Aspects


The software engineering is the process of manufacturing systems (e.g. software and applications) where well-known techniques for handling complex problems are used. The software engineering process is divided into phases and one of the important phases in the software engineering is the design phase. In the design phase, a developed plan has to be in place to show how the system will implement the requirements while promoting design quality that adhere certain attributes. The software engineering process represents a set of actions required to transform users’ need into an effective software solution efficiently (Answer.Com, 2011).  

Software Quality attributes represents the benchmarks that describe the intended behaviour of the system where it provides the means for measuring the suitability and the fitness of a product. While software architecture has a great affect on most of the software quality in different ways, the software quality attributes affect the design architecture. That said, identifying the desired system qualities attributes before going through the design phase, will allow the software designers to model the right solution for the desired software within the constraints of the quality attributes, and provide the right architecture for such solution (, 2002).

Defining high objectives for manufacturing a software product at the beginning of any project with statements such as “a high performance system” and “User friendly system” might be acceptable at beginning of the project. Once more information start to become available, such objectives becomes meaningless and useless for the purpose of the actual design of the solution since both statements don’t provide a tangible way of measuring the system behaviour. In describing the quality attributes of any system, statement such as “under normal conditions, the system will process the requests within an average of latency of the four seconds” will allow the architect to make the quantifiable assumptions about the system performance. Such scenarios, creates a tangible and measurable goals for the desired software behaviours (, 2002). (2002) explained that in achieving qualities for a software product, describing tangible scenarios that can express the objectives of the system behaviours will help in shaping the software quality goals despite the fact that such scenarios don’t describe how such quality will be achieved. However, it is part of the architect to use the right tactic to achieve such goals, for example, to achieve the performance quality attribute within a system, an architect can use a tactic that implement a better processing algorithms, or implementing a parallel processing that can improve the performance attribute within the software product. Over the past years, architects have produced a list of common software qualities where the system qualities can be categorized into four parts:  non-runtime quality, runtime qualities, architecture qualities and business qualities. The following are the quality attributes for each category:

  • Non-Runtime System Qualities – where such qualities cannot be measured during the system execution, and the attributes of such quality are:

1- Modifiability – Where the software can easily accommodate the software changes.

2- Portability – Where the system can have the ability to run under different computing environment (e.g. hardware and software environment).

3- Reusability – Defined in what degree such software product can be reused in building new product.

4- Integrability – Defined as the ability of the component of such system to be used separately and work correctly.

5- Testability –   where the software can be easy to demonstrate its faults.

  • Runtime System Qualities – Such qualities can be measured during the execution of the software, and the attributes of such quality are:

1-      Functionality – Is the ability of the software to promote the work that it intended to do.

2-      Performance – Represents the throughput behaviour of the system, response time, and utilization of the system which is different from the system delivery time and human performance.

3-      Security – Is the ability for the system to resist unauthorized attempts to use its functions or modify its behaviours while it provides the regular service to the authorized and legitimate users.

4-      Availability – Is the measure of time where the system is up and functioning correctly and also represents the amount of time required between system failures and resuming the operation after a failure.

5-      Usability – Represents how the system is easy to be used by users and how easy the users can be trained to use such system where other sub qualities such as helpfulness and learn-ability can be achieved.

  • Business Qualities – It represents a non-software system qualities, however it might affect the quality attributes indirectly, and some of these attributes are:

1-      Cost and Schedule – Defined the system cost with respect to the project lifetime and the time to market the product.

2-      Marketability – Represent the use of the system with respect to the competition exist in the market.

  • Architecture Qualities – represents the overall integrity among the system components and how much such system can satisfy the system requirements.

Aspects of the Design Quality

Islam (2009) explained that the purpose of defining the design quality parameters or attributes is to make them measurable and tangible in achieving certain quality of the software product. The main software design quality attributes are:

  • Functionality – Represents the main purpose that the design provides where a system can not possess the usability features if such system can’t function correctly.  Functionality attribute contains sub-attributes such as suitability, accurateness, interoperability, compliance, and security.
  • Reliability – Defines the capability of the system to maintain its service provision within a defined time and conditions. One aspect of system reliability is the ability of a system resist component’s failure (i.e. the capability of the software design to maintain a certain level of performance when such system is used under certain conditions). Reliability attributes contains sub-attributes such as maturity, fault tolerance, and recoverability.
  • Usability – Represents the ease of use for a given function, and only exists with regard to functionality. The usability represents the ability of the design to be learned, understood, and be likeable by the users when it is used under specified conditions. Usability attribute contains sub-attributes such as understand-ability, learn-ability, operability.
  • Efficiency – Represent the usage of system resources when such system provides the required functionality and can be presented through memory usage, disk space usage, and network communications usage. It also represents the ability of the design to provide the appropriate performance that can be proportional to the amount of resources available under specific conditions.  Efficiency attribute contains sub-attributes such as time behaviour and resource behaviour.
  • Maintainability – Defines the capability of the system to identify and fix a fault within software components based on defined maintainability characteristics. It is the ability of the design to be modified to provide improvement, corrections, or to adapt new changes in the environment or in the functional specifications. Maintainability attribute contains sub-attributes such as analyzability, changeability, stability and testability.
  • Portability – Represents how well the software can adapt any changes in its environment or its requirements. Portability attribute contains sub-attributes such as adaptability, install-ability, conformance, replace-ability, and reusability.

Causes of Poor Software Quality

Curtis (2009) argues that the poor quality of software is a result of known causes that can be predicted and controlled and it’s an inevitable attribute of any software. Such causes can only be controlled when it is addressed correctly to be able to eliminate the risk that can be imposed on the business process. With more critical and complex business processes implemented in software it increases the quality risk and some of the causes of poor software quality are:

  • Lack of domain knowledge – Where developers and architects most of the time lacking the fully understanding of the business domain, and to mitigate such cause, it is important that developers and architects will have an access to such domain through business training and reviewing of the business processes.
  • Lack of technology knowledge – Multi-tiers business applications expose complexity to the architects and developers since such model includes many entities such as business logic, user interface, data management, middleware and interfaces to legacy applications. With incorrect assumptions about how other technology is working might create huge non-functional defects that might cause data corruption, and security breaches during operations. The best solution to mitigate such problem is cross-training in different technologies and applications.
  • Unrealistic Schedules – Where developers and architects sacrifice the software development best practice that is not aligned with the project schedule. To mitigate such cause, it is imperative to enforce the project management strong practices, controlling endless requirements changes, tracking problems to identify problems, and controlling commitments through planning.
  • Badly engineered software – Implementing unnecessarily complex code that can create un-anticipated negative effects in trying to modify such code based on new changes. To mitigate such cause, it is important re-factor the critical portions of such complex code from the architectural point of view.
  • Poor acquisition practices – When some of multi-tier applications implemented within any organization are outsourced, it’s too hard to maintain control over the quality of the software. To mitigate such risk, managers and architects should targets quality in their contracts and strong quality assurance gate has to be implemented.


Architectural decision might impact directly some of the system qualities and in most cases, making a decision in favour of one quality in the software product might directly affect another quality. Also, in implementing the system-quality attributes, such implementation must be prioritized based on the software requirements and how much such attribute is important compared to others (Morgan, 2007).

Morgan (2007) explained that implementing the system quality attributes requires and extra effort from the architect to pay attention to the software-quality attributes. In achieving such goal, it is important to establish some rules that can measure the system quality. One of the approaches that can be used to implement the system quality is the IEEE Software Quality Metrics Methodology, where it suggests performing the following steps:

1-      Software-quality requirements must be established before the design take place.

2-      Software-quality metrics must be identified.

3-      Software-quality metrics must be implemented.

4-      The results of these metrics must be analyzed.

5-      The software-quality metrics must be validated.

Finally, to achieve the goal of high quality software, it’s important for any organization to define quality. In many cases, the software development process within an organization operates with general notion of quality, tolerate defects that are not accepted by most of the engineering disciplines and operate with a loose definition of such software quality. To achieve quality it’s important for any organization to apply a high-quality process throughout the development process, integration process, and testing process. Business that value quality becomes more innovative, responsive; competitive and is able to reduce development cost that can be at high risk with poor quality software implementations (Bessin, 2004).


Answer.Com (2011) Software Engineering [Online]. Available from: (Accessed: 06 March 2011).

Bessin, G. (2004) The business value of software quality [Online]. Available from: (Accessed: 06 March 2011).

Curtis, B. (2009) Top Five Causes of Poor Software Quality [Online]. Available from: (Accessed: 06 March 2011).

Islam, S. (2009) Software Engineering Process – Design Quality Attributes [Online]. Available from:—Design-Quality-Attributes (Accessed: 06 March 2011).

Morgan, G. (2007) Implementing System-Quality Attributes [Online]. Available from: (Accessed: 06 March 2011). (2002) Quality Attributes [Online]. Available from: (Accessed: 06 March 2011).


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: