No abstract

Abstract-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 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 function to integrate requirements processes with other developmental processes. We have quantitatively and qualitatively investigated the requirements processes of a specific project from beginning to end. Our focus is to clarify the types of necessary requirements based on the components contained within a certain portion of the software architecture. Further, each type reveals its typical requirements processes through its own rationale. This case study is a system to manage the orders and services of a restaurant. In this paper, we introduce the case and categorize its requirements processes based on the components of the system and the qualitative characteristics of ISO-9126. We could identify seven categories of the typical requirements process to be managed and/or controlled. Each category reveals its typical requirements processes and their characteristics. The case study is our first step of practical integrated requirements engineering.

SUMMARYWe propose PM (Project Management) patterns to prevent schedule delays caused by changes in requirements on empirical studies. Changes or late elicitation of requirements during the design, coding and test processes are one of the most serious risks, which may delay project schedules. However, changes and late elicitation of requirements are usually accepted during development processes. Therefore, the PM methods for preventing schedule delays caused by changes and late elicitation of requirements during development processes are an important area of study. In this study, we examined the actual conditions of various projects which succeeded in preventing schedule delays resulting from changes and late elicitation of requirements during development processes. We were able to extract various typical PM techniques for preventing these schedule delays. The techniques, known as "PM patterns", were also applied to other projects. The patterns were arranged on a two-dimensional framework. We discuss a framework of PM patterns aimed at solving the problems caused by changes in requirements. key words: project management pattern, requirement elicitation, project management knowledge, project management process, framework

No abstract