To bridge a wide gap between the end users and the requirements engineers, we propose a business flow diagram for acquiring users' requirements of the object oriented software development in the business application domain. Each field of this diagram shows either a role or a responsibility of a particular person or an organization. This paper proposes a development method that the engineers acquire the requirements by using our diagrams. We have implemented a supporting tool based on this study for collaborating the requirements engineers with their users. At first, the end users of an information system to be developed draw diagrams representing the flows of information and physical objects in their work from their own points of view. Sometimes the engineers write them with the users. If all users submit their diagrams, then our tool collects them and constructs a total diagram. The requirements engineers analyze the total diagram for improving the business flow. After the engineers complete this diagram, our tool can automatically transform it into an initial version of the class diagram. We show the effectiveness of our approach with some experiments. Comparing the related works, we discuss some issues of the practical aspects of this proposal.
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.
Copy
Mikito KUROKI, Morio NAGATA, "A Business Flow Diagram for Acquiring Users' Requirements of Object Oriented Software" in IEICE TRANSACTIONS on Information,
vol. E83-D, no. 4, pp. 608-615, April 2000, doi: .
Abstract: To bridge a wide gap between the end users and the requirements engineers, we propose a business flow diagram for acquiring users' requirements of the object oriented software development in the business application domain. Each field of this diagram shows either a role or a responsibility of a particular person or an organization. This paper proposes a development method that the engineers acquire the requirements by using our diagrams. We have implemented a supporting tool based on this study for collaborating the requirements engineers with their users. At first, the end users of an information system to be developed draw diagrams representing the flows of information and physical objects in their work from their own points of view. Sometimes the engineers write them with the users. If all users submit their diagrams, then our tool collects them and constructs a total diagram. The requirements engineers analyze the total diagram for improving the business flow. After the engineers complete this diagram, our tool can automatically transform it into an initial version of the class diagram. We show the effectiveness of our approach with some experiments. Comparing the related works, we discuss some issues of the practical aspects of this proposal.
URL: https://global.ieice.org/en_transactions/information/10.1587/e83-d_4_608/_p
Copy
@ARTICLE{e83-d_4_608,
author={Mikito KUROKI, Morio NAGATA, },
journal={IEICE TRANSACTIONS on Information},
title={A Business Flow Diagram for Acquiring Users' Requirements of Object Oriented Software},
year={2000},
volume={E83-D},
number={4},
pages={608-615},
abstract={To bridge a wide gap between the end users and the requirements engineers, we propose a business flow diagram for acquiring users' requirements of the object oriented software development in the business application domain. Each field of this diagram shows either a role or a responsibility of a particular person or an organization. This paper proposes a development method that the engineers acquire the requirements by using our diagrams. We have implemented a supporting tool based on this study for collaborating the requirements engineers with their users. At first, the end users of an information system to be developed draw diagrams representing the flows of information and physical objects in their work from their own points of view. Sometimes the engineers write them with the users. If all users submit their diagrams, then our tool collects them and constructs a total diagram. The requirements engineers analyze the total diagram for improving the business flow. After the engineers complete this diagram, our tool can automatically transform it into an initial version of the class diagram. We show the effectiveness of our approach with some experiments. Comparing the related works, we discuss some issues of the practical aspects of this proposal.},
keywords={},
doi={},
ISSN={},
month={April},}
Copy
TY - JOUR
TI - A Business Flow Diagram for Acquiring Users' Requirements of Object Oriented Software
T2 - IEICE TRANSACTIONS on Information
SP - 608
EP - 615
AU - Mikito KUROKI
AU - Morio NAGATA
PY - 2000
DO -
JO - IEICE TRANSACTIONS on Information
SN -
VL - E83-D
IS - 4
JA - IEICE TRANSACTIONS on Information
Y1 - April 2000
AB - To bridge a wide gap between the end users and the requirements engineers, we propose a business flow diagram for acquiring users' requirements of the object oriented software development in the business application domain. Each field of this diagram shows either a role or a responsibility of a particular person or an organization. This paper proposes a development method that the engineers acquire the requirements by using our diagrams. We have implemented a supporting tool based on this study for collaborating the requirements engineers with their users. At first, the end users of an information system to be developed draw diagrams representing the flows of information and physical objects in their work from their own points of view. Sometimes the engineers write them with the users. If all users submit their diagrams, then our tool collects them and constructs a total diagram. The requirements engineers analyze the total diagram for improving the business flow. After the engineers complete this diagram, our tool can automatically transform it into an initial version of the class diagram. We show the effectiveness of our approach with some experiments. Comparing the related works, we discuss some issues of the practical aspects of this proposal.
ER -