臺灣博碩士論文加值系統

對於應用資訊系統開發者而言，開發合乎使用者需求的軟體始終是一大重要課題。在軟體開發生命周期中，定義出新系統的需求是較為重要的一部分，然而大多數的需求文件仍是以自然語言的文字格式撰寫而成，如此一來易造成充滿模稜兩可(Ambiguity)、不一致(Inconsistency)、不精確(Imprecision)、與不完整(Incompleteness)的情況。除此之外，若將這種需求文件轉換成軟體開發中的物件導向分析以及物件導向設計階段所需的文件時，將會投入更多的轉換成本。
為解決這個問題，本論文提出以模型為基礎之物件導向需求工程。由於物件的繼承特性，可以帶來許多設計上的優勢，物件導向設計方法已儼然成為系統設計的新潮流。我們將需求定義為物件，並將其分類，以預先定義的方式管理需求物件與其屬性。本論文所提出之方法可幫助系統開發者有系統地擷取需求，並且可以讓接下來的分析階段、設計階段使用，而不會有不一致的情況產生。以模型為基礎之物件導向需求編輯器不但可以增加需求階段的效率，也可以幫助簡化軟體開發流程裡的需求階段轉換到分析、設計階段，進而解決不一致的情況產生，降低開發成本。

It is an important subject for information system developer to come up the application software that meets user’s requirements. And one of the key tasks in software development cycle is to correctly define the new system requirement. Unfortunately most of the user requirements are written in natural language format. It can easily lead to a situation which is full of ambiguity, inconsistency, imprecision and incompleteness. At the same time, it will incur a lot of conversion cost and time when trying to convert such written requirements into object oriented analysis and design documents.
To resolve such problem, this paper proposes an object oriented structure that can be used to specify, analyze and manage the software requirements. An object has its natural characteristic of inheritance. This characteristic brings certain design advantages. So object oriented design methodology has become a new development trend. We can define the user requirement as an object and classify it. We can then easily manage the requirement object and its characteristic with some predefined methods. The proposed structure will also help system developer to access to the requirement systematically. It can be used furthermore in the analysis and design development cycle without creating any inconsistency. Based on modeling, object oriented requirement engineering can enhance the efficiency during the requirement cycle. It can also simplify the process in software development such as the stage conversion from requirement into analysis and design. It will further resolve the inconsistency issue. It can help to reduce the development cost as well.

摘要　I
Abstract　II
目 錄　III
圖目錄　VI
表目錄　VIII
第一章 導論　1
　1.1　前言　1
　1.2　研究動機與目的　3
　1.3　研究方法與步驟　5
　1.4　章節導讀　6
第二章 背景知識與相關研究 7
　2.1　軟體工程　7
　　2.1.1　軟體工程簡介　7
　　2.1.2　軟體工程的定義　8
　　2.1.3　軟體工程的核心知識　10
　2.2　軟體需求與需求分析　12
　　2.2.1　軟體需求介紹　12
　　2.2.2　需求分析方法研究　13
　　2.2.3　需求分析的幾個重要階段　15
　2.3　物件導向與物件導向需求工程　16
　　2.3.1　物件導向　16
　　2.3.2　物件導向需求工程　18
　2.4　需求管理工具　21
第三章　物件導向需求模型　24
　3.1　軟體需求擷取流程　25
　3.2　需求問題樣板　26
　3.3　需求情境樣板　30
　3.4　需求物件化定義　33
　3.5　需求關聯性　38
第四章　系統展示　39
　4.1　開發環境　39
　4.2　系統登入與新增專案　40
　4.3　系統主畫面圖　42
　4.4　建立系統目標與相關活動者　43
　4.5　使用需求樣板新增需求　45
　4.6　新增需求情境　47
　4.7　建立物件化需求　48
　4.8　匯出與匯入需求物件　51
　4.9　搜尋需求物件　54
　4.10　關連性分析　54
　4.11　編輯使用案例圖　55
　4.12　版本紀錄器　56
　4.13　匯出XML檔案　57
第五章　結論與未來展望　58
參考文獻　59

1 Bauer F.L., NATO Software Engineering Conference, 1968.
2 Coad P., and Yourdon E., OOA – Object-Oriented Analysis 2nd Edition, Prentice Hall, 1990.
3 Carson R.S., “Keeping the Focus During Requirements Analysis,” Proceedings of the 11th International Symposium of the International Council on Systems Engineering (INCOSE), Melbourne, Australia, 2001.
4 Clarke S., Murphy J., and Roantree M., “Composition of UML Design Models: A Tool to Support the Resolution of Conflicts,” Proceedings of the 5th International Conference on Object-Oriented Information Systems, 1998, pp.464-479.
5 Dai L., Cooper K., “Modeling and Analysis of Non-functional Requirements as Aspects in a UML Based Architecture Design,” Proceedings of the Sixth International Conference on Software Engineering, May 2005, pp.178-183.
6 Finkelstein A., Gabbay D., Hunter A., and Nuseibeh B., “Inconsistency Handling in Multi-Perspective Specifications,” IEEE Transactions on Software Engineering, Vol. 20, No.8, 1994, pp. 569-578.
7 Ghezzi C., Jazayeri M., and Mandrioli D., Fundamentals of Software Engineering, 2nd ed., Prentice Hall, 2002.
8 Grosz G., “Building Information System Requirements Using Generic Structure”, IEEE 16th Annual International Computer Software and Applications Conference, 1992, pp.200-205.
9 Heitmeyer C., Jeffords R., and Kiskis D., “Automated Consistency Checking Requirements Specifications,” ACM Transactions on Software Engineering and Methodology, vol. 5, no. 3, pp. 231-261, 1996.
10 Hooks I., “Writing Good Requirements,” the Proceedings of the 3rd NCOSE International Symposium, 2003.
11 Hooper J.W., and Hsia P., “Scenario-based for Requirements Identification”, ACM Sigsoft Software Engineering, Vol.7, No. 5, 1982, pp.88-93.
12 Ian Sommerville, Software Engineering Sixth Edition, Addison-Wesley, 2001.
13 IEEE, IEEE Standard Glossary of Software Engineering Terminology. IEEE Std 610.12, 1990.
14 Kaindl H., “A practical approach to combining requirements definition and object-oriented analysis,” Annals of Software Engineering, Vol. 3, 1997, pp. 319-343.
15 Kaindl H., “Difficulties in the transition from OO analysis to design,” IEEE Software, Vol. 16, No.5, 1999, pp.94-102.
16 Kasser J.E., “Towards improving the recognition and correction of poor requirements,” the Proceedings of SETE 2005, ICE Australia, 2005, pp.1-13.
17 Kasser J.E. and Williams V. R., “What Do You Mean You Can't Tell Me If My Project Is in Trouble?,” Proceeding of Software Metrics (FESMA 98), Antwerp, Belgium, 1998.
18 Kotonya, G. and Sommerville I., “Requirements Engineering with Viewpoints,” BCS/IEE Journal of Software Engineering, Vol. 11, No. 1, 1996, pp. 5–18.
19 Lamsweerde V., Darimont R., and Letier E., “Managing Conflict in Goal-Driven Requirements Engineering,” IEEE Transactions on Software Engineering, Vol. 24, No. 11, 1998, pp. 908-926.
20 Lee J., and Xue, N.L. “FOOM: a fuzzy object-oriented modeling for imprecise requirements,” the Proceeding of Fuzzy Information, 1998, pp.345-349.
21 Lee J. and Kuo J.Y., “A new approach to requirements trade-off analysis for complex systems,” IEEE Transactions on Knowledge and Data Engineering, Vol. 10, No.4, 1998, pp.551-562.
22 Leffingwell, D. and Widring D., Managing Software Requirements, Addison-Wesley, 2000.
23 Lubars, M., Potts C., and Richter C., “Developing Initial OOA Models,” In Proceedings of the Fifteenth International Conference on Software Engineering (ICSE-15), IEEE Computer Society Press, Los Alamitos, CA, 1993, pp. 255–264.
24 Maiden N., Robertsoon S., “Developing Use Cases and Scenarios in the Requirements Process,” Proceedings of 27th International Conference on ICSE’05, May 2005, pp.15-21.
25 Penna G.D., Intrigila B., Larurenzi A.R., Orefice S., “An XML Definition Language to Support Scenario-Based Requirements Engineering,” International Journal of Software Engineering and Knowledge Engineering, Vol. 13, No. 3, Apr. 2003, pp.237-256.
26 Salem A.M., Darter M.O., and Ramanujam B., “A Practical Method for Performing Object Oriented Requirement Analysis,” the Proceedings of International Conference on Computer Science, 2005.
27 Schach S. R., Software Engineering, Aksen Associates Pacific Palisades, CA, USA, 1990.
28 Seybold C., Meier S., “Evolution of Requirements Models by Simulation,” Proceedings of the 7th International Workshop on Principles of Software Evolution, 2004, pp.43-48.
29 Standish, “The Chaos Report," http://www.standishgroup.com/chaos.html, March 19, 1998.
30 Stephane S. Some, “Supporting use case based requirements engineering,” Information and Software Technology, Vol. 48, No. 1, Jan. 2006, pp. 43-58.
31 SWEBOK, http://www.swebok.org, 2007.
32 The Standish Group, Chaos Report, http://www.standishgroup.com/, 2007.
33 Tran X.L, and Kasser J., “'Towards improving the recognition and correction of poor requirements,” Proceeding of Systems Engineering/Test and Evaluation, pp.1-13, 2005
34 Whittle, J., Araujo J., “Scenario Modeling with Aspects,” Proceeding of IEE Software, Vol.151, No.4, Aug. 2004
35 Zhu X., and Jin Z., “Detecting of requirements inconsistency: an ontology-based approach,” Proceedings of the 2005 The Fifth International Conference on Computer and Information Technology, 2005, pp.869- 875.