When building a digital product, quality is critically important. However, having features that function as expected or ensuring that an error isn’t presented to the user isn’t all that makes up a quality product. It’s much broader. The question is, what else composes quality of a digital software product?

At ITX, we reviewed existing facets of quality to help develop our own perspective on the topic. The ideas presented within the Eight Dimensions of Quality resonate most within our organization. However, digital products lead to unique aspects of quality and based on our years of experience we developed our own perspectives: the seven perspectives of quality for digital products.

There are trade-offs and corresponding decisions that help drive the importance of each perspective to the overall solution. For example, for some products security might not be a great concern because it works within a secure private network. However, for other solutions security is critically important. By considering the trade-offs, the highest quality product can be built without over-building it and adding waste.

The Seven Perspectives of Digital Quality are:

• Functional – The product serves its intended use.
  • Acceptance criteria – The product meets all defined acceptance criteria.
  • Intended use – The product achieves its intended use for all stakeholders.
• Architecture – The architecture of your solution must be reusable, extensible, modular and fault tolerant.
  • Reusability – How reusable are the individual components of your product in regards to supporting future features or for other needs in your organization?
  • Extensibility – Can you add new features or enhancements easily and how well does your product interact with outside systems, both to receive and share information?
  • Modularity – How modular is your architecture so that separate teams can work on it at the same time and parts of the system can be replaced without affecting the whole?
  • Fault Tolerance – How capable is your system to respond to partial or complete failure?
• Compliance – Most companies face regulatory requirements from their industry, government or their company, and all companies must consider what software components to use.
  • Code licensing – Today it generally makes sense to leverage open source in some way to speed up the development process and increase quality. However not all open sources are equal in terms of their licenses. There are commercial friendly open source licenses like MIT or Apache and very restrictive licenses (at least commercially) such as GNU. Generally, commercial entities are best only using commercially friendly open source licenses; however each company is different and should consult their legal counsel.
  • Industry regulations – What industry regulations must be followed, such as PCI in commerce?
  • Government regulations – What government regulations are required such as HIPAA in healthcare or 508 accessibility requirements?
  • Corporate regulations – What constraints does your company put on you such as brand guidelines, security standards or other requirements?
• Performance – How does your product scale and respond under your expected load scenarios, both now and in the future, so it is able to grow with your business?
  • Responsiveness – How quickly does the product respond to an end user’s actions?
  • Concurrency – How many end users can interact with the system at the same time?
  • Reliability – How stable is your product and how likely is it that it could fail during a given time period?
• Security – How secure is your product in terms of data, coding standards and infrastructure? How does it stand up against security breaches?
  • Software Development Security – Is the software written in a way to have a resilient system that repels attacks? Does it follow industry best practices such as OWASP (Open Web Application Security Project)?
  • User Security – Does the system allow only the right people to get in and do what they need to accomplish and nobody else? Can the system repel and respond to breaches and is there strong identity and access management? Is there ability to respond to an incident through logging?
  • Data security – Is the data of your system secure and encrypted in a manner that it cannot be stolen and if it cannot be read?
  • System Integrity – Is the system designed so that it cannot be misused or abused by users? For example, one of our clients counts the number of times a document is downloaded. How do you prevent a user from clicking the download too many times, inflating the count?
• Supportability – How maintainable is the product over its expected lifecycle?
  • Serviceability – How easy is it to service your product and release updates to market?
  • Scalability – How readily can you scale up the system to handle increased demand?
  • Documentation – How robust and complete is the documentation of the product to allow new team members to get up to speed?
  • Testability – How easy is it to test the solution and what are the types and coverage of automated tests?
  • Upgradability – How easy is it to upgrade the underlying platform and any third-party tools that are utilized in the product?
  • Monitoring – Is the system designed in such a way that monitoring tools and systems can easily monitor the key functionality of the product to ensure it is working?
• User Experience – The product has been designed with a focus on usability, end user(s) needs and goals, and a beautiful, consistent, cohesive aesthetic.
  • Usability – How easy is the product to use? Does it follow design conventions and best practices? Is it efficient and intuitive for end users?
  • Accessibility – Is the product accessible? Is it easy for different groups of end users to access the product? This includes both technical limitations, such as browser or device, and physical user limitations, such as blindness.
  • Aesthetics – Is the product beautiful? Does the visual design enhance the content, engage users and build trust and interest in the brand?

By using these perspectives of quality when designing a solution, we can develop more effective and cost efficient solution. The trade-offs between these can help prioritize features and effort. Further, scorecards and expectations can be built around each of these, ensuring a higher quality output. In future blog posts we will dive into each perspective of quality in more detail.