Software development reimagined – Part 2: Avoiding typical errors through comprehensive software requirements

In the software requirements, developers describe the purpose and intent of a software system as well as its (external) behavior. What expectations do users have of the software product, and how user-friendly is it? How clear is the program structure, how well-organized is the programming, and how understandable is the documentation? Answering these and other questions can help avoid many errors. 

Approximately 501,300 typical errors in a system's software are based on missing or incorrect requirements. The end result of requirements engineering is the development and maintenance of a meaningful System Requirements Specification document that addresses the following requirements:

• Business requirements: Here, management and marketing define the product's goals.
• User requirements: Requirements for the software system from the user's perspective
• Functional requirements define the behavior of the software system in such a way that user requirements can be met.
• Project requirements: What must be fulfilled for the software project to successfully implement the functional requirements? This aspect focuses on lifecycle management and includes the documentation of the software system as well as necessary legal requirements. These include, among other things, licenses for the software tools and hardware components used, consideration of copyrights/trademarks and patents, and quality requirements for the service.

Especially when considering functional requirements, software quality characteristics come into play. At this point, comprehensive analyses of aspects such as multicore usage, safety, and security within the project are worthwhile.

Figure 1: Tasks of Requirements Engineering

Requirements engineering also comprehensively considers the following software requirements:

• Standards and standards, for example ISO 26262 (ISO standard for safety-related electrical/electronic systems in motor vehicles) and IEC 61508 (Functional safety of electrical/electronic/programmable control systems)
• Which Software modules or software stacks are being used?
• Which Programming interfaces are used?
• Which Quality assurance Should it be used?
• Creating a Rules for program development (Clean Code, Solid Principle, etc.), static code analysis methods, unit tests, system tests

Once all these requirements are met, the data types/structures and access methods used (such as pointers), their lifespan, the amount of memory used, and any concurrent memory accesses are analyzed in relation to these requirements. An examination of the integrity of the tools, files, and libraries used (especially version control systems like CVS) is also part of this process.

Furthermore, the question arises: Which data backup methods and error responses should be used? From a safety perspective, this is particularly important. FMEA (Failure Mode and Eeffects Aanalysis) into play:

Figure 2: FMEA – Failure Mode and Effects Analysis

Are all real-time requirements met?

In this context, system performance requirements are particularly important. Are all tasks completed within the expected and tolerable timeframe? This is especially relevant when it comes to task and function response times, data throughput, and the timely availability of resources. Clear requirements must be defined from the perspective of both static and dynamic behavior.

What about system flexibility?

Scalability, maintainability, extensibility, reusability, and the system's use in an international environment are also key aspects of the requirements analysis.

Figure 3: Multicore, Safety and Security and new challenges

When using multicore in the context of safety and security, what additional requirements need to be considered and specified?

• Type and access rights when using core private and global memory (RAM, ROM, Flash etc.)
• In multicore architectures, consideration is given to the specification of the control and synchronization of parallel processing of functions and processes, as well as the specification of the requirements for reset and boot behavior (especially in multicore).
• Adequate and individual protection and allocation mechanisms for storage resources with a close look at safety-relevant functions, processes and peripherals used from the perspective of the individual accessing cores.
• Inter-core communication and synchronization
• Specification of global time sources and synchronization mechanisms (Time Synchronization Mechanism)
• Requirements for operating systems such as multicore RTOS (Real-Time Operating System), especially when using different safety classes and security
• Analysis and specification of dynamic processes, functions and procedures
• For the application of stacks and libraries, the structure as well as the application and test specifications must be defined, especially with regard to multicore, safety and security.
• Specification of the protection mechanisms for security functions, processes and procedures (e.g. communication), resources (e.g. storage) through firewalls, cryptographic protection of storage contents and data communication when using high-security modules (HSM), as well as specification of the required or necessary cryptographic methods.
• Specification of communication management – who is allowed to communicate with whom and who is required to communicate with whom? For example, when using different bus systems: transparent communication processes and synchronization mechanisms (such as the specification of gateways).
• Definition of requirements for dynamic methods when using multicore, safety and security
• For error detection and error handling, especially in the case of safety requirements, a specification of the methods, scope and procedures must be made.
• Specification of diagnostic methods and diagnostic interfaces
• Specification of static and dynamic test methods, in particular data logging, debugging and trace methods, taking into account multicore, safety and security.
• Specification of the type of symbol definition to be used with regard to multicore
• Specification of software update methods and their safeguarding mechanisms, from a static perspective and, if required, also for dynamic software updates.
• Specification of documentation requirements

Conclusion

When using multicore systems, a comprehensive and detailed requirements analysis with safety and security requirements for system security becomes the key to project success.

The other parts of this series on this topic Embedded software development considering multicore, safety, and security aspects They deal in more detail with current influences and challenges, software architecture and software testing. Part 1 This article examines how multicore technology, safety, and security aspects are changing today's software projects. Part 3 This is about the topic of software architecture.

Gain the right knowledge about embedded software development, multicore, and safety & security. MicroConsult offers professional training and coaching on these topics – in live online and in-person formats.

Further information

MicroConsult Expertise: Multicore & Microcontrollers

MicroConsult Training & Coaching: Multicore & Microcontrollers

MicroConsult Expertise: Embedded Software Development

MicroConsult Training & Coaching: Embedded SW development

MicroConsult expertise: Safety & Security

MicroConsult Training & Coaching: Safety & Security

All MicroConsult training & coaching