Catálogo de publicaciones - libros

This chapter illustrates that ambiguity is a serious problem of natural language requirements documents, which is not limited to simple language problems such as multiple referents of an “it”. The results of two empirical studies are presented, which indicate that on one hand ambiguity problems are not solved by formalization during further software development activities, and, on the other hand, it is difficult to detect all ambiguities, even if the reader is aware of all the facets of ambiguity. A combination of the results of both studies indicated that most ambiguities that slip through formalization can be detected by a previous inspection using a tailored reading technique. Based on these results, recommendations are made on how to live with the inevitable ambiguity in the RE process.

Decisions are increasingly understood as the crystallization points of the software development process. Despite the abundance of the requirements engineering (RE) processes, little attention has been given to providing appropriate support for making RE decisions. In this chapter we analyze current research related to RE decision making. We study how and when decisions are made in RE and the underlying methodology. Our focus is not to provide solution approaches for particular decision problems in RE, but to discuss strategies for improving research and practice in the RE decision making process. We have performed an extensive analysis of related research. Our findings show the difficulties in RE decision making and the deficits of current research. We position decision support at the appropriate approach to handle incompleteness and uncertainty of information as is mostly the case in RE. Based on this, we propose an agenda for future research.

An increasing part of software development is devoted to products that are offered to an open market with many customers. Market-driven development imposes special challenges for the requirements engineering process. This chapter provides an overview of the special characteristics of market-driven requirements engineering and describes the most important challenges of the area. Key elements of market-driven requirements engineering processes are presented together with a definition of process quality. Requirements state models and requirements repositories are also described and examples of typical solutions to progress tracking and data management are provided. The difficult problem of release planning is also discussed and an industrial example of a release planning process is given.

Collecting, understanding, and managing requirements is a critical aspect in all development methods. This is true for Agile Methods as well. In particular, several agile practices deal with requirements in order to implement them correctly and satisfy the needs of the customer. These practices focus on a continuous interaction with the customer to address the requirements evolution over time, prioritize them, and deliver the most valuable functionalities first. This chapter introduces Agile Methods as the implementation of the principles of the lean production in software development. Therefore, Agile Methods focus on continuous process improvement through the identification and the removal of waste, whatever does not add value for the customer.

This chapter overviews the existing methods of requirements analysis as prescribed by some of the best-known web-development methods. It also discusses the pre-eminent importance of stakeholder analysis, identification of stakeholder views and concerns, and the processes governing elicitation of web systems requirements. The chapter finally derives a model of concern-driven requirements evolution from several case studies undertaken in the area of web-enabled employee service systems.

This chapter describes the managerial processes and governance frameworks that are used to develop software applications and software-intensive systems at the Australian Bureau of Statistics (ABS). The chapter focuses on the software requirements development activities against the backdrop of a dynamic operating environment and technically challenging Information and Communication Technology (ICT) infrastructure. Recognition of the importance of software requirements engineering at a strategic level is evident, supported by senior management and with ongoing user involvement and consultation An enterprise architecture provides a framework for the integration of requirements engineering with business drivers and subsequent development practices. The software and ICT outcomes are benchmarked at or near best practice and are accompanied by above average ABS corporate performance. The ABS practices show congruence with theoretical frameworks and international standards.

As supported by many empirical evidences since early 1970s, “good quality” requirements are the leading factor for a successful software development project that delivers a “good quality” product with originally specified features and functionalities, on time, and within the originally estimated budget. The challenge gets tougher and more critical when the competition in the market is severe, the number of customers on the world is rather limited and static, and the customer demands are high. As functioning in such a market, with the main goal to maintain the leading position of the previous versions of its Stressometer®, ABB has adopted a RUP®-based software development process in the new generation Stressometer systems development projects. Stressometer Unified Process (SUP) integrates the RUP essentials with some features of agile processes such as heavy involvement of various stakeholders, preparation of test cases before coding, and continuous testing during development. This chapter describes the essential quality characteristics of requirements —both individual and aggregates such as embodied in a use-case model or in a specification, analyses the relations among them, evaluates RUP regarding the means it provides or lacks for developing “good quality” requirements, and discusses how ABB Stressometer projects have tackled these shortcomings via SUP.

To understand how to apply different requirements engineering practices and where difficulties may arise when implementing a set of requirements engineering practices, it is often useful to consider how others have done and the troubles they have encountered. This chapter describes six industry cases of applied requirements engineering, with a focus on areas where further improvements are desired by or recommended to the companies. Many of these improvement areas are also identified by other, independent, requirements engineering state of practice surveys, and thus indicate areas that warrant special attention when constructing a requirements engineering process for an organization.

The gap between research and practice in requirements engineering is immense. To understand practice and the reasons for this gap, empirical evidence about requirements engineering practice is needed. In the last ten years a number of empirical studies have been conducted to gather such data. This chapter gives an overview focusing on broad surveys. The aim of this overview is to understand the following three issues: (1) what kind of questions can and should we ask to understand practice, (2) what evidence do we have about practice, (3) what further evidence do we need about practice. To further illustrate the issues, we provide findings of new studies conducted by the authors in Germany and Australia. Altogether this chapter aims at establishing a basis for further empirical research on requirements engineering.

This last chapter of the book describes solutions and trends in the discipline of RE. Starting from a wrap-up of what was presented throughout this book, it suggests a framework of requirements engineering and indicates what current solutions are available in this framework. Beyond providing a short overview of the state of the practice, this chapter also summarizes current trends in RE. Four trends are evaluated, namely the growing usage of commercial off-the-shelf components and systems and how RE activities need to be adjusted; the evolving focus on product lifecycle management and the need to collaborate amongst very heterogeneous communities; the wish to learn and to share experiences on effective ways to implement RE in an organization and the growing interest in requirements engineers’ skill sets. We finally provide an outlook into where requirements engineering is heading for.