Personal recommendations in requirements engineering : the OpenReq approach

[Context & motivation] Requirements Engineering (RE) is considered as one of the most critical phases in software development but still many challenges remain open. [Problem] There is a growing trend of applying recommender systems to solve open RE challenges like requirements and stakeholder discovery; however, the existent proposals focus on specific RE tasks and do not give a general coverage for the RE process. [Principal ideas/results] In this research preview, we present the OpenReq approach to the development of intelligent recommendation and decision technologies that support different phases of RE in software projects. Specifically, we present the OpenReq part for personal recommendations for stakeholders. [Contribution] OpenReq aim is to improve and speed up RE processes, especially in large and distributed systemsPeer ReviewedPostprint (author's final draft

Towards a scope management of non-functional requirements in requirements engineering

Getting business stakeholders’ goals formulated clearly and project scope defined realistically increases the chance of success for any application development process. As a consequence, stakeholders at early project stages acquire as much as possible knowledge about the requirements, their risk estimates and their prioritization. Current industrial practice suggests that in most software projects this scope assessment is performed on the user’s functional requirements (FRs), while the non-functional requirements (NFRs) remain, by and large, ignored. However, the increasing software complexity and competition in the software industry has highlighted the need to consider NFRs as an integral part of software modeling and development. This paper contributes towards harmonizing the need to build the functional behavior of a system with the need to model the associated NFRs while maintaining a scope management for NFRs. The paper presents a systematic and precisely defined model towards an early integration of NFRs within the requirements engineering (RE). Early experiences with the model indicate its ability to facilitate the process of acquiring the knowledge on the priority and risk of NFRs

A Specification for Designing Requirement Prioritization Artifacts

The importance of prioritizing requirements stems from the fact that not all requirements can usually be met with available time and resource constraints. Although several papers have been published in this domain, they mainly focus on descriptive research endeavors to suggest different requirement prioritization approaches. Prescriptive research dealing with design science for a systematic and holistic understanding of the prioritization process is still scarce. The gap motivates our research, which aims at arriving at a set of design principles that explains the form and function of software requirement prioritization artifacts. We resort to a non-experimental approach using content analysis to identify and analyze articles on requirement prioritization published up to 2009 in order to arrive at the set of initial design principles. This subsequently is evaluated based on expert feedbacks. We close the paper by indicating our research continuation plans, and highlighting issues for future considerations

Scope Management of Non-Functional Requirements

In order to meet commitments in software projects, a realistic assessment must be made of project scope. Such an assessment relies on the availability of knowledge on the user-defined project requirements and their effort estimates and priorities, as well as their risk. This knowledge enables analysts, managers and software engineers to identify the most significant requirements from the list of requirements initially defined by the user. In practice, this scope assessment is applied to the Functional Requirements (FRs) provided by users who are unaware of, or ignore, the Non-Functional Requirements (NFRs). This paper presents ongoing research which aims at managing NFRs during the software development process. Establishing the relative priority of each NFR, and obtaining a rough estimate of the effort and risk associated with it, is integral to the software development process and to resource management. Our work extends the taxonomy of the NFR framework by integrating the concept of the "hardgoal". A functional size measure of NFRs is applied to facilitate the effort estimation process. The functional size measurement method we have chosen is COSMICFFP, which is theoretically sound and the de facto standard in the software industry

Requirements degradation for the creation of a first prototype

The requirements engineering process is typically executed, irrespective of the process model chosen, for the final commercially viable system. The system requirements generated are for a system deployed and used in its final form and function. However, the first prototype that is generated is typically representative of a minimum viable technology, and represents a degraded set of the initial system requirements specification. Typically, a first prototype is used as a technology demonstrator, and its failure or success will determine the continuation of the project, with success triggering the allocation of additional financial and personal resources. This paper explores techniques for requirements degradation that can be used to form the system requirements specification for the first prototype. A requirements Engineering methodology is proposed based upon a survey of literature. It takes into consideration the characteristics of the project, i.e. a market driven, technology implementation research project with limited budget and a flexible timeline executed in an academic environment. The techniques must take into cognizance the main risk items, and core requirements, that need to be demonstrated in the minimum viable technology to secure the future of the project. The degradation cannot undermine or jeopardize the future success of the commercially viable system in determining the subset of requirements for the minimum viable technology

Collaborative Requirements Engineering Notation for Planning Globally Distributed Projects

Requirements engineering represents a critical phase of the software development lifecycle in which requirements describing the functional and non-functional behaviors of a system are elicited, modeled, analyzed, negotiated, agreed, and specified. In traditional software systems these tasks are typically performed in face-to-face meetings between requirements engineers and the project level stakeholders. However, in today’s global software development environment, it is becoming increasingly commonplace for stakeholders to be dispersed across multiple geographical locations and time zones. Under these circumstances, face-to-face meetings become expensive, and often impossible to facilitate, and as a result the success of the requirements process relies, at least partially, on tools and processes that support distributed communication and collaboration. To investigate the challenges and effective practices for performing requirements activities in distributed environments, we conducted a series of in-depth interviews with project managers and business analysts who have worked with non-co-located stakeholders. Since many project managers fail to plan and deploy the necessary infrastructures to support quality communication, and in practice requirements are often elicited and managed via email exchanges; we introduced a visual modeling notation to help project managers proactively plan the collaboration infrastructures needed to support requirements-related activities in globally distributed projects. An underlying meta-model defines the elements of the modeling language, including locations, stakeholder roles, communication flows, critical documents, and supporting tools and repositories. The interview findings were further analyzed to identify practices that led to success or created significant challenges for the projects; resulting in a set of patterns for globally distributed requirements engineering

Impact estimation: IT priority decisions

Given resource constraints, prioritization is a fundamental process within systems engineering to decide what to implement. However, there is little guidance about this process and existing IT prioritization methods have several problems, including failing to adequately cater for stakeholder value. In response to these issues, this research proposes an extension to an existing prioritization method, Impact Estimation (IE) to create Value Impact Estimation (VIE). VIE extends IE to cater for multiple stakeholder viewpoints and to move towards better capture of explicit stakeholder value. The use of metrics offers VIE the means of expressing stakeholder value that relates directly to real world data and so is informative to stakeholders and decision makers. Having been derived from prioritization factors found in the literature, stakeholder value has been developed into a multi-dimensional, composite concept, associated with other fundamental system concepts: objectives, requirements, designs, increment plans, increment deliverables and system contexts. VIE supports the prioritization process by showing where the stakeholder value resides for the proposed system changes. The prioritization method was proven to work by exposing it to three live projects, which served as case studies to this research. The use of the extended prioritization method was seen as very beneficial. Based on the three case studies, it is possible to say that the method produces two major benefits: the calculation of the stakeholder value to cost ratios (a form of ROI) and the system understanding gained through creating the VIE table