Published in IET Software Received on 6th October 2008 Revised on 19th May 2009 doi: 10.1049/iet-sen.2008.0076 In Special Issue on EASE 2008 ISSN 1751-8806 Empirical study of Sommerville and Sawyer’s requirements engineering practices K. Cox 1 M. Niazi 2 J. Verner 3 1 Computing, Mathematical and Information Sciences, University of Brighton, UK 2 School of Computing and Mathematics, Keele University, UK 3 UNSW/Enterprise Analysts Pty Ltd, Sydney, Australia E-mail: mkniazi@cs.keele.ac.uk Abstract: Practices in seven key areas from requirements engineering (RE) good practice guide are examined via in-depth interviews with ten Australian software development organisations. Our objective is to provide a better understanding of the relative perceived value of the RE practices investigated and to provide an initial assessment of the appropriateness of Sommerville and Sawyer’s three classification levels. We used in-depth interviews as our main approach to collecting data. We assessed practices as either standardised use, normal use, used at the discretion of project manager or never used. We found that the single most standardised, or valuable, practice for 1) documentation, was making a business case of a project, for 2) elicitation, it was assessing system feasibility, 3) for analysis and negotiation, it was defining system boundaries, 4) for requirements description, it was to specify requirements quantitatively and to define standard templates for requirements, 5) for system modelling, it was to use a data dictionary, 6) for validation, it was to propose test cases, and 7) for management, it was to define a change management process. We suggest Sommerville and Sawyer’s classification of basic, intermediate and advanced practices needs some reconsideration to bring his list into alignment with current industry practices. 1 Introduction It has been reported that, on average, the percentage of software projects completed on-time and within budget improved from 16% in 1995 [1] to 34% in 2003 [2]. Despite this improvement, nearly two-thirds of the projects examined in the 2003 CHAOS report were ‘challenged’ (i.e. only partially successful) with the authors observing that one of the main reasons for project failure is unstable requirements. Requirements engineering (RE) is concerned with describing a client’s problem domain (the context), determining the desired effects the client wants to exert upon that domain (the requirements) and specifying the external face of the proposed IT (the specification) to (a) help enable those desired effects to occur and (b) to give designers a specification to help them build the proposed IT. The RE process has a huge impact on the effectiveness of the software development process [3]. When RE processes are ad hoc or poorly defined, the end product is always unsatisfactory [4]. Several studies have identified problems with the RE process [3, 5 – 11]. A UK study found that of 268 documented development problems and requirements problems accounted for 48% of those problems [5]. Another survey, of 150 organisations in the US, showed that the majority requirements modelling technique of choice was ‘none’ [12]. In order to improve the RE process many practices have been suggested [13]. Researchers need to be constantly aware of what is really going on in practice in order to understand which RE practices are perceived to be useful and are used by practitioners. Because research has shown that effective RE practices can provide several benefits including help in keeping to schedule, and ensuring that product quality is under control [13, 14], it is important to discover which practices benefit the software organisation. IET Softw., 2009, Vol. 3, Iss. 5, pp. 339–355 339 doi: 10.1049/iet-sen.2008.0076 & The Institution of Engineering and Technology 2009 www.ietdl.org