The methodological soundness of requirements engineering papers: a conceptual framework and two case studies

This paper was triggered by concerns about the methodological soundness of many RE papers. We present a conceptual framework that distinguishes design papers from research papers, and show that in this framework, what is called a research paper in RE is often a design paper. We then present and motivate two lists of evaluation criteria, one for research papers and one for design papers. We apply both of these lists to two samples drawn from the set of all submissions to the RE’03 conference. Analysis of these two samples shows that most submissions of the RE’03 conference are design papers, not research papers, and that most design papers present a solution to a problem but neither validate this solution nor investigate the problems that can be solved by this solution. We conclude with a discussion of the soundness of our results and of the possible impact on RE research and practice.     

Promoting software quality through a human,social and organisational requirements elicitation process

Human, social and organisational (HSO) factors play a decisive role in software development in terms of determining functional and non-functional characteristics of software products. The significance of these factors is underlined by the need to produce applications that fit nicely in a working setting, supporting the working procedures followed and promoting users' content and productivity. In this context, a new requirements elicitation process is proposed, a part of which utilises a short-scale ethnography analysis. The process introduces specific steps for recording HSO factors based on certain software quality characteristics that are treated as principal components for conducting requirements identification. The output of the process is the HSO document, which can be used in conjunction with the classic requirements document to identify structural and functional aspects of the system.     

The top risk of requirements engineering

The worst thing that can happen in requirements engineering is that your set of requirements, however expressed, doesn't accurately represent your users' needs and consequently leads your team down the wrong development path. The whole point of requirements engineering is to steer your development toward producing the right software. If you don't get the requirements right, how well you execute the rest of the project doesn't matter because it will fail. The article looks at how we can be led astray     

A case study validation of a knowledge-based approach for the selection of requirements engineering techniques

Requirements engineering (RE) is a critical phase in the software engineering process and plays a vital role in ensuring the overall quality of a software product. Recent research has shown that industry increasingly recognizes the importance of good RE practices and the use of appropriate RE techniques. However, due to the large number of RE techniques, requirements engineers find it challenging to select suitable techniques for a particular project. Unfortunately, technique selection based on personal experience has limitations with regards to the scope, effectiveness and suitability of the RE techniques for the project at hand. In this paper, a Knowledge-based Approach for the Selection of Requirements Engineering Techniques (KASRET) is proposed that helps during RE techniques selection. This approach has three major features. First, a library of requirements techniques was developed which includes detailed knowledge about RE techniques. Second, KASRET integrates advantages of different knowledge representation schemata and reasoning mechanisms. Thus, KASRET provides mechanisms for the management of knowledge about requirements techniques and support for RE process development. Third, as a major decision support mechanism, an objective function evaluates the overall ability and cost of RE techniques, which is helpful for the selection of RE techniques. This paper makes not only a contribution to RE but also to research and application of knowledge management and decision support in process development. A case study using an industrial project shows the support of KASRET for RE techniques selection.

The fundamental nature of requirements engineering activities as a decision-making process

The requirements engineering (RE) process is a decision-rich complex problem solving activity. This paper examines the elements of organization-oriented macro decisions as well as process-oriented micro decisions in the RE process and illustrates how to integrate classical decision-making models with RE process models. This integration helps in formulating a common vocabulary and model to improve the manageability of the RE process, and contributes towards the learning process by validating and verifying the consistency of decision-making in RE activities.     

需求工程的探讨

软件工程被分为需求、设计、实现、测试等几个阶段,其中需求阶段是一个项目的开端,也是项目成功的基石。在软件工程中,需求分析指的是在建立一个新的或改变一个现存的电脑系统时描写新系统的目的、范围、定义和功能时所要做的所有的工作。需求分析是软件工程中的一个关键过程。在这个过程中,系统分析员和软件工程师确定顾客的需要。只有在确定了这些需要后他们才能够分析和寻求新系统的解决方法。在软件工程的历史中,很长时间里人们一直认为需求分析是整个软件工程中最简单的一个步骤,但在过去十年中越来越多的人认识到它是整个过程中最关键的一个过程。假如在需求分析时分析者们未能正确地认识到顾客的需要的话,那么最后的软件实际上不可能达到顾客的需要,或者软件无法在规定的时间里完工。     

Portraying the practice of decision-making in requirements engineering: a case of large scale bespoke development

Complex decision-making is a prominent aspect of requirements engineering (RE) and the need for improved decision support for RE decision-makers has been identified by a number of authors in the research literature. A first step toward better decision support in requirements engineering is to understand multifaceted decision situations of decision-makers. In this paper, the focus is on RE decision-making in large scale bespoke development. The decision situation of RE decision-makers on a subsystem level has been studied at a systems engineering company and is depicted in this paper. These situations are described in terms of, e.g., RE decision matters, RE decision-making activities, and RE decision processes. Factors that affect RE decision-makers are also identified.     

The good, the bad, the complex: Computers and Composition in transition

In this article I use Albert Borgmann’s (1984) four-part theory of technology to analyze various contributions to Computers and Composition—initially enthusiastic, sometimes fearful, and later aware of the complexities of technology and the need for anchoring discussions of technology in theory and pedagogy. By applying Borgmann’s theory, I show how readers of Computers and Composition can follow the 20-year development of technological awareness in the journal, and I also show possibilities for future directions the journal can take.     

The ethics of NHS computing: A terminal case

Value in the British National Health Service have shifted away from patient care towards financial control. However, in the quest for efficiency, huge amounts of NHS money have been wasted on computer system which failed. In this paper, I draw on a case study to explore some of the ethical issues which underlie this kind of waste of resources. Issues include the gap between public pronouncements and personal experience, the chaos of which lies behind the facade of rationality, and the systematic silencing of people, usually women, who question the viability of computer systems which are created for private gain rather than public service.     

A requirements engineering environment within a tightly integrated SDE

This paper describes the outside functionality of an RE environment within an integrated software development environment. Furthermore, an integrator tool for the transition to software system architecture modelling is presented. The tools discussed are editors, analysers, executors, monitors, and integration tools of different characteristics for horizontal integration (within RE) and vertical integration (to architecture modelling). All tools are tightly integrated and work incrementally, therefore allowing different forms of construction and modification processes and giving substantial support.     

The role of distances in requirements communication: a case study

Requirements communication plays a vital role in development projects in coordinating the customers, the business roles and the software engineers. Communication gaps represent a significant source of project failures and overruns. For example, misunderstood or uncommunicated requirements can lead to software that does not meet the customers’ requirements, and subsequent low number of sales or additional cost required to redo the implementation. We propose that requirements engineering (RE) distance measures are useful for locating gaps in requirements communication and for improving on development practice. In this paper, we present a case study of one software development project to evaluate this proposition. Thirteen RE distances were measured including geographical and cognitive distances between project members, and semantic distances between requirements and testing artefacts. The findings confirm that RE distances impact requirements communication and project coordination. Furthermore, the concept of distances was found to enable constructive group reflection on communication gaps and improvements to development practices. The insights reported in this paper can provide practitioners with an increased awareness of distances and their impact. Furthermore, the results provide a stepping stone for further research into RE distances and methods for improving on software development processes and practices.

     

需求工程在南京地铁企业信息化建设中的应用

高质量的需求规范是高质量软件制品的必要条件;对需求获取、需求规范的定义、需求验证和评审、需求信息的传递、需求的进化和演变等需求工程中基本活动进行了实践和总结。     

Software product line scoping and requirements engineering in a small and medium-sized enterprise: An industrial case study

Software product line (SPL) engineering has been applied in several domains, especially in large-scale software development. Given the benefits experienced and reported, SPL engineering has increasingly garnered interest from small to medium-sized companies. It is possible to find a wide range of studies reporting on the challenges of running a SPL project in large companies. However, very little reports exist that consider the situation for small to medium-sized enterprises and these studies try develop universal truths for SPL without lessons learned from empirical evidence need to be contextualized. This study is a step towards bridging this gap in contextual evidence by characterizing the weaknesses discovered in the scoping (SC) and requirements (RE) disciplines of SPL. Moreover, in this study we conducted a case study in a small to medium sized enterprises (SMEs) to justify the use of agile methods when introducing the SPL SC and RE disciplines through the characterization of their bottlenecks. The results of the characterization indicated that ineffective communication and collaboration, long iteration cycles, and the absence of adaptability and flexibility can increase the effort and reduce motivation during project development. These issues can be mitigated by agile methods.     

On the use of a formal requirements engineering language: The Generalized Railroad Crossing Problem

In this paper, we report on the use of theAlbert II requirements specification language through the handling of the Generalized Railroad Crossing case study. This formal language is based on an ontology of concepts used for capturing requirements inherent in real-time, distributed systems. Because of itsnaturalness, the language supports a direct mapping of customers’ informal needs onto formal statements, without having to introduce artificial elements. The language is founded on a formal framework (real-time temporal logic) which supports the reasoning process of the analyst during the elaboration of the specification. Such support for the reasoning is illustrated in the context of a goal-oriented approach adopted for the elaboration of the case study.     

Bayesian networks for enhancement of requirements engineering: a literature review

Requirements analysis is the software engineering stage that is closest to the users’ world. It also involves tasks that are knowledge intensive. Thus, the use of Bayesian networks (BNs) to model this knowledge would be a valuable aid. These probabilistic models could manage the imprecision and ambiguities usually present in requirements engineering (RE). In this work, we conduct a literature review focusing on where and how BNs are applied on subareas of RE in order to identify which gaps remain uncovered and which methods might engineers employ to incorporate this intelligent technique into their own requirements processes. The scarcity of identified studies (there are only 20) suggests that not all RE areas have been properly investigated in the literature. The evidence available for adopting BNs into RE is sufficiently mature yet the methods applied are not easily translatable to other topics. Nonetheless, there are enough studies supporting the applicability of synergistic cooperation between RE and BNs. This work provides a background for understanding the current state of research encompassing RE and BNs. Functional, non-functional and -ilities requirements artifacts are enhanced by the use of BNs. These models were obtained by interacting with experts or by learning from databases. The most common criticism from the point of view of BN experts is that the models lack validation, whereas requirements engineers point to the lack of a clear application method for BNs and the lack of tools for incorporating them as built-in help functions.     

How to integrate legal requirements into a requirements engineering methodology for the development of security and privacy patterns

Laws set requirements that force organizations to assess the security and privacy of their IT systems and impose them to implement minimal precautionary security measures. Several IT solutions (e.g., Privacy Enhancing Technologies, Access Control Infrastructure, etc.) have been proposed to address security and privacy issues. However, understanding why, and when such solutions have to be adopted is often unanswered because the answer comes only from a broader perspective, accounting for legal and organizational issues. Security engineers and legal experts should analyze the business goals of a company and its organizational structure and derive from there the points where security and privacy problems may arise and which solutions best fit such (legal) problems. The paper investigates the methodological support for capturing security and privacy requirements of a concrete health care provider.