Paul Grünbacher

Anna Perini

This book constitutes the proceedings of the 23rd International Working Conference on Requirements Engineering - Foundation for Software Quality, REFSQ 2017, held in Essen, Germany, in February/March 2017. The 16 full papers and 10 short papers presented in this volume were carefully reviewed and selected from 77 submissions. The papers were organized in topical sections named: use case models; ecosystems and innovation; human factors in requirements engineering; goal-orientation in requirements engineering; communication and collaboration; process and tool integration; visualization and representation of requirements; agile requirements engineering; natural language processing, information retrieval and machine learning traceability; quality of natural language requirements; research methodology in requirements engineering.

23rd International Working Conference, REFSQ 2017, Essen, Germany, February 27 – March 2, 2017, Proceedings

Requirements Engineering: Foundation for Software Quality

Barry Boehm

Stefan Biffl

Hakan Erdogmus

Aybuke Aurum

Ross Jeffery When, as a result of pressure from the CEO, the Chief Information Officer poses the question “Just what is this information system worth to the organization?” the IT staff members are typically at a loss. “That’s a difficult question,” they might say; or “well it really depends” is another answer. Clearly, neither of these is very satisfactory and yet both are correct. The IT community has struggled with qu- tions concerning the value of an organization’s investment in software and ha- ware ever since it became a significant item in organizational budgets. And like all questions concerning value, the first step is the precise determination of the object being assessed and the second step is the identification of the entity to which the value is beneficial. In software engineering both of these can be difficult. The p- cise determination of the object can be complex. If it is an entire information s- tem in an organizational context that is the object of interest, then boundary defi- tion becomes an issue. Is the hardware and middleware to be included? Can the application exist without any other applications? If however the object of interest is, say, a software engineering activity such as testing within a particular project, then the boundary definition becomes a little easier. But the measure of benefit may become a little harder.

Paul Grünbacher

About

Books

Join the club