Quality, functional and non-functional requirements in software development

Translated from the original post in German

Users and customers want high-quality software that helps them to achieve their goals effectively and efficiently. It should run “smoothly,” and as “fast” and “bug-free” as possible. However, these obvious yet very general requirements are quite subjective and do not give a development team much to work with. It has to be more concrete, more specific. So, what does quality mean when it comes to software development? We will shed some light on that here.

What is the “official” definition of quality?

Let’s start by looking at it from an official perspective. What could be more helpful here than international standards?

Software quality can be defined as the totality of features and characteristics of a software product that bear on its ability to satisfy stated and implied needs.

DIN EN ISO 8402:1995-08

The degree to which a set of inherent characteristics of an object fulfills requirements.

DIN EN ISO 9000 2015

Functional and non-functional requirements

When it comes to quality in software development, there are functional and non-functional requirements:

  • Functional requirements specify what a system/product should do. (Example: A store system should provide the customer with an overview of what they have already purchased.)
  • Non-functional requirements go beyond functional requirements and specify how well a system/product should perform a function or service. (Example: The system should display the purchase overview within three seconds.) Non-functional requirements are also known as boundary conditions or quality attributes.

Quality and quality-related costs

Quality requires time and resources. So, it is not an end in itself but based on an economic consideration of cost and benefit. We group such quality-related costs as follows:

  • Prevention costs: quality-enhancement measures, controls, planning, audits, etc.
  • Failure costs: loss of customers, reputation, contractual penalties, deviations.

Weighing up the costs and benefits means that we have to accept a certain degree of failure because of economic restraints. (It is well-known that this rule of thumb is sometimes taken too far in software development, as described in the perpetual beta or banana principle. The failure costs are then correspondingly high.) Highly critical systems are the exception; in the medical field or air traffic control, for example, where easily avoidable mistakes are unacceptable.

Classification of quality characteristics

The ISO-25010/9126 standard classifies quality characteristics as follows:

Competing quality requirements

It is often impossible to satisfy all quality requirements for a software product in equal measure. In fact, they compete with one another. Here, the development team must compare and then prioritize. Here are two classic examples:

  • Security vs. performance: Using a more expensive encryption algorithm would increase security but also increase the services’ response time.
  • Usability vs. security: Entering a 30-digit password would increase security but compromise user experience.

Quality scenarios

Teams can use quality scenarios to specify requirements. These also serve as a basis for specific types of tests.

The following template can be used to define quality scenarios. The level of detail can be adapted to suit a particular case:

Source → environment → stimulus → artifact → response → metric

Example: Under normal conditions, users initiate 20,000 transactions, which are processed with an average latency of 1.5 seconds.

Goal Question Metric

The Goal Question Metric is a systematic approach to creating specific quality models in a tree structure. The parts of the tree represent the goals, questions, and metrics.

  •       Root: The Goal -> What should the measurement achieve?
  •       Nodes: Questions -> What should be measured? / Which questions should the measurement answer?
  •       Leaves: Metrics -> Which metrics can describe the necessary characteristics?

Metrics

There are various metrics used to assess these characteristics. This word cloud presents a selection:

And that is by no means all of them.

Methods and tools

Software teams have high-performance tools and concepts at their disposal for all of the aspects mentioned. Here are a few examples:

  •       Maintainability/Portability: SonarQube, evaluation processes (ATAM, audits)
  •       Security: OWASP CVE Scanner, Jess Security Scanner, SonarQube
  •       Reliability: Stress tests, regression tests
  •       Usability: A/B tests, WAI/AAA tests, usability inspections (guideline-based reviews), surveys
  •       Performance: Load tests, performance tests

Your partner for custom software projects

Are you  planning a specific software project? Or are there certain processes in your company that are particularly challenging? Is a system or interface holding your employees back or making things difficult for your customers? Then ask us for help! We look forward to working with you to develop a custom solution to suit your requirements – our work is of the highest quality, and you have complete control over the costs.

Further information

Continuous delivery in practice: Deployment at the touch of a button and release management with Bamboo
An introduction to testing web services with Karate and JUnit

Forget Less and Ensure Quality with didit Checklists for Atlassian Cloud Forget Less and Ensure Quality with didit Checklists for Atlassian Cloud Forget Less and Ensure Quality with didit Checklists for Atlassian Cloud
ATTENTION!
Our blog articles reflect the situation at the time of writing and are not updated. It is therefore possible that the contents are outdated and no longer correspond to the latest developments. We do not accept any liability for this.

Leave a Reply