A Case Study of Requirements Elicitation Process with Changes

Abstract

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.

Investigating the relationship between project constraints and appropriate iteration length in agile development through simulations

“…For simplicity, we suppose that uncertainty results in both types of changes. The former is incorporated using the model discussed in (Nakatani, 2010); the latter is added in by considering the elapsed time from the beginning of the project.…”

“…In the latter case, the new requirements have higher importance on average than the initial requirements because the customer should be getting familiar with the project. Meanwhile, the number of added requirements is limited by the initial number of requirements and project uncertainty, based on a requirements elicitation model described in a previous study (Nakatani, 2010).…”

Toward the Decision Tree for Inferring Requirements Maturation Types

“…It means that small OTs tend to receive a small number of requirements. According to our previous study [32], the RA needs to collect a certain amount of requirements. "A certain amount" means that if the number of requirements in an OT is one or two, RAs cannot evaluate the maturation period of the OT adequately.…”