Rôle of domain engineering in software development—why current requirements engineering is flawed !

• Authors: Dines Bjørner
• Venue: PSI'09 Proceedings of the 7th international Andrei Ershov Memorial conference on Perspectives of Systems Informatics
• Year: 2009

We introduce the notion of domain descriptions (D) in order to ensure that software (S) is right and is the right software, that is, that it is correct with respect to written requirements (R) and that it meets customer expectations (D). That is, before software can be designed (S) we must make sure we understand the requirements (R), and before we can express the requirements we must make sure that we understand the application domain (D): the area of activity of the users of the required software, before and after installment of such software. We shall outline what we mean by informal, narrative and formal domain descriptions, and how one can systematically — albeit not (in fact: never) automatically — go from domain descriptions to requirements prescriptions. As it seems that domain engineering is a relatively new discipline within software engineering we shall mostly focus on domain engineering and discuss its necessity. The paper will show some formulas but they are really not meant to be read, let alone understood. They are merely there to bring home the point: Professional software engineering, like other professional engineering branches rely on and use mathematics. And it is all very simple to learn and practise anyway ! We end this paper with, to some, perhaps, controversial remarks: Requirements engineering, as pursued today, researched, taught and practised, is outdated, is thus fundamentally flawed. We shall justify this claim.