Grants and Contributions:

Grant or Award spanning more than one fiscal year. (2017-2018 to 2022-2023)

Requirements Engineering (RE) is concerned with the elicitation, modelling and analysis of stakeholder requirements in order to derive a specification for a system-to-be, to be passed on to designers. RE is widely considered the most critical stage in software development, literally the one that makes or breaks projects. Given persisting high failure rates for software projects, we propose to work towards advancing the state-of-research in RE by laying the foundations for making RE an engineering discipline.

These foundations are based on three principles: (a) Requirements represent stakeholder needs and are modelled as goals, to be fulfilled by the system-to-be; (b) The transformation of these goals -- however informal, conflicting, vague, etc. — is to be based on the application of a set of refinement operators, where each application transforms a goal into a more concrete one, much in the spirit of the Refinement Calculus of Hoare, Abrial, et al; (c ) The transformation process is be supported by refinement tools that transform one or more goals into one or several more concrete ones; (d) The selection of optimal specifications for a given goal model should be supported by a reasoning tool that carried out sound, complete and scalable reasoning, even for goal models with thousands of elements (nodes and links). We are proposing to work on such foundations having in mind socio-technical systems (systems that consist of software, but also business processes and human actors) as well as cyber-physical systems that involve both software and physical components, e.g., robotic devices, because these are important application areas for software engineering.

In addition to these foundations, we propose to revisit requirements specification languages with an eye towards making them more expressive so that they can express security, performance and other mechanisms used in software engineering practice, which — in our view — cannot be accounted by current specification techniques, formal or otherwise.

Finally, we are interested in studying specific classes of requirements, aiming to (a) formalize them; (b) study alternatives ways of operationalizing them, based on the literature. One such class is the class of acceptance requirements. These are requirements of the form “X% of community Y will use the system”. They are critical requirements for social software. After all, if a system isn’t used, it is a failure! Another class concerns minimizing bureaucratic overhead in offering a (computer-based) service. Such requirements are understandable to anyone who has used a government service and was bothered by long waits, long turn-arounds, too much information being requested, and (in some countries) even the need to bribe in order to get what you need. Here, we want to characterize such “minimize bureaucracy” requirements and study alternative ways they can be fulfilled by referring to the literature.