Correctness is a term that encompasses a few requirements:

• The software is designed to meet your needs.
• The software is accurate (it does what it was designed to do).
• The software has low or no defects/bugs.

• Requirements Gathering Processes - time is taken to understand your needs.
• Testing practices and plans are in place before the developer starts the project.

This is the famous "it should be easy to use". It is tough to define, but we tend to consider three key criteria:

1. The software should make sense when following your process. Ideally, it guides the user through it.
2. Commonly used features are the most accessible.
3. The right level of flexibility and configuration are exposed to the user. This can be less or more depending on the project.

• Good requirements gathering to understand what the interface should involve.
• Early design and testing of the user interface with the opportunity for feedback and improvement.

Robustness means it doesn't only work in the perfect circumstances, or in the first year. 

• Defensive programming practices anticipate and manage failure scenarios.
• Developers allow sufficient time for testing in different scenarios and potential failure modes.

Maintainability is all about how easy the software is to change. Change doesn't necessarily mean adding new features but being able to turn around bug fixes quickly as well.

There are a few reasons why maintainability is a concern, even though it doesn't directly impact the user of the software.

1. In maintainable code, bug fixes or new features are quicker to add and much less likely to introduce additional bugs. This means less downtime of the system and lower costs for changes.
2. Hard to maintain code means it is more likely that developers miss or introduce bugs. Hence this is likely to be higher quality for correctness and reliability as well.
3. When the code is written with this in mind, it is easier to have different developers work on it. This reduces the project risk of future changes if the original developers are unavailable or need a bigger team.

• Keep the software simple. Take opportunities to remove and simplify existing code and avoid complex frameworks and structures which are hard to understand.
• A modular and structured approach to developing software which creates consistency across the code base.

The performance is the measure of the size and speed of the application. Good performance means that the software completes its tasks in a reasonable time on reasonably specified hardware.

Optimisation is a balancing act. Performance can always be improved but at a cost. It is about finding the balance for the particular application.

Computers are cheap, people are expensive. You don't want to waste your engineers time waiting around for the software to complete what it is doing.

• Ability to identify likely bottlenecks and apply standard optimisation methods to the code.
• Avoid premature optimisation that costs a lot of development time until performance problems are identified and understood.

Application and system security is in the headlines more and more. Secure software is designed to avoid key risks of outside interference in the application.

Like performance, this is a balancing act. Secure software costs more to develop and is less usable, so this must be balanced with other factors.

There are two key concerns in engineering software:

1. Avoid downtime due to malware/virus exploitation.
2. Avoid confidential data getting into the wrong hands and being exploited to harm your company.

• Threat Evaluation - Taking time to understand the credible threats to the system.
• Secure By Design - The early design phases consider security from the start, and the system level design provides a secure base.