This study presents an initial set of findings from an empirical study of social processes, technical system configurations, organizational contexts, and interrelationships that give rise to open software. The focus is directed at understanding the requirements for open software development efforts, and how the development of these requirements differs from those traditional to software engineering and requirements engineering. Four open software development communities are described, examined, and compared to help discover what these differences may be. Eight kinds of software informalisms are found to play a critical role in the elicitation, analysis, specification, validation, and management of requirements for developing open software systems. Subsequently, understanding the roles these software informalisms take in a new formulation of the requirements development process for open source software is the focus of this study. This focus enables considering a reformulation of the requirements engineering process and its associated artifacts or (in)formalisms to better account for the requirements for developing open source software systems.

Is there such a thing anymore as a software system that doesn't need to be secure? Almost every softwarecontrolled system faces threats from potential adversaries, from Internet-aware client applications running on PCs, to complex telecommunications and power systems accessible over the Internet, to commodity software with copy protection mechanisms. Software engineers must be cognizant of these threats and engineer systems with credible defenses, while still delivering value to customers. In this paper, we present our perspectives on the research issues that arise in the interactions between software engineering and security.

The process of engineering software-intensive systems that comply with their Certification and Accreditation (C&A) requirements involves many critical decision-making activities for the related stakeholders. Considering the exhaustive nature of C&A activities together with the complexity of software-intensive systems, effective decision making relies heavily on the ways to understand and structure the problem domain concepts concerning decision points for interpretation, applicability, scope, evaluation, and impact of the enforced C&A requirements. These decision points are further complicated by natural language specifications of inherently non-functional C&A requirements scattered across multiple regulatory documents with complex interdependencies at different levels of abstractions in the organizational hierarchy, which often result in subjective interpretations and non-standard implementations of the C&A process. To address these issues, we define a systematic methodology using novel techniques from software Requirements Engineering (RE) and knowledge engineering for understanding and structuring the problem domain concepts based on a uniform representation format that promotes common understanding among stakeholders. Specifically, we use advanced ontological

This dissertation is an investigation into how ambiguity should be classified for authors and readers of text, and how this process can be automated. Usually, authors and readers disambiguate ambiguity, either consciously or unconsciously. However, disambiguation is not always appropriate. For instance, a linguistic construction may be read differently by different people, with no consensus about which reading is the intended one. This is particularly dangerous if they do not realise that other readings are possible. Misunderstandings may then occur. This is particularly serious in the field of requirements engineering. If requirements are misunderstood, systems may be built incorrectly, and this can prove very costly. Our research uses natural language processing techniques to address ambiguity in requirements. We develop a model of ambiguity, and a method of applying it, which represent a novel approach to the problem described here. Our model is based on the notion that human perception is the only valid criterion for judging ambiguity. If people perceive very differently how an ambiguity should be read, it will cause misunderstandings. Assigning a preferred reading to it is therefore unwise. In

This paper proposes the Strategy-oriented Alignment in Requirements Engineering (SOARE) approach for e-business systems. The primary objective of the SOARE approach is to enable alignment between requirements for e-business systems and the business strategies they are intended to support. The SOARE approach incorporates means for analysing and decomposing business strategy, employing goal modelling both to represent business strategy in a requirements engineering context and to link high-level strategic objectives to low-level requirements through goal refinement. The SOARE approach further describes a basis for deriving and leveraging recurring requirements patterns. This paper proposes a high-level process for the SOARE approach, which is then illustrated via a proof-of-concept case study from the literature

Abstract. This paper is concerned with bridging the gap between requirements, provided as a set of scenarios, and conforming design models. The novel aspect of our approach is to exploit learning for the synthesis of design models. In particular, we present a procedure that infers a message-passing automaton (MPA) from a given set of positive and negative scenarios of the system’s behavior provided as message sequence charts (MSCs). The paper investigates which classes of regular MSC languages and corresponding MPA can (not) be learned, and presents a dedicated tool based on the learning library LearnLib that supports our approach. 1

Intelligent Agents, 1993.

Abstract. Information Systems (IS), particularly e-business systems, are required to be more secure in order to resist to the increasing number of attacks. Security is no longer just a desirable quality of IT systems, but is required for compliance to international regulations. The Requirements Engineering (RE) community has started to make successful contributions in the domain of security engineering. This concerns the integration of RE techniques at the early stages of security engineering, as well as the iterative management of security requirements, due to the intertwining between requirements and software architecture design. This paper proposes to complement these results by adapting and integrating another key activity of security, namely risk analysis. The aim of this paper is to show, that using and adapting an appropriate set of existing tools and techniques of risk analysis methods, improves the effectiveness of an iterative security engineering method starting at the earliest stage of IS development. 1

The elicitation or communication of user requirements comprises an early and critical but highly error-prone stage in system development. Socially-oriented methodologies provide more support for user involvement in design than the rigidity of more traditional methods, facilitating the degree of user-designer communication and the ‘capture ’ of requirements. A more emergent and collaborative view of requirements elicitation and communication is required to encompass the user, contextual and organisational factors. From this accompanying literature in communication issues in requirements elicitation, a four-dimensional framework is outlined and used to appraise comparatively four different methodologies seeking to promote a closer working relationship between users and designers. The facilitation of communication between users and designers is subject to discussion of the ways in which communicative activities can be ‘optimised ’ for successful requirements gathering, by making recommendations based on the four dimensions to provide fruitful considerations for system designers. 1.

Early Requirements Engineering is the phase of the software development process that is concerned with understanding the organizational context of a system, and the goals and social dependencies of its stakeholders. Formal Methods techniques have a great potential as a powerful means for specification, early debugging and certification of software. So far, however, their application to early requirements modeling and analysis has been limited by a mismatch between the concepts used for describing early requirements and the constructs offered by formal specification languages. This thesis