Software requirements & specifications: a lexicon of practice, principles and prejudices
Software requirements & specifications: a lexicon of practice, principles and prejudices
Four dark corners of requirements engineering
ACM Transactions on Software Engineering and Methodology (TOSEM)
Software engineering education: Rôles of formal specification and design calculi
Annals of Software Engineering - Special issue on software engineering education
Annals of Software Engineering
Pinnacles of software engineering: 25 years of formal methods
Annals of Software Engineering
Problems, Methods and Specialization
IEEE Software
RTSE '97 Proceedings of the International Workshop on Requirements Targeting Software and Systems Engineering
Problems and requirements [software development]
RE '95 Proceedings of the Second IEEE International Symposium on Requirements Engineering
Investigating a new formal model for autonomous virtual organisation using RAISE method
International Journal of Networking and Virtual Organisations
System verification through program verification
FM'11 Proceedings of the 17th international conference on Formal methods
What's wrong with git?: a conceptual design analysis
Proceedings of the 2013 ACM international symposium on New ideas, new paradigms, and reflections on programming & software
| Hi-index | 0.00 |
Before software can be developed its requirements must be stated. Before requirements can be expressed the application domain must be understood. In this invited paper we outline some of the basic facets of domain engineering. Domains seem, it is our experience, far more stable than computing requirements, and these again seem more stable than software designs. Thus, almost like the universal laws of physics, it pays off to first develop theories of domains. But domain engineering, as in fact also requirements engineering, really is in need of thoroughly researched development principles, techniques and tools. The aim of this invited paper is to advocate: that researchers study these development method components, and that universities focus their education on basing well-nigh any course on the use of formal techniques: Specification and verification, and that software engineers take heed: Start applying formal techniques. A brief example of describing stake-holder perspectives will be given--on the background of which we then proceed to survey the notions of domain intrinsics, domain support technologies, domain management & organisation, domain rules & regulations, domain human behaviour, etc. We show elsewhere how to "derive" requirements from domain descriptions. Domain requirements: by domain projection, instantiation, extension and initialisation; interface requirements: multi-media, dialogue, etc.; and machine requirements: performance, dependability (reliability, availability, accessability, safety, etc.), and maintainability (adaptability, perfectability and correctability). The current paper presents work-in-progress. The text of the paper is therefore very schematic.