The original paper is in English. Non-English content has been machine-translated and may contain typographical errors or mistranslations. ex. Some numerals are expressed as "XNUMX".
Copyrights notice
The original paper is in English. Non-English content has been machine-translated and may contain typographical errors or mistranslations. Copyrights notice
Perubahan keperluan kadangkala menyebabkan projek gagal. Banyak projek kini mengikuti proses pembangunan tambahan supaya keperluan dan perubahan keperluan baharu boleh dimasukkan secepat mungkin. Proses ini dipanggil proses keperluan bersepadu, yang berfungsi untuk mengintegrasikan proses keperluan dengan proses pembangunan lain. Kami telah menyiasat secara kuantitatif dan kualitatif proses keperluan projek tertentu dari awal hingga akhir. Fokus kami adalah untuk menjelaskan jenis keperluan yang diperlukan berdasarkan komponen yang terkandung dalam bahagian tertentu seni bina perisian. Selanjutnya, setiap jenis mendedahkan proses keperluan tipikalnya melalui rasionalnya sendiri. Kajian kes ini merupakan satu sistem untuk menguruskan tempahan dan perkhidmatan sesebuah restoran. Dalam kertas ini, kami memperkenalkan kes dan mengkategorikan proses keperluannya berdasarkan komponen sistem dan ciri kualitatif ISO-9126. Kami boleh mengenal pasti tujuh kategori proses keperluan biasa untuk diurus dan/atau dikawal. Setiap kategori mendedahkan proses keperluan biasa dan ciri-cirinya. Kajian kes ialah langkah pertama kami dalam kejuruteraan keperluan bersepadu praktikal.
The copyright of the original papers published on this site belongs to IEICE. Unauthorized use of the original or translated papers is prohibited. See IEICE Provisions on Copyright for details.
Salinan
Takako NAKATANI, Shouzo HORI, Naoyasu UBAYASHI, Keiichi KATAMINE, Masaaki HASHIMOTO, "A Case Study of Requirements Elicitation Process with Changes" in IEICE TRANSACTIONS on Information,
vol. E93-D, no. 8, pp. 2182-2189, August 2010, doi: 10.1587/transinf.E93.D.2182.
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.
URL: https://global.ieice.org/en_transactions/information/10.1587/transinf.E93.D.2182/_p
Salinan
@ARTICLE{e93-d_8_2182,
author={Takako NAKATANI, Shouzo HORI, Naoyasu UBAYASHI, Keiichi KATAMINE, Masaaki HASHIMOTO, },
journal={IEICE TRANSACTIONS on Information},
title={A Case Study of Requirements Elicitation Process with Changes},
year={2010},
volume={E93-D},
number={8},
pages={2182-2189},
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.},
keywords={},
doi={10.1587/transinf.E93.D.2182},
ISSN={1745-1361},
month={August},}
Salinan
TY - JOUR
TI - A Case Study of Requirements Elicitation Process with Changes
T2 - IEICE TRANSACTIONS on Information
SP - 2182
EP - 2189
AU - Takako NAKATANI
AU - Shouzo HORI
AU - Naoyasu UBAYASHI
AU - Keiichi KATAMINE
AU - Masaaki HASHIMOTO
PY - 2010
DO - 10.1587/transinf.E93.D.2182
JO - IEICE TRANSACTIONS on Information
SN - 1745-1361
VL - E93-D
IS - 8
JA - IEICE TRANSACTIONS on Information
Y1 - August 2010
AB - 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.
ER -