Requirements Engineering (RE) is the process of establishing a set of requirements to create designs for a software system. RE involves requirements elicitation, analysis, specification and validation. The techniques used to obtain requirements include conducting interviews, gathering user stories, observing the system being used and prototyping concepts to the users of the proposed system. RE clarifies the actual requirements of the system become more apparent for the development team.
Incorrectly elicited requirements, such as overlooking crucial requirements, will result in a fault and will become a major problem for resources at a later stage in the project life span. RE avoids this problem by having processes and techniques prepared to minimise the chance of missing requirements. A welldefined set of requirements allows for a design that is closer to the finished product to be developed and will help to reduce the complexity of implementing any requirements changes later in the project, i.e. development is already underway, and the smallest change could render the whole system unviable.
In Bosch’s development of their safety-critical systems, RE is crucial for the avoidance of late stage errors to safeguard the reliability and integrity of their software. A study on requirements errors in safety-critical systems found that the main cause of safety-related functional faults is not comprehending the requirements, this accounted for 62% on the Voyager spacecraft and 79% on Galileo. “Functional faults, being an operational, conditional or behavioural discrepancy with the functional requirements” (Lutz, 1993) were the reason for 52% of faults on Voyager and 47% on Galileo. They were the most common type of software error, with requirements being the main cause of safety-related software errors that are not found until integration and testing.
Due to the findings of multiple studies presented in the publication, it is safe to say that the earlier the bug was introduced and the later it was discovered, the longer it will take and the more expensive it will be to fix (Lutz, 1993). Therefore, well-defined requirements, elicited through a structured approach such as formalised RE, are integral for preventing project failures, and reducing resource waste, such as time and money, trying to fix a fault that could potentially be avoided.
Software Configuration Management
Software Configuration Management (SCM) is a practice that involves using standardised processes, tools and methods that are frequently used by businesses to organise and manage the software modifications it introduces to its products. This is done through identifying the components likely to change and the relationships they share as well as how different versions, and the changes that have been made are to be managed. SCM looks to take charge of the changes introduced to the software it manages by using reliable version selection and control. SCM maintains the software’s current state, the baseline, while at the same time it enables developers to work on new versions for bug fixes and additional features. SCM is the organisation of a software systems components so that they fit together in working order to provide the capacity to communicate the status of a document, source code and any changes that were made.
SCM makes it easier to provide maintenance to software once it is released, this improves upon reliability, resource consumption and project management by making the software reusable and improving the ease of integration with a new system by keeping track of all artefacts, including documentation, source code, issues resolved and unresolved as well as all changes made. This makes the organisation of complex software systems a more manageable task by preventing fragmentation of the project due to multiple developers working on the same file where SCM control is not in place, without it the last developer to save will be the only one to keep their changes. Furthermore, SCM provides a framework for new staff who replace departed team members mid-project and take their knowledge of how to produce an increment with them. Thus, providing the foundations for people to
learn what has happened already in the project and allows new staff to familiarise themselves with the organisations processes and project status (Futrell, Shafer, & Shafer, 2002).
Another firm who utilise SCM in their development is Cisco, who adopted the practice in 2003, due to the complexity of their upcoming release of Oracle 11i. The previous practices used were deemed as unfit for purpose due to the complexity of Oracle 11i. Cisco now use a dedicated team to utilise SCM and in doing so they have improved upon software quality, they have reduced risk, increased productivity, enhanced scalability and improved IT service to the internal clients (Cisco, 2007).
As Mössinger states that “SCM is the backbone for handling the huge number of variants” (Mössinger, 2010) you can see that SCM is an important tool for complex systems where there are a large number of components and processes that must be compatible to provide a reliable system. This is illustrated by the way Cisco and Bosch both adopt SCM to effectively manage these complex systems in an efficient manner. This is done to produce higher quality and more reliable software.
AUTOSAR and Model-Based Design
The growing complexity in automotive software systems which consist of many electronic control units (ECUs) and bus systems to allow interaction between software on various ECUs has meant that it is more difficult to produce the same standard of high-quality software. To combat this AUTOSAR is being developed perpetually by over 150 organisations in the automotive industry, including Bosch, BMW and Volkswagen, this is to provide a standardised framework for ECU networks, that support scalability to allow its use on as wide a variety of motor vehicles as possible. This enables resources to be diverted away from architecture and can be used to develop further advancements in the industry.
Model-Based Design provides the ability to visualise and simulate the software designs as a form of virtual prototyping which reduces costs by eliminating the need for multiple prototypes that could get very expensive. MBD also enables automatic code generation of algorithms which provides the capability to reuse the entire infrastructure. MBD is also used for “communicating component requirements and interface definitions between customer and supplier”, which allows for early error detection and prevention which in turn reduces the time it takes to produce an increment. (Sandmann & Thompson, 2008)
Automotive engineers use MBD to handle the complexity of the software being developed by using MATLAB and Simulink which has been stated to “improve product quality and reduce development time by 50%” (MathWorks, 2018) as well as reducing “validation time by 40-50%” (MathWorks, 2018). Early verification and validation can minimise the risks of detecting errors later in the project, such as during implementation. If the during perpetual verification and validation any errors are found, MBD allows the software to be regenerated very efficiently resulting in huge time savings saves.
Overall the combination of the AUTOSAR framework being used in conjunction with RE, SCM and MBD allows Bosch to produce very high-quality software, a vital element in safety-critical systems that could potentially put a person’s life at risk, thanks to the strict guidelines in ensuring requirements completeness and integrity, the greatly improved management of software during development and the ability to cost effectively simulate virtual prototypes and test the designs for the system.