Requirements engineering

Abstract

In many systems engineering activities the elicitation of requirements is regarded as a central activity for the efficient and effective functioning of the intended system. In recent years, requirements engineering (RE) has been established as a distinct field of investigation and practice. Its application has evolved from being concerned initially with software systems (IEEE-Std. 729, 1983; IEEE-Std. 830, 1984) to a broader perspective that extends to incorporate other aspects of systems and of the environment in which these systems function (Greenspan et al., 1994; Loucopoulos and Karakostas, 1995; Pohl, 1996;Yu, 1997; Zave, 1997). This broader view of RE is based on the premise that, in designing systems, requirements engineers aim to 'improve' organisational situations which are seen as problematic - or, at least, as needing some change. Hence, the problem of system design moves closer to addressing a wider set of problems found within organisational settings.Within this context, requirements are usually classified as functional requirements and non-functional (or quality) requirements. Whilst the former are concerned with the identification of intended system behaviour, the latter address issues relating to service provision for the intended usage of the system. RE typically deals with a class of problems that have been termed "illstructured problems" (Reitman, 1965; Rittel and Webber, 1984; Simon, 1984).The problem state is not a priori specified and there is no definitive formulation.To a great extent, formulating the problem amounts to solving it. The success of the RE process often depends on the ability to proceed from informal, fuzzy individual statements of requirements to a formal specification that is understood and agreed by all stakeholders. However, the process is far from deterministic or straightforward. The aim of this chapter is to outline the process of RE and to focus on two complementary techniques that facilitate this process, namely, goal modelling and business rules modelling. Conventional methods of system development offer a prescriptive approach to RE.The traditional view of requirements definition is that this phase of systems development begins with an informal description of 'what' the system is expected to do. However, recent research, supported by experiences in the industrial domain, recognises that successful system development relies upon the ability to understand and represent not only what the system should do, but also 'why' (Loucopoulos and Kavakli, 1995;Yu, 1997;Yu and Mylopoulos, 1998). Understanding the 'why' (teleological) dimension in systems development is necessary to ascertain and justify the presence of requirements components which may not be comprehensible to clients and users. Goals express intention and capture the reason for the system to be built.According to their degree of specificity, enterprise goals can be organised into goal hierarchies.Vague, highlevel goals are refined into concrete, formal goals.This refinement is necessary because only simple primitive goals can be operationalised. Operationalisation is the process of refining goals so that the resulting subgoals have an operational definition (Anton et al., 1994).The most common approach to goal operationalisation is that of goal reduction. Goal modelling techniques that are used within the RE process are presented later. A process that is allied to goal operationalisation is business rules modelling. This activity concerns the definition of static and dynamic constraints (Loucopoulos et al., 1991). Naturally, business rules, as part of requirements gathering and systems analysis, have not been ignored by structured analysis, information engineering or object-oriented analysis approaches (Moriarty, 1993), which, to varying degrees, subsume or represent business rules as part of notation schemes used to specify application requirements (Gottesdiener, 1999).The way that business rules relate to stakeholder goals and are modelled for the purpose of describing the key issues of the application domain is also presented later. © Springer-Verlag London Limited 2005.