SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY The current state of stakeholder-driven requirements engineering CORE-project

SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY Goals of assessing the current state of the stakeholder-driven RE Describe the current challenges and practices in the Finnish software industry identify good practices and success factors offer a baseline for improving practices clarify the problem field in practical system development work

SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY Survey 18 respondents from 13 companies The respondents were asked to evaluate the most recent project they participated in during requirements engineering phase requirements quality project success succesful practices problems

SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY Projects in the survey The average project size: 163 man months RE-team: 1-34 persons, N=9,1 Hoffmann and Lehner (2001): 6.2 The proportion of requirements engineering in the project costs: 1-30 %, N= 12,6% Boehm (1981): 6% In Hoffmann and Lehner (2001) 15,7%, in successful projects: 28 %

SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY Main roles in RE-team NameNumber of projects Project manager11 Product manager8 Software developer8 Software architect3 User representative3 Customer representative3 Expert/technical expert3 Programmer2 User2

SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY Other roles in RE team Other roles found in single projects: Technical writer & documentation manager Localization, quality & management Marketing & product support Maintenance & testing Instrument developer & experimenter architect

SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY Stakeholders Direct contacts to users and customers in 33% of projects Usability specialist involved in 33 % of the projects Usability specialist part of the RE team in 22 % of the projects

SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY Success factors The presence of usability specialist had an general positive effect on requirements quality and success However, differences in the views of the parties in the project were increased Direct contacts to users and customers had even bigger effect in requirements quality and success In the most successful projects, requirements were based on real information from users or customers The RE costs were lower

SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY Respondents’ assessment of the project success (1/2) Interviewee considers the project successful: 66,7 % (Procaccino et al. (2001): 44%) Organisation considers the project a success: 50 % (Procaccino et al. (2001): 77%) The result is a success according to the customer or user feedback: 40 % The result meets the business goals: 63,7 % The result meets the requirements: 80 %

SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY Respondents’ assessements of the project success (2/2) 35,7 % completed according to schedule RE was done successfully: 41,2 % A lot of differences in the views of the parties in the project: 44,4 %

SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY Assessed successful practices Technical aspects (3) Considering customer/user needs, usability (3) Rapidness, agility, flexibility (2)

SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY Developmental needs More time for RE (4) Systematic gathering of requirements (4) Improving traceability (3) RE-processes and introduction of systematical practices (3) Systematic refining of the requirements (2) RE-tool (2)

SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY Problems in gathering and analysing Lack of resources (4) Customer/user not involved enough (4) Lack of systematic methods or practices (2) Vagueness of responsibilities (2) The documented requirements definitions/descriptions lacking (2)