Digital PreCheck in Mer Connect Plus App
Non-functional requirements in software quality
That all expectations must be clarified applies all the more to non-functional requirements – such as performance or maintainability. These requirements might face varying degrees of self-interest in the different parties involved or can sometimes be hidden: While the user will place the greatest value on an intuitive and engaging user experience and the features that are important to them, the provider will also place great value on robustness, security, extensibility, and cost-effectiveness. For developers, properties such as good readability, maintainability, or testability of the source code are more likely to play a supporting role.
The intended area of use of software also generates different expectations in terms of quality. For example, a desktop application for an ergonomic workplace has different requirements in terms of fail-safety and appearance than the operation of the online news portal of Frankfurter Allgemeine Zeitung. All these aspects contribute to software quality – and they answer the question of good software: Quality is right when the functional and non-functional requirements of all relevant parties are known at all times and are met to the agreed extent. And to ensure exactly this, we take various quality assurance measures as needed.
With suitable quality assurance measures and tools, however, it is certainly possible to defuse the magic triangle, i.e., to achieve significantly higher quality without major losses in functionality or significantly higher costs. To avoid false expectations, it is advisable to clarify the non-functional requirements – including those for software quality – before the project starts and to know where the project is located in the magic triangle. A positive side effect of this is that it avoids cost-intensive subsequent changes to the development process. The quality is then higher from the outset at the same price, because the required level of quality assurance is realized and tracked from day one and the measures are connected to the development from the very beginning.
Building blocks of proactive quality assurance at jambit
Our motto – 100% enthusiasm – means for us that high quality is the core of our work. What it doesn't mean is that we don't make mistakes, but that we admit them and take advantage of them. By learning from them, it strengthens the quality of our projects and the trust of our customers. The basis for this is our top-of-mind culture, which creates a framework with progressive methods and work practices, and ensures our very high quality level. This allows us to efficiently track down errors and create a trust-based and constructive work culture.
Our employees are the center of the jambit culture. They create the atmosphere in which smooth software development is possible and in which value creation is the focus. This is a motivation! And only those who are motivated and happy bring the necessary intrinsic interest in success and passion for your projects. Only these employees think beyond the mere implementation of requirements, embrace the project vision, and lead the project to success. We offer our jambitees a variety of further training and personal development opportunities. A competence-based resource planning of staffing combines the strengths and interests of our employees with the needs of our customers.
Last but not least, quality also requires commitment from our customers – from awareness of requirements to enabling access to test equipment and specifications. Particularly when proof of a certain level of maturity is required. For example, in the context of functional safety, it is essential that the most realistic possible test environment is provided. We are convinced that an early investment in quality – proactive quality assurance – always pays off because costly extra work can be avoided.
What does proactive quality assurance mean for jambitees?
Depending on the project, we use various methods, tools, or paradigms to ensure quality in daily work at a very high level from day one – with and without formalized quality management. These include the use of agile methods while common best practices such as Clean Code and Clean Architecture, following DevOps principles, or stringent test management still form the base. Most of these can be applied with no or very little additional effort. With slight modifications, they can usually be adapted in agile projects as well as in rather traditional projects.