Powered by
Conference Publishing Consulting

2014 IEEE 5th International Workshop on Requirements Prioritization and Communication (RePriCo), August 26, 2014, Karlskrona, Sweden

RePriCo 2014 – Proceedings

Contents - Abstracts - Authors

2014 IEEE 5th International Workshop on Requirements Prioritization and Communication (RePriCo)

Title Page


Preface
Welcome to the 5th International Workshop on Requirements Prioritization and Communication (RePriCo’14). The workshop serves as a platform for the presentation and discussion of new and innovative approaches to prioritization and communication issues in requirements engineering. RePriCo’14 takes place on August 26, 2014, in Karlskrona, Sweden, co-located with the 22nd IEEE International Requirements Engineering Conference: Innovation in and through Requirements Engineering (RE'14).

Application of Requirements Prioritization Decision Rules in Software Product Line Evolution
Mari Inoki, Takayuki Kitagawa, and Shinichi Honiden
(Kogakuin University, Japan; Toshiba Solutions, Japan; National Institute of Informatics, Japan)
An application of a method for prioritizing requirements to an actual project is reported. The project where one of the authors participated as a project member developed in-house software development support tools based on a software product line. In the development of a software product line, a project needs to evolve core assets in accordance with changes to the environment, the market, and technology. The concerns of stakeholders may also change the process of evolving core assets over the years, and even if stakeholders change, the concept of the target product line should be maintained. In order to effectively evolve core assets, it is important for the project to prepare and utilize a standardized method for prioritizing requirements. In this paper, we analyzed the evolution of core assets in relation to an actual project. Tacit knowledge for prioritizing requirements was extracted. Such knowledge was made explicit and defined to develop a method for prioritizing requirements. The method consists of the rules and processes for applying the rules. We also defined a meta-model for prioritizing requirements and incorporated the concept of the improvement of rules into the meta-model. According to the evaluation of the method, the following issues were clarified: (a) different stakeholders smoothly and efficiently reached agreement using the method, and (b) the method is effective for reducing lead time and costs for defining requirements.

Extended Support for Visualizing Requirements: Filtering and Tracing Requirements in ReBlock
Deepti Savio and Ashok Pancily Poothiyot
(Siemens, India; IIT Indore, India)
The visualization of system requirements in a domain-independent, transparent and flexible manner with respect to the progress of the project for all project stakeholders is an area that still needs attention. There are several means to visualize requirements stored in a database, but few ways in which the status of a requirement – such as at what stage of realization it is at a given point in time, its associated dependencies with other requirements, multi-directional traces, and so on – can be discerned at a glance, while simultaneously keeping the overall big picture in view. The ReBlock plug-in was conceptualized and prototyped in order to address these limitations. Here, we discuss the implementation of several extensions to the initial prototype of the plug-in that make it more adaptable for visualizing a larger number of requirements.

Modeling Requirements: The Customer Communication
Dan Matheson
(Colorado State University, USA)
This paper describes the results of six years of experience in eighteen real-world projects in two companies of using models, primarily Unified Modeling Language-based models, to gather, review, record and communicate product definition solution requirements for customers in the medical device industry. The motivation for this approach was a response to ineffective projects that documented requirements in the traditional text format of “The system shall…”. In an attempt to both increase the quality of communication and fit with the rapid cycles of an agile-based project structure, a primarily graphical-based technique was used. The use of multiple models for the business requirements versus a single text document made communication across many business groups easier and decreased review time dramatically. The ISO RM-ODP standard was used to keep the focus of the business requirements models at the Enterprise, Information and Computation viewpoints. The use of multiple graphical models emulates the techniques of architects as they extract, document and present a building’s requirements. The graphical modeling-based formats and agile-based project techniques of this approach produced successful in-production solutions, which have been validated to FDA compliance standards.

Stakeholder Identification Method in Goal Oriented Requirements Elicitation Process
Mohd Sadiq and S. K. Jain
(NIT Kurukshetra, India)
In any software project, different stakeholders participate in requirements elicitation process to identify the requirements of software. Stakeholder Identification (SI) is an important part of requirements elicitation process. Despite its importance, SI methods have received less attention by goal oriented requirements engineering (GORE) community. Goals are high level objective of an organization; and are the basis of GORE. In literature, we identify that goal oriented requirements elicitation process (GOREP) like knowledge acquisition for automated specification (KAOS), attributed goal oriented requirements analysis (AGORA), and goal oriented idea generation (GOIG) etc. do not support SI methods. Therefore, to address this issue, we present a method for SI in GOREP which includes the following steps: specify stakeholder types, specify stakeholder roles, selecting and classifying stakeholders using fuzzy based approach, and stakeholder’s analysis. Finally, the utilization of the proposed method is demonstrated with the help of an example.

proc time: 0.61