Integrated Requirements Engineering Approach for Systems and Software
Ulrich Zanker Liebherr-Aerospace Lindenberg, Germany
A typical development project is sequenced in the following main activities:
System Requirements Analysis -> Software Requirements Analysis -> Software Design -> Software Coding -> Software Verification.
The process activity to be improved is in the area of system/software requirements analysis and capturing. To reach such an improvement, the idea was to use the dynamic system modelling technique for the behaviour system model (System Requirements Analysis) and directly link mathematical performance simulation models for early specification validation and rapid prototyping.
The new requirements engineering approach integrates all electronic design disciplines, system, software, hardware and quality assurance. Benefits for the software design process is a direct target and to establish a solid basement for further process improvements (i.e. hardware/software co-design) is the expected positive long term spin-off.
The original goals already achieved are the selection of an appropriate tool, training of the involved engineers, implementation and settlement of the tool and method within the system/software process. An initial package of the baseline projects specification is captured, validated by simulation and transformed to software requirements. These initial software requirements are rapidly prototyped and the risk areas are checked. A second run through system and software requirements analysis and capture was performed (enhanced application software functionality). Currently the documentation generation, result analysis and measurement and dissemination activities are in progress. The lessons learned are:
The details of this report may be of a particular interest for the aerospace community but also for organisations producing embedded system software using none-standard equipment.
This project is carried out by the electronic division of Liebherr-Aerospace Lindenberg with financial support from the European Commission under European Software and Systems Initiative ESSI, Software Best Practice, Process Improvement Experiment PIE.
LIEBHERR-AEROSPACE LINDENBERG GmbH, part of the LIEBHERR international group, works with about 1200 employees exclusively in the aerospace business, being one of the leading European equipment suppliers for civil and military aircraft’s.
The product spectrum of LIEBHERR-AEROSPACE LINDENBERG GmbH is diverted into the following areas:
LIEBHERR-AEROSPACE LINDENBERG is regarding itself as a system rather than a component supplier. This causes the demand to deal with control applications, which is electronics in general and software in particular. About 100 employees are dedicated to electronics development and production, 15 of them are in charge with software development and test for advanced fly-by-wire systems, environmental control systems and actuator embedded electronics applications.
The importance of software within these systems is steadily increasing, but also the costs of developing and maintaining software has increased to a level hardly tolerable. Nevertheless there is no way for a system supplier to omit electronics and software development, while keeping its position within this highly competitive global market. Assessments have shown that the only way to manage the situation is an incremental but continuous improvement of the development process.
The establishment of a solid basis (advanced requirements engineering methods) for this improvement activity is manpower, time and money consuming and risky in terms of immediate success. The european process improvement experiment (PIE) has been an opportunity to lower these risky items (in context with a real world program) to manageable values.
Fig. IREASS.1 : Software Lifecycle
The strengths of this proceeding is in having no formal or method overhead, design engineers work with best effort dependant on experience only.
The weak points are in having no general method, isolated tool data (simulation), communication problems with other system designers and special departments, no consistency analysis, no support for test case generation, no database export for sub-specifications.
The envisaged corrective actions is the establishment of an state of the art requirements engineering method with integrated tool support.
The strengths of this proceeding is in having structured method, tools constancy checking capabilities, tools database can be exported to software design process and software testing process.
The weak points are in having no database import from system process, communication problem with system designers, uncovered specification inconsistencies to be fed into time consuming specification change loop, hardware and software development are separated, no support for test case generation, documentation generation semi-automated instead of fully automated.
The envisaged corrective actions is the establishment of an state of the art requirements engineering method with integrated tool support, tool supported test case and documentation generation.
The strengths of this proceeding is in having structured method, tools constancy checking capabilities, tools database can be exported to software coding process and software testing process.
The weak points are in having no support for test case generation, documentation generation semi-automated instead of fully automated, limited code generation capabilities.
The envisaged corrective actions is the implementation of tool supported test case definition, enhanced code- and automated documentation -generation.
The strengths of this proceeding is in having an effective and integrated cross development tool environment.
The weak points is having very limited code generation capabilities.
The envisaged corrective actions is the gradual upgrade of tool environment to enhanced code generation.
The strengths of this proceeding is in having review and analysis techniques are supported by CASE environment and requirements traceability tool, statical software unit tests are automated.
The weak points are in having no sophisticated tool support for dynamic unit test, sw integration test and hardware/software integration test, documentation generation semi-automated instead of fully automated.
The envisaged corrective actions is the tool supported software test and automated documentation generation.
Fig. IREASS.2 : Software Fault Trend Analysis
This lead to the conclusion that the utilisation of suitable methods and CASE-tools for the system specification work would result in best benefits for the development process by founding the solid basement for further process improvement. Such the corrective action encountered above can be prioritised:
This PIE-project is completely managed and carried out by Liebherr, the prime user. For training and coaching (consultant) Scientific Computer was selected as a subcontractor, the tool producing company.
The requirements for the actuator control electronic (ACE) shall be developed in conjunction with the process improvement experiment, while the cockpit interface(COS) will serve as a reference project, with a conventional requirements engineering approach. The baseline projects are split into two work-packages each, the „initial package" implementing the minimum functionality required to make the whole system run and the „final package" implementing full functionality.
The workpackages (WP 1 - 13) defined below, are in relationship to those „initial" and „final packages" and introduced around requirements analysis, capture, simulation and validation. The termination of those workpackages are marked by internal deliverables and internal dissemination activities as defined with the workpackages. This marks serve as measured reference points for the project
Fig. IREASS.3 : Integrated Tool Overview
Fig. IREASS.4 : System Overview
Fig. IREASS.5 : Selected Tool
Fig. IREASS.6 : Basic Training (Example Model)
Add On Training WP 3
Sophisticated add on training of method and tool. The engineers of the PIE core team (system design and software design) have been trained together. The aim of this training was to enable the engineers to start a project by utilising system modelling methods and technologies.
Fig. IREASS.7 : Add On Training (Example Model)
Familiarisation with Method and Tool (Example Application) WP 4
A small example application was modelled from system specification to the software requirements. This has given the chance to familiarise with method and tool.
Fig. IREASS.8 : Example Application (Control Loop Model)
Fig. IREASS.9 : Baseline Application (Control Loop Model)
System Simulation and Specification Validation „initial package" WP 6
The system requirements for the baseline projects („initial package") have been validated by analysis and simulation. This activity was concentrated on system design personal (system engineers) but software engineers and coaching support have been involved to reach the goal of an integrated requirements engineering approach.
Fig. IREASS.10 : Control Algorithm, Simplex Simulation Model
Export of System Model Database and Software Requirements Capture „initial package" WP 7
The system models database has been exported to the software process, suitable for refinement of the software requirements from the system requirements. This activity was accomplished by the software engineers actively supported by the system engineers.
Fig. IREASS.11 : Example Application (Mode Control)
Fig. IREASS.12 : Quadruplex Voting Control Loop
Documentation Generation for System and Software Specification WP 10
Automated documentation generation of system specification and software requirements document This activity is accomplished by the software engineers actively supported by the coaching experts.
Analysis and Measurement of Results WP 11
Analysis of measured result and comparison with reference project.
External and Internal Dissemination Activities WP 12
Preparation of report and presentation material and subsequent presentation for the intended audience.
Project Management WP 13
Preparation of PIE-project schedules, observation of effort and results and applicability of measured reference points. The project schedules and resources are co-ordinated with the companies product planning system PPS. The technical co-ordination and observation is accomplished by an assigned engineer, assisted by the integrated configuration management and problem reporting tool STS.
At this time, the experiment is ongoing and especially the results and analysis are of preliminary nature and not complete. The full and final results will not become apparent until the remainder of the experiment is completed.
The measurement of results in form a fault trend analysis is in progress. As a preliminary result we can see good stability of system/software requirements for the ACE control loop (baseline project), whilst the requirements of the COS are still moving.
We expect that the early detection of the ACE functional architecture inadequacy has already contributed positively to the return on investment but this is difficult to quantify. The exceptional "early" stability of the requirements we can observe let us expect positive results from the fault trend analysis and a better lines of code per hour relationship compared to the reference projects measurement.
This section should detail the actual results of the experiment and your analysis (how you interpret the results) in terms of the original objectives of the experiment
Include qualitative and quantitative results and how they were measured. Provide details of any mid-term assessment, and, as far as possible, give real numbers.
Consider the results from each of the following perspectives:
Training and Familiarisation with Method and Tool: - After the intensive training, the core part of the system specification of a small sample application (landing gear steering system) have been validated. The positive effect, compared to a none PIE overlaid project, was a very detailed knowledge of the steering control problems and side-effects, despite the application is completely new and no prototype hardware is available at that time.
System Requirements Capture and Specification Validation: - The intensive simulation activity for specification validation, driven mainly by the PIE-activity, has finally shown that the selected hardware/software architecture (control-monitor philosophy) is not adequate for this actuator control application. This inadequacy was detected at an very early stage of the project, compared to conventional projects, where the problem would have been discovered much later, probably during system integration phase.
Software Requirements Capture and Rapid Prototyping: - The software requirements capturing activity is considered to be more effective due to involvement of software engineers in specification validation and due to increased confidence into correctness of specified functions and algorithms. The rapid prototyping (within a target prototype) is considered as a second key activity (beside the specification validation). This activity has to deliver the final confidence into the selected hardware/software design to be adequate in terms of performance. An early result is the fact that the automatic code generation capability, provided by the simulation tools, are could not be used for this project due to the selected „unique" hardware/software design.
This leads to the expectation that automatic code generation cannot contribute a significant benefit to this type of application (dedicated, unique airborne equipment), but could have an enormous potential when using standard (off-the-shelf) equipment, which is a clear trend in the avionics community.
Documentation Generation: - The documentation generation capability is currently an extremely weak point of the selected method/tool. In that area we are missing the automated assistance of a "traditional" CASE tool. The documentation generation for the project is not automated as expected.
Describe the results of the project in terms of their impact on the business operation. Detail the project's effect on business, and assess whether it was positive or negative. If possible, give information that can be used for cost/benefit analysis.
Consider typical questions that a senior manager contemplating a similar change might ask.
Describe whether the project had any impact on the organisational environment. Give reasons for these changes.
Comment on the people related impact of the experiment. Did involvement of the people concerned have a positive impact? Was there any resistance to adopting more rigorous methods and how was this overcome?
Comment here on any additional skills acquired by the project staff as a result of the experiment.
In most of the projects, the nature of the experiment implies considerable change for the professionals involved, in terms of their way of working, their skills and disciplines, etc. Comment on the impact of the experiment on these areas.
This section should summarise the key lessons that you have learnt from undertaking the experiment.
As the report is expected to interest both software developers and senior managers, please ensure that this section caters for these target audiences, and identifies clearly your key lessons learnt, from the technological and business point of view.
The use of standard tools is most effective if using standard hardware/software architectures/platforms and less effective when working with dedicated, unique designs.
Early specification validation is a key feature for adequate system, hardware and software design.
Rapid prototyping, with target prototypes is essential for design confidence in case of embedded real time applications.
Typically three or four main lessons, from a software engineering point of view
The market provides new tools, technology and knowledge within very short update rates, but not every technology or tool fits to a given application.
There is an excellent return of investment if choosing an adequate tool and method and there is only cost if selecting an inadequate.
Typically three or four main lessons, from a business point of view
Pros:
Identify any specific changes that you would make to your approach if you were to repeat the experiment.
As a first and preliminary conclusion the conduction of the experiment has shown the correctness and adequacy of experiments philosophy - founding a solid basement with the integrated requirements approach for future process improvements. It became obvious that process improvement has to be a continuos action driven by the appearance of new technologies.
A key feature to gain good support from the market (tools, expert knowledge) is to change to standard architectures in software and hardware as far as it is possible in our field of applications.
It is evident that we have to apply the selected simulation environment to a new project, having in mind the strength and weakness encountered during the experiment. And we shall try to introduce the next step, identified when analysing the starting scenario - the hardware/software co-design.
References
[1] RTCA/DO-178B, Software Consideration in Airborne Systems and Equipment Certification, RTCA-Requirements and Technical Concepts for Aviation, RTCA, Inc. 1140 Connecticut Avenue, N. W., Suite 1020 Washington, D.C: 200036, USA 1992
[2] ARP 4754, Certification Considerations for Highly-Integrated or Complex Aircraft Systems, System Integration Requirements Task Group, SAE-Society of Automotive Engineers, Inc., USA
[3] DOD-STD-2167A, Defense System Software Development, Military Standard, Department of Defense Washington D.C. 20301, USA 1988
ACT/FHS Active Control Technologie Demonstrator - Fliegender Hubschraubersimulator
CASE Computer Aided Software Engineering
COS Cockpit Interface
DLR Deutsche Forschungsanstalt für Luft- und Raumfahrt
ECD Eurocopter Deutschland
LLI Liebherr-Aerospace Lindenberg GmbH
PIE Process Improvement Experiment
PPS Product Planning System
SA Structured Analysis
SD Structured Design
RT Real Time
Appendix
Author
Ulrich Zanker, graduated at Fachhochschule Munich with Dipl. Ing. (FH), is working for Liebherr-Aerospace Lindenberg since 1983.
He has experience in developing software for airborne computers like: Airbus A310 Slat Flap Control Computers (Flight Controls) and Airbus A320 Zone Controller (Environmental Control System).
Another field of experience is the introduction and administration of the technical computer system for the electronic department (VAX-Cluster, Unix Workstations and networked PCs).
Since 1993 he is heading the software group (currently 16 software engineers) of the Liebherr-Aerospace electronic department, producing safety critical software for airborne computers as well as software for the associated test systems (test benches and simulators).
Company