Survey for Software Quality Attributes – Where Should We Focus?

I have been using a tool for some time with clients and teams to find out what software quality attributes the product development team should focus on in the project. ISO standard 9621 describes the quality attributes found in software. The following image shows the 6 categories and specific attributes contained within them.

ISO 9621 Software Quality Attributes
ISO 9126-1 Software Quality Attributes

Before I knew about this standard I would discuss how different quality attributes are in conflict with each other. For instance, if we write code that is focused on performance we lose some maintainability. It will be more difficult to read code focused on performance because readability will be sacrificed to some extent.

Now that I’ve known about ISO 9126 for many years, I made a simple spreadsheet tool to interview Product Owners, stakeholders, and software development team members with. Here is the Excel spreadsheet form of this tool:

Software Quality Attributes Rating Tool

Although a bunch of smart people have come up with ISO 9126, I found that modifying the software quality attributes rated in the tool worked more effectively with interviewees. This tool is not to decide what software attributes will be present in the software product getting developed. It is used to identify which software quality factors the team should put more emphasis on when making trade-off decisions during the project. Here is a list of the software quality attributes used in the tool:

  • Suitability – Functionality is suitable to all end users
  • Interoperability – Functionality interoperates with other systems easily
  • Compliance – Functionality is compliant with applicable regulatory guidelines
  • Security – System is secure: confidentiality, integrity, availability, accountability and assurance
  • Maturity – System components are proven stable by others
  • Fault Tolerance – System continues operating properly in the event of failure by one or more of its components
  • Recoverability – System recovers from failures in surrounding environment
  • Understandability – Able to use system with little training
  • Learnability – Supports learning of system functionality with little external interfacing
  • Operability – Ability to keep a system in a functioning and operating condition
  • Performance – Perceived response is immediate
  • Scalability – Able to handle increased usage on the appropriate amount of resources
  • Analyzability – Ability to figure out how the system functions
  • Changeability – Ability to change the system components to meet new business needs
  • Testability – Ability to create repeatable and specific tests of the system and potential for some to be automated
  • Adaptability – Ability to change out system component functionality quickly
  • Installability – Ease of installation and reinstallation
  • Conformance – Conformance to industry and operational standards
  • Replaceability – Ability to replace system in the future

Using the tool is quite simple:

  1. Emphasis Ranking: Have the Product Owner score each of the software quality factors from 1-5 (1 being less applicable and 5 being more applicable) in terms of the software product.
  2. Business Stakeholders identify 3 Must Haves – Ask the business stakeholders what are the 3 software quality factors they want most and stack rank them from 1 to 3
  3. Software Development Team 3 Must Haves – Ask the software development team what are the 3 software quality factors they want most and stack rank them from 1 to 3
  4. Capture Notes about Decisions – Use the notes column to capture any specific decisions about the software quality factors that would help the entire software product team come to consensus.
  5. Discuss Must Haves across Groups – Get the Product Owner, business stakeholders, and software development team members together to discuss and come to consensus on which software quality attributes they will focus on for this project.

Please let me know how you use this tool. There have been many teams that have taken up this tool and found it to be helpful for communicating what is most important from a software quality attibutes point of view in the project. Hope it does the same for you.

Be Sociable, Share!

6 thoughts on “Survey for Software Quality Attributes – Where Should We Focus?”

  1. Small typo. Its ISO 9126, not 9621.

    Apart from that, I agree completely. A lot of teams concentrate only on functionality and reliability, as implemented through testing and bug fixing, but neglect the other aspects.

    I do find a lot of people see the ISO 9xxx and lump it into the ISO 9001 certification camp and automatically think big bureaucratic process, so I like to refer them to the fairly identical list of software quality attributes listed by Robert L. Glass in Facts and Fallacies.

    (Although ISO 9001 doesn’t have to big and bureaucratic, and can be a good QA component in agile cultures, but that is another topic.)

  2. Oh and one more point, I find the idea of “trade-offs” to be a bit overstated in general.

    If anything, the quality attributes reinforce each other. Good software design tends to enhance multiple software quality attributes at the same time, for example, by designing for testability (via TDD for example) we also increase the readability, modularity, portability and maintainability.

    Additionally the old trade-off between quality itself and productivity no longer applies. We either focus on quality, and find increases in both quality and productivity (as technical debt reduction makes future iterations or maintenance more effective) or we attempt to sacrifice a little quality in the hope of achieving greater productivity, and find (due to the broken window effect) that increases in technical debt make maintenance and future iterations increasingly more expensive.

  3. Thanks this was helpful. WE are probably goign to use a pugh matrix instead however the definition of the quality attributes is good.

Comments are closed.