Takako Nakatani

A requirements description metamodel for use cases

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 actors perspective.

A Model and Architecture of REBOK (Requirements Engineering Body of Knowledge) and Its Evaluation

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.

A Case Study: Requirements Elicitation Processes throughout a Project

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.

REBOK Manifest: Towards a Requirements Engineering Body of Knowledge

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

Requirements Maturation Analysis by Accessibility and Stability

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.

Preliminary Analysis for Risk Finding in Offshore Software Outsourcing from Vendor’s Viewpoint

It is meaningful to investigate the know-how of experienced project managers on the side of vendors about the risk in offshore software outsourcing. A survey is conducted to find out the main risk factors from the vendor’s viewpoint. The questions asked include background information of vendor and respondent, suggestions to the client, and evaluations on experienced offshore projects. In all, 131 respondents from 77 vendors evaluate 241 offshore software outsourcing projects upon 30 items. The background information about the respondents and the vendors is summarized first. The preliminary analysis on the characters and the achievements of experienced offshore projects is reported in this paper. Some conclusions are drawn at last.

Instructional Design of a Requirements Engineering Education Course for Professional Engineers

As offshore development has become common for software companies, those companies have started to concentrate their engineers’ effort upon the early development phase of software. Within this context, it is important to educate professional engineers to master all aspects of requirements engineering. It is not easy to master the various aspect all at once. However, we can expect professional engineers to study methods on their own if they believe that learning the methods is important for them or their projects. We have developed a two-and-a-half-day role-playing workshop for professional engineers that focuses on teaching the importance of requirements engineering, as well as the background, rationale, and purpose of the requirements to guarantee success in their projects. We start this paper with an overview of requirements engineering and its techniques, and then, introduce the instructional design of our course for professional engineers. We also present the results of an actual workshop, which showed engineers could earned clients’ mindsets and the importance of the rationale of requirements.

An analysis method with failure scenario matrix for specifying unexpected obstacles in embedded systems

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.

Enhancing the ESIM (Embedded Systems Improving Method) by Combining Information Flow Diagram with Analysis Matrix for Efficient Analysis of Unexpected Obstacles in Embedded Software

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 maturation analysis based on the distance between the source and developers

The success of a project is often affected by imperfect requirements. In order to cope with this risk, a requirements analyst needs to communicate with a client. However, communication between the requirements analyst and the client is not enough to prevent requirements imperfection, since requirements come from various sources, e.g. environment, laws, documents, actual usage, etc. The process of requirements elicitation is affected by the requirements stability, the ability of a requirements analyst, and accessibility of the source of requirements. This paper focuses on the distance between the source of requirements and a requirements analyst, and clarifies how the distance influences the requirements maturation. Requirements maturation represents the degree to which the requirements are elicited completely. We define a measure for observing requirements maturation and analyzing the accessibility of the source of the requirements. Then, we define a hypothesis. A case is analyzed in order to verify the hypothesis. As a result, there is a correlation between the requirements maturation efficiency and the accessibility of the source of the requirements.