Campus Event Calendar
Event Entry
What and Who
The Role of Domain Engineering in Software Development - or why current ideas of Requirements Engineering are all wrong !
Dines Bjorner
Technical University of Denmark
Talk
AG 1, AG 4, RG1, MMCI, AG 3, AG 5, SWS
Public Audience
English
Note: We use this to send email in the morning.
Date, Time and Location
Tuesday, 17 March 2009
16:15
45 Minutes
E1 3
001
Saarbrücken
Abstract
We introduce the notion of domain descriptions (D) in order to ensure
that software (S) is right ^1) and is the right ^2) software, that is, that it is correct with respect to written requirements (R) and that it meets customer expectations.
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
description, 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 talk will show some formulas but they are really not meant to be
read by the speaker, let alone understood, during the talk, by the
listeners. They are merely there to bring home the point:
that professional software engineering, like other professional
engineering branches rely on and use mathematics. And it is all very
simple to learn and practise anyway !
1) Software is right when it fulfills its requirements.
2) It is the right software when that software meets customers expectations.
that software (S) is right ^1) and is the right ^2) software, that is, that it is correct with respect to written requirements (R) and that it meets customer expectations.
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
description, 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 talk will show some formulas but they are really not meant to be
read by the speaker, let alone understood, during the talk, by the
listeners. They are merely there to bring home the point:
that professional software engineering, like other professional
engineering branches rely on and use mathematics. And it is all very
simple to learn and practise anyway !
1) Software is right when it fulfills its requirements.
2) It is the right software when that software meets customers expectations.
Contact
reindel
--email hidden
passcode not visible
logged in users only
gk-sek, 03/10/2009 09:35
gk-sek, 03/10/2009 09:35 -- Created document.
gk-sek, 03/10/2009 09:35 -- Created document.