Search

This paper reflects on a decade-long journey into the industrial practices developed for requirements inspection in the Japanese software industry; it proposes an ELFIEP (Evolutionary Lifecycle Framework for Industrial Engineering Practice). We published two papers in RE’13 and RE’14. The first paper introduced the industrial practice of SRS (Software Requirements Specifications) inspection system of a software company. The system is a set of inspection items: inspection processes, techniques, and supporting tools. In the second paper, to encourage wider industrial adoption of requirements inspection systems, we proposed a methodology for designing requirements inspection systems. Called RISDM (Requirements Inspection System Design Methodology), it has been recognized by professional communities in Japan. A number of software companies have adopted the methodology, and are now operating their individual inspection systems. This paper provides a retrospect of the journey to RISDM. Learning from the journey, we propose ELFIEP as a generic framework for the evolution of engineering practice, and discuss insights gained from the journey and the framework.

Software innerSourcing has been attracting attention over the past decade in terms of procuring human resources. It can make any employee become a member of all projects in the company by adopting an Open Source Software (OSS) development style. For encouraging healthy employee participation on software innerSourcing, it is important to understand what motivates them. This report creates a visual model using the iStar framework, a goal and actor-oriented modeling methodology, to develop an understanding of employee motivation for software innerSourcing. We interview six employees who participated in one web application development project via software innerSourcing. We then create iStar models based on the interview results. They can be used to explain what motivates employees to use their time for other projects in software innerSourcing.

A critical issue in software development projects in IT service companies is finding the right people at the right time. By enabling assignments of tasks to people to be more fluid, the use of crowdsourcing approaches within a company offers a potential solution to this challenge. Inside a company, as multiple system development projects are ongoing separately, developers with slack time on one project might use this time to contribute to other projects. In this paper, we report on a case study of the application of crowdsourcing within an industrial web application system development project in a large telecommunications company. Developers worked with system specifications which were organized into a set of microtasks, offering a set of short and self-contained descriptions. When crowd workers in other projects had slack time, they fetched and completed microtasks. Our results offer initial evidence for the potential value of microtask programming in increasing the fluidity of team assignments within a company. Crowd contributors to the project were able to onboard and contribute to a new project in less than 2 hours. After onboarding, the crowd workers were together able to successfully implement a small program which contained only a small number of defects. Interview and survey data gathered from project participants revealed that crowd workers reported that they perceived onboarding costs to be reduced and did not experience issues with the reduced face to face communication, but experienced challenges with motivation.

Agile practices are widely introduced to projects these days. However, merely using processes/tools in the practices does not necessarily result in “achieving agility”, especially for those who have been using a waterfall model. They tend to think that the waterfall model is the only way. This mindset is the main obstacle to make the introduction of agile practices successful. To derive a true value in using them, understanding the underlying mindset in the agile practices is essential. This report introduces a novel workshop-based learning course to understand the agile mindset. The course participants create pipe cleaner arts for experiencing pseudo software development in two different models: waterfall and agile. A questionnaire result from total 201 participants shows that they perceived a clear difference between the two models. About 87% of them answered that the experience is useful for their future development works.

Sourcing the right IT engineers is critical for project success. In recent years, two sourcing strategies have been grabbing attention: crowdsourcing and inner-sourcing. Each has their own good points and bad points. Crowdsourcing allows organizations to recruit IT engineers from outside on demand. However, organizations working on closed-source code with confidential information might be worried about security concerns (e.g., information leak). The other strategy, inner-sourcing, can make any IT engineer in an organization become a member of all projects by adopting open source software development practices. This improves the mobility of IT engineers between projects inside the organization. However, there is a limit to the types of IT engineers that one organization can have. In this report, we propose a hybrid sourcing approach. It integrates the two sourcing strategies to develop software - crowdsourcing and inner-sourcing. This approach distributes the development tasks to either software crowdsourcing or inner-sourcing according to task type. As a case study, we adopt hybrid sourcing approach for an industrial project. The project developed a web application system for a bus company. We evaluate the effectiveness and future issues of hybrid sourcing.

In agile software development projects, software engineers prioritize implementation over documentation. Is the cost of missing documentation greater than the cost of producing unnecessary or unused documentation? Agile software engineers must still maintain other software artifacts, such as tickets in an issue tracking system or source code committed to a version control system (VCS). Do these artifacts contain useful knowledge? In this paper, we examine undocumented knowledge in a multi-case exploratory case study of industrial agile software development projects. The first is an internal project with 159 source code commits and roughly 8000 lines of code. The second is an external project with 760 source code commits and roughly 50,000 lines of code. We introduce a ticket-commit network chart (TCC) that visually represents time-series commit activities along with filed issue tickets. We also implement a tool to generate the TCC using both commit log and ticket data. Our case study revealed that software engineers committed source code to the VCS without a corresponding issue ticket in a non-trivial minority of instances. If these commits were based on and linked to individual issue tickets, then these "unissued" tickets would have accounted for a non-trivial minority (5---21%) of the knowledge needed for future software modification and operations. End users and requirements engineers also evaluated the contents of these commits. They found that the omission of links to individual tickets had an important impact on future software modification or operation with between 22 and 49% of these instances resulting in undocumented knowledge.

Acquiring knowledge and context of the ongoing project is one of the most challenging issues for new project members. New project members need to comprehend the contents of features already implemented in software systems. However, most software documents (e.g., flow chart and data-model) were initially created and not updated. Herein we focus on tickets issued during the project period because they are created based on stakeholders' requirements as a project evolves. We propose a novel approach to categorize and visualize tickets to better understand the features implemented in the existing software systems. Specifically, tickets are grouped by a clustering method and the number of clusters (i.e., ticket categories) is automatically estimated. Then the ticket categories are visualized by (i) creating a heatmap of the tickets lifetimes, (ii) extracting keywords of the ticket categories, and (iii) analyzing the relationships between ticket categories. We applied our approach to an NTT software development project. Additionally, we interviewed the project members and external experts to evaluate the effectiveness of our approach. Our approach helps comprehend the features of the software system.

To successfully define a system and context boundary, requirements engineers must identify the stakeholders related to the system and understand them. Typically, to make an industrial system development project, it is necessary for requirement engineers to know which organizational entity in the industry, as a stakeholder, has an influence on the requirements of the system. Models of business processes that including swim lanes are very helpful for requirements engineers to identify the organizational entity executing the activities related to the system. However, such business processes are often undocumented, and discovering them is difficult and time-consuming. In this report, we introduce a novel approach for discovering business processes that involve swim lanes. Based on process mining technique, our approach generates the business process from an event log and user information extracted from an existing system.

Understanding appropriate requirements is a decisive factor to project success for the enterprise system development under the complicated and changeable environments. Nowadays, the enterprise systems are expected to solve a large variety of business problems from multiple stakeholders. Therefore, requirements analysts need to understand the complicated stakeholder’s business circumstances, define the issues necessary for the business purposes, and elicit requirements for the enterprise systems which could achieve the issues. In this paper, we propose a business modeling methodology which we call as MOYA that is abbreviation for “Model-Oriented methodology for Your Awareness”. MOYA supports requirements analysts to elicit and organize requirements from the stakeholders. The methodology also helps stakeholders to build consensus on their own requirements. This paper describes an approach, procedures, and deliverables of MOYA. After describing an industrial project as a practice of MOYA, we discuss effectiveness and limitations of MOYA.

In this paper, we propose a Requirements Engineering Ontology (REO). We reviewed three well-known Bodies of Knowledge (BoKs) on requirements engineering: BABOK, SWEBOK, and REBOK. Based on the review, we compiled the REO as an organized set of knowledge of the requirements engineering. With the REO, we propose "knowledge spectrum analysis", a technique to analyze and visualize the distribution of knowledge in technical documents. As a practical application of the REO, we conduct two case studies on the knowledge spectrum analysis. First, we evaluate three BoKs (i.e., BABOK, SWEBOK, and BABOK) using the REO. Second, we utilize the REO to survey a set of technical documents for corporate-wide methodology for business modeling at NTT DATA. Based on the results of the case studies, we demonstrate the effectiveness of the REO.

We introduce a whole view of current status of requirements engineering based on REBOK (Requirements Engineering Body Of Knowledge) and its practical use with case studies.

The aim of our research is to empirically analyze the impact of requirements trace ability quality to the productivity of the enterprise applications development. We analyze trace ability links of Requirements Specification Documents (RSDs) collected from the enterprise applications development. These RSDs are classified into two groups in terms of project performance. One group includes RSDs of significant cost overrun projects, another group includes RSDs of normal range cost projects. Our analysis revealed that high quality of trace ability in RSDs significantly reduces the cost overrun in the enterprise applications development.

Requirements engineering has been extensively developed as a discipline. Many statistics on the software development indicate requirements process is the most influential to both success and failure of software development. However, practitioners are still difficult to learn and apply requirements engineering. As a guideline for practitioners to learn and apply requirements engineering, we developed REBOK (Requirements Engineering Body Of Knowledge). In the development, we found there is no common model of BOKs in software engineering. This article proposes the model and architecture of the body of knowledge of REBOK and its proof of the concept.