In the requirements definition phase, conceptual models are used to understand the developing software. Although scenarios are often described on the basis of conceptual models, there are cases that necessary requirements are omitted in the scenarios when the scenarios are created manually. Herein we propose an approach to support scenario creation from conceptual models where event lists of scenarios, which include checkpoints to define requirements, are generated from conceptual models automatically. The conceptual models represent the core resources of the software, the owner of the core resources, and use cases as class diagrams. Then software engineers and their clients arrange the event lists and define requirements as scenarios on the basis of the checkpoints. Our approach can support describing scenarios with all the necessary requirements from conceptual models. To confirm the effectiveness of our approach, we compared our approach to the all-manual approach.

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 success of any projects can be affected by requirements changes. We define requirements elicitation as the activity of adding, deleting, and modifying requirements. We here refer to the completion of requirements elicitation of a software component as requirements maturation. The requirements of the component will never be changed after 100% maturation. We introduce the requirements maturation efficiency (RME) in order to estimate the requirements maturation period for the component. The RME of the requirements represents how quickly the requirements of a component reach 100% maturation. The goal of this paper is to define a method of estimating the RME of each component. Since requirements analysts (RAs) elicit requirements by accessing requirement sources and stability is one of the characteristics of requirements, we can assume that the RME of a component must be derived from the accessibility of the requirements source and the stability of the requirements. We model accessibility as the number of information flows from the source of the requirements to the RA and model stability with the requirements maturation index (RMI). The results from multiple regression analysis for two cases indicate that RME can be derived by these two factors with a significant level of 5%. We also discuss a method by which to estimate the period for requirements maturation.

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.

We initiate the discussions on the REBOK (Requirements Engineering Body of Knowledge) in requirements engineering community.

Requirements changes sometimes cause a project to fail. A lot of projects now follow incremental development processes so that new requirements and requirements changes can be incorporated as soon as possible.These processes are called integrated requirements processes which integrate requirements processes with other development processes. We have investigated the requirements processes of a project from beginning to end, both quantitatively and qualitatively. Our focus is to clarify the types of requirements based on the components contained within a certain portion of the software architecture. Each type reveals its typical requirements processes through its rationale. The case studied is a system to manage the orders and services of a restaurant. In this paper, we introduce the case and describe the types of requirements processes. Then we discuss the reasons why we could not elicit all the requirements in the early development processes.

In order to improve the quality of embedded software, this paper proposes an enhancement to the ESIM (embedded systems improving method) by combining an IFD (information flow diagram) with an Analysis Matrix to analyze unexpected obstacles in the software. These obstacles are difficult to predict in the software specification. Recently, embedded systems have become larger and more complicated. Theoretically therefore, the development cycle of these systems should be longer. On the contrary, in practice the cycle has been shortened. This trend in industry has resulted in the oversight of unexpected obstacles, and consequently affected the quality of embedded software. In order to prevent the oversight of unexpected obstacles, we have already proposed two methods for requirements analysis: the ESIM using an Analysis Matrix and a method that uses an IFD. In order to improve the efficiency of unexpected obstacle analysis at reasonable cost, we now enhance the ESIM by combining an IFD with an Analysis Matrix. The enhancement is studied from the following three viewpoints. First, a conceptual model comprising both the Analysis Matrix and IFD is defined. Then, a requirements analysis procedure is proposed, that uses both the Analysis Matrix and IFD, and assigns each specific role to either an expert or non-expert engineer. Finally, to confirm the effectiveness of this enhancement, we carry out a description experiment using an IFD.

Requirements Engineering begins to attract attention as a trump letting a project succeed and software improve its reliability. There already exist a lot of research results in requirements engineering area, and they seem to be helpful for practitioners. However, it is not so easy to use such research results because most of them do not provide stable and scalable tool support. One of the reasons is that tasks in requirements engineering highly depend on human decisions and/or insights and it seems to be hard to achieve such tasks systematically and automatically. Of course, we can find several tools to support requirements engineering process. For example, there is a survey of requirements management tools in INCOSE site [1]. Tools for goal oriented requirements analysis can be found in [2] and [3]. One of the common points of such tools is they are really helpful to achieve human-centric tasks in requirements engineering. Therefore, we have to explore what kinds of systematic or automatic support could be provided to improve humancentric tasks in requirements engineering. That is the reason why we plan this workshop. In this workshop, participants will explore tools to support requirements processes: e.g. requirements elicitation, requirement specification, requirements validation, or requirements management.

This paper describes an analysis method with failure scenario matrix for specifying unexpected obstacles in order to improve the quality of embedded systems. Although embedded software has become increasingly large in scale and complexity, companies are requiring the software to be developed within shorter periods of time. Therefore, the quality of the software is bound to suffer. This problem is one of the most serious concerns in a coming age of ubiquitous embedded systems. In order to improve the quality, it is very important to specify the forbidden behavior of embedded systems. The forbidden behavior of unexpected obstacles is analyzed by using a matrix and scenarios. This paper provides a detailed description of the analysis method used, in particular the cause, phenomenon, and goal in the scenario, relating them to each other by using a matrix.

One of the purposes of analyzing the business domain is to reveal the background of customer requirements. The resulting artifact provides us the reason why the requirements arise and possibilities of other useful solutions to solve the customers' problems. We have developed RODAN as a business domain analysis method. RODAN improves the understandability of the background of the requirements by focusing on roles in the business domain and owners of the business goals. This paper is an attempt towards clarifying the notion of understanding the business domain and evaluating the method effectiveness of extracting undefined requirements and rationales of defined requirements.

Engineers have little time for requirements elicitation and their validation, because they still have to make a great effort to write down concrete use cases. Although concrete use cases are important for deriving test cases, it is possible to free engineers from the routine work of defining similar use cases repeatedly and at the same time keeping consistency in requirements elicitation. We propose one solution concerning these difficulties. The requirements description metamodel called RD-metamodel integrates the activity graph metamodel and use case metamodel. It supplies a mechanism of use case writing with multiple perspectives: resource-reference, resource-structure, activity-sequence, process, and the actor's perspective.

A class evolves to address new user requirements and enhance reusability. The evolution processes can be analyzed statistically by tracing quantitative characteristics of object-oriented software development cases. In our case studies, increasing phenomena have been observed by four layers: a system layer, a class tree layer, a class layer and a method layer. Quantitative data, the value of mean lines of code per method over classes belonging to the same inheritance tree, can be considered to represent a characteristic of the inheritance tree over evolution and to affect class evolution as a constraint. Another type of data, the distribution pattern of size data at the system layer, is fitted to the negative binomial distribution model, and the parameters of the model can be interpreted to disclose some development intentions. This paper reports the results of empirical case studies and discusses evolution patterns and laws of objects.

Software tends to change itself according to user requirements changes. In the object-oriented technology, it is important to find a way how classes evolve to cope with new user requirements or to obtain reusability. The authors propose that developers need to know the class evolution processes and to forecast their future evolution according to the system, growth. Class specifications and class structures change inevitably, and classes may also be replaced during the class evolution processes. They classify classes into three categories the boundary species, the domain species and the common species, and discuss their evolution processes.