What are the requirements for software development

Users and customers want high quality software with which they can achieve their goals effectively and efficiently. It should work "smoothly", as "quickly" as possible, as "bug-free" as possible. But these obvious, but very general requirements are quite subjective and initially nothing that a development team can work with. It has to be more concrete and specific. So what does quality mean in terms of software development? We want to shed some light on that here.

What does quality mean "official"?

Let us first approach the topic from the very official point of view. What should be able to help us here, if not the international standards?

"Software quality is understood to mean the entirety of the features and characteristic values ​​of a software product that relate to its suitability to meet specified or required requirements"
DIN EN ISO 8402: 1995-08

"The degree to which a set of inherent characteristics of an object meets requirements"
DIN EN ISO 9000 2015

Functional and non-functional requirements

In software development, we have to deal with functional and non-functional requirements in terms of quality:

  • Functional requirements determine what the system / product should do. (Example: The shop system should be able to show a customer their purchases in an overview.)
  • Non-functional requirements go beyond the functional requirements and describe how well a system / product fulfills a function or provides a service. (Example: The system must not take longer than three seconds to display the purchasing overview.) Such non-functional requirements are sometimes also referred to as boundary conditions or quality properties.

Quality and quality cost

Quality takes time and resources. Therefore, quality is not an end in itself, but is based on the economic weighing of benefits and costs. Such quality costs can be divided as follows:

  • Error prevention costs: quality-enhancing measures, controls, planning, audits, etc.
  • Failure costs: loss of customers, reputation, contractual penalties, discrepancies

Ultimately, this consideration means that due to economic constraints, a certain amount of errors is acceptable. (As is well known, this rule of thumb is sometimes overstimulated in the software area, see Banana Software. The error costs are often correspondingly high.)

Exceptions are highly critical systems such as in the medical field or in air traffic control, in which errors cannot be tolerated for obvious reasons.

Classification of qualitative characteristics

The ISO-25010/9126 standard offers a classification of qualitative characteristics that can be used as a guide:

Competing qualitative requirements

Often not all quality requirements can be met equally in a software product. Rather, they compete with each other. In this case, the development team has to weigh them against each other and prioritize them. Here are two classic examples of this:

  • Security versus performance: In order to increase the security of the application, we use a more expensive encryption algorithm, which increases the response time of the services.
  • Usability versus security: Entering a 30-digit password increases security, but affects the user experience.

Quality scenarios

To specify qualitative requirements, we can use so-called quality scenarios, which can also serve as the basis for specific types of test.

The following template can be used to define quality scenarios. Depending on the need, it should be used at the appropriate level of granularity:

Source -> Environment -> Stimulus -> Artifact -> Response -> Metric

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

Goal Question Metric

A systematic procedure for creating specific quality models is offered by theGoal Question Metric-Approach that can be represented as a tree structure. The components of the tree represent the goals, questions and metrics.

  • Root: the goal -> What should be achieved by the measurement?
  • Node: Questions -> What should be measured? / Which questions should the measurement answer?
  • Sheets: Metrics -> Which metrics can describe the necessary properties?

Metrics

The metrics used to describe the properties are diverse. This word cloud shows a selection:

And that is by no means all.

Methods and tools

The software team has powerful tools and concepts at its disposal for all of the aspects mentioned. Here are some examples:

  • Maintainability / portability: SonarQube, assessment procedures (ATAM, audits)
  • Security: OWASP CVE Scanner, Jess Security Scanner, SonarQube
  • Reliability: stress tests, regression tests
  • Usability: A / B tests, WAI / AAA tests, usability inspection (guideline-based review), surveys
  • Performance: load tests, performance tests

Your partner for individual software projects

Are you already planning a specific software project? Or are there certain processes in your company that have been causing you headaches for a long time? Is a system or an interface slowing down your employees on the one hand or your customers on the other? Then talk to us about it! We look forward to developing an individual solution together - with the highest quality and full cost control.

View this post in English

Further information

Optimize code quality with SonarQube and Bamboo
Analysis of a Java application with Java Mission Control and Flight Recorder
Continuous delivery in practice: Deployment at the push of a button and release management with Bamboo
Ensure architecture rules with Java and ArchUnit


Learn more about the Creative Commons license

Creative CommonsQuality AssuranceSoftwareSoftware DevelopmentSoftware Quality