Report on CEIRE '98 

Hugh Davis (DERA), 29th October 1998

 This was my first foray into the world of requirements engineering. The conference had a lively atmosphere and was well balanced between academic papers, workshops, tutorials and an exhibition of tools and books. Over 100 delegates pre-registered, with a preponderance of researchers but a good minority of practitioners (consultants and representatives of large companies who probably work as internal consultants). Here are some of the highlights for me, and my impressions of requirements engineering. (I will avoid the abbreviation RE although the expansion remembered from my school days is almost apposite.)

The conference brought to mind the enthusiasm at Ada conferences a decade ago. After pondering the significance of this I came to the relatively positive conclusion that, although the technology and tools may soon be consigned to oblivion and the movement may not produce the benefits that it promises, it is a focus of a continuing concern with the development of system and software engineering that noticeably improves with each passing decade. So, we should listen to what is said, and think about it, but not write Requirements Engineer in our passports.

This view gained support in a workshop on Requirements Engineering Education. There was wide-spread interest (which passed me by) in academic minutiae such as how to mark group work that contributes towards the class of a degree, but no answer to the question of what is the subject matter of requirements engineering. The syllabuses of three first degree courses in requirements engineering were presented, but the presenters admitted that they are used to draw together topics from other standard courses rather than to cover a well-defined subject.

Further scepticism was generated in an entertaining talk by Ray Paul called Why Requirements Engineering is an Oxymoron, but Michael Jackson gave us hope in his keynote address on A Discipline of Description, a tour de force in clarity of thought and exposition, and an inspiration for all who try to interpret the needs of those who don't know what they want for those who wouldn't understand anyway.

At a more pragmatic level Colin Potts made sense of use cases and the like in a tutorial on Scenario-Base Requirements Determination.

The most interesting workshop for me was on Systems Engineering – what is it and what is unique to it? The facilitator won my support at the outset by saying that the more he grapples with system engineering, the more it slips through his fingers. All he sees is an impoverished form of software engineering. (He later lost my support by calling me a reductionist, but the sad truth is that, for all we talk of emergent properties, system engineering today is merely a process of reductionism.) Whether or not we answered the set questions, I found it enlightening for my interest in the relationship between system and software engineering. Both can be used in a broad sense covering all aspects of the whole development life cycle or in a narrow sense limited to the implementation of software and of mixed technology components respectively. (The narrow sense of system engineering ought to be uncommon, but there were hardware-oriented engineers at the workshop who could not see the engineering of heterogeneous systems as more than a problem of management and of communication between different disciplines, which trivialises system engineering to its narrow sense.) Although the use of software engineering for a programmer, possibly even without any work experience, is an abuse, the use of software engineering in the narrow sense is acceptable. It would be nice if the use of software engineering in its broad sense could be replaced by system engineering since there is no distinction between broad system and software engineering, once the construction of components using specialist engineering disciplines is excluded. This is inevitably so because both are about the modelling of system information that is abstracted from implementation details.

Whilst the workshop simply reinforced my view that system engineers can learn from broad software engineering, it seems to me (and this point was not made explicitly in the workshop - on the contrary) that narrow software engineers, who mainly integrate other components, whether COTS packages or reusable objects, need to learn disciplines common to different hardware technologies. We should no longer get away with the notion that software has no physical properties such as weight and size. Software components are embodied in hardware (memory, processes, communication links, etc.) which is only there to run software, and they take a finite (sometimes infinite) time to perform functions.