2008年5月23日 星期五
Auction UC - Manage Account
http://cid-90dadd2e56b02895.skydrive.live.com/self.aspx/%e5%85%ac%e9%96%8b/Manage%20Account%20UC.doc
1.1 Brief Description
The Manage Account use case allows the User to update the user information maintained in the User's account, or to deactivate the User's account.
When modifying the account, the entered information is validated and stored in the User's account.
If new credit card information is entered, the system attempts to pay any pending payment notices via the Credit Service Bureau.
If there are any auctions in progress for the account, or the User has any pending payments, the account cannot be deactivated.
A deactivated account is not deleted from the system (it may be needed later for auditing purposes), but it cannot be accessed by the User. Thus, a deactivated account cannot be used to sign in. Deactivated user accounts are removed by a separate archiving process (see the Archive Deactivated Items use case). A new account with the same username cannot be reused until the “old” user account is archived.
The User must be signed in in order to update his/her account. See the Sign In use case.
For information on how a user account is created, see the Create Account use case.
1.1 Brief Description
The Manage Account use case allows the User to update the user information maintained in the User's account, or to deactivate the User's account.
When modifying the account, the entered information is validated and stored in the User's account.
If new credit card information is entered, the system attempts to pay any pending payment notices via the Credit Service Bureau.
If there are any auctions in progress for the account, or the User has any pending payments, the account cannot be deactivated.
A deactivated account is not deleted from the system (it may be needed later for auditing purposes), but it cannot be accessed by the User. Thus, a deactivated account cannot be used to sign in. Deactivated user accounts are removed by a separate archiving process (see the Archive Deactivated Items use case). A new account with the same username cannot be reused until the “old” user account is archived.
The User must be signed in in order to update his/her account. See the Sign In use case.
For information on how a user account is created, see the Create Account use case.
Auction UC - Create Account
http://cid-90dadd2e56b02895.skydrive.live.com/self.aspx/%e5%85%ac%e9%96%8b/Create%20Account%20UC.doc
1. Create Account
1.1 Brief Description
The Create Account use case allows the User to create and activate an account that contains information for the User.
At the time the user activates the account the user is signed in.
1. Create Account
1.1 Brief Description
The Create Account use case allows the User to create and activate an account that contains information for the User.
At the time the user activates the account the user is signed in.
Auction UC - Close Auction
http://cid-90dadd2e56b02895.skydrive.live.com/self.aspx/%e5%85%ac%e9%96%8b/Close%20Auction%20UC.DOC
1. Close Auction
1.1 Brief Description
At the expiration of the end of auction timer, this use case closes out an auction. The end of auction timer is set when the Seller specifies a bidding time limit when the auction is created. See the Create Auction use case.
When an auction is closed, the current best bid for the item is accepted (the best bid becomes the purchase price for the item). The system notifies the Buyer and Seller that the auction has completed and provides each with the final purchase price for the item, as well as contact information for the other.
The Seller's credit card (credit card information is maintained with the auction and/or with the user account) is charged the transaction fee.
1. Close Auction
1.1 Brief Description
At the expiration of the end of auction timer, this use case closes out an auction. The end of auction timer is set when the Seller specifies a bidding time limit when the auction is created. See the Create Auction use case.
When an auction is closed, the current best bid for the item is accepted (the best bid becomes the purchase price for the item). The system notifies the Buyer and Seller that the auction has completed and provides each with the final purchase price for the item, as well as contact information for the other.
The Seller's credit card (credit card information is maintained with the auction and/or with the user account) is charged the transaction fee.
Auction UC - Bid on Item
http://cid-90dadd2e56b02895.skydrive.live.com/self.aspx/%e5%85%ac%e9%96%8b/Bid%20on%20Item%20UC.DOC
1. Bid on Item
1.1 Brief Description
When browsing an item currently available via auction (see the Browse Auction Catalog use case), a Buyer may opt to place a bid on the item. The entered bid must be greater than the current bid by an amount greater than the minimum bid increment specified by the Seller. Once accepted the entered bid becomes the current bid.
The User must be signed in in order to bid on an item. See the Sign In use case.
If the auction has been closed, the bid is not accepted. See the Close Auction use case.
If the Buyer has any pending payment notices, a message is displayed to the Buyer, reminding the Buyer that payment for the notices must be made (i.e., new credit card information must be entered) before the User can participate in any auction (as either the Buyer or the Seller. New credit card information can be entered via the Manage Account use case.
1. Bid on Item
1.1 Brief Description
When browsing an item currently available via auction (see the Browse Auction Catalog use case), a Buyer may opt to place a bid on the item. The entered bid must be greater than the current bid by an amount greater than the minimum bid increment specified by the Seller. Once accepted the entered bid becomes the current bid.
The User must be signed in in order to bid on an item. See the Sign In use case.
If the auction has been closed, the bid is not accepted. See the Close Auction use case.
If the Buyer has any pending payment notices, a message is displayed to the Buyer, reminding the Buyer that payment for the notices must be made (i.e., new credit card information must be entered) before the User can participate in any auction (as either the Buyer or the Seller. New credit card information can be entered via the Manage Account use case.
Auction UC - Browse Auction Catalog
http://cid-90dadd2e56b02895.skydrive.live.com/self.aspx/%e5%85%ac%e9%96%8b/Browse%20Auction%20Catalog%20UC.DOC
1. Browse Auction Catalog
1.1 Brief Description
This use case allows a User to browse the items currently available for auction. The User may search for a specific item, or may look at all of the items currently available for auction, sorted by category.
The system displays information on the requested item, including, but not limited to the item description, current best bid, minimum bid increment, and bidding history.
Once an auction item is displayed, the User has the option of bidding on the item. See the Bid on Item use case.
The User does not have to be signed on to browse the auction catalog.
1. Browse Auction Catalog
1.1 Brief Description
This use case allows a User to browse the items currently available for auction. The User may search for a specific item, or may look at all of the items currently available for auction, sorted by category.
The system displays information on the requested item, including, but not limited to the item description, current best bid, minimum bid increment, and bidding history.
Once an auction item is displayed, the User has the option of bidding on the item. See the Bid on Item use case.
The User does not have to be signed on to browse the auction catalog.
Auction UC - Create Auction
Use Case Specification: Create Auction
1. Create Auction
http://cid-90dadd2e56b02895.skydrive.live.com/self.aspx/%e5%85%ac%e9%96%8b/Create%20Auction%20UC.DOC
1.1 Brief Description
The Create Auction use case allows a Seller to create an online auction. The Seller specifies auction information (including the start and end of the auction), his credit card information (if not provided or during account creation, see the Create Account use case, or different for this auction) and can provide an image of the item, and an online auction is created for the item. Buyers can then bid on the item in the auction (see the Bid on Item use case).
An end of auction timer is set for the entered end of the action day and time. When that auction time expires, the auction is closed (see the Close Auction use case).
The seller can use the credit card information that is stored with her/his account or input credit card information that will be used with this auction only.
The User must be signed in order to create an auction. See the Sign In use case.
If the User has any pending payment notices due, a message is displayed to the User informing him/her that an outstanding balance is due, and the User is not permitted to create an auction. The user must go into his/her account and modify the credit card information (see the Manage Account use case).
2. Flow of Events
2.1 Basic Flow
1. This use case starts when the Seller indicates to the system that he/she wishes to create an auction in order to sell an item.
2. The system prompts the Seller to enter the auction information and indicate if s/he wants to provide an image of the item.
3. The Seller enters the auction information. If the seller indicated that s/he wants to provide an image of the item, the systems prompts the seller to select the file with the item image (.gif or .jpag, …). The system validates the entered auction information.
4. The System displays the auction information and requests that the Seller confirm.
5. The Seller confirms the entered auction information.
6. The system prompts the Seller to enter credit card information to be used for payment of the auction fees. If the Seller provided credit card information when he/she created his/her account (see the Create Account use case), that credit information is displayed as the default values for the credit card information. The Seller can then use that credit card information (the credit card information “on file”), or the Seller can enter new credit card information.
Note: The new credit information is used for the auction being created (instead of the “on file” credit card information). The on file credit card information remains unchanged. The only way to change the on file credit card information is via the Manage Account use case.
Note: Any entered credit card information is not validated at this time since a credit card’s validity can change between when it is entered and when something actually needs to be charged to it. Thus, the credit card will be validated prior to charging something to it.
7. The system creates an auction with the entered information. The auction is now open for bidding.
8. The system sets an EndOfAuction timer to expire on the day and time specified for the auction duration.
9. The system displays an “auction created successfully” screen that the seller can print for his/her record.
10. The use case ends.
2.2 Alternative Flows
2.2.1 Seller Has Pending Payments
If the Seller has any pending payment notices, the following occurs at the start of the use case before the system prompts the Seller to enter the information for the new auction (i.e., before Step 2):
- The System displays a message to the Seller reminding him/her that he/she has pending payments that are due and that, until those payments are made, the Seller cannot participate in an auction, either as a Buyer or a Seller. To settle the payment notices, the Seller must enter new credit card information. Credit card information can be entered via the Manage Account use case.
- The use case ends (no auction is created).
-
2.2.2 Seller Cancels Create Auction Request
At any time, the User may choose to cancel the Create Auction request. In such a case, the use case ends and an auction is not created.
2.2.3 Seller Enters Invalid Auction Information
If the system determines that the Seller entered invalid auction information, the following occurs:
- The system describes which entered data was invalid and presents the Seller with suggestions for entering valid data.
- The system prompts the Seller to re-enter the auction information.
- The Seller re-enters the information and the system re-validates it.
- If valid information is entered, the auction information is stored.
- If invalid information is entered, the Seller Enters Invalid Auction Information alternative flow is executed again. This repeats until valid information is entered or the Seller cancels the create auction request.
3. Special Requirements
None
4. Pre-Conditions
4.1 Seller is Signed In
The Seller must be signed in before the Seller can create an auction. See the Sign In use case.
5. Post-Conditions
5.1 An auction is created.
An auction for the item with the entered auction characteristics has been created. Buyers may now bid on the item.
OR
5.2 An auction is not created because of pending payment notices or the Seller cancels the request
An auction for the item with the entered auction characteristics was not created because the User has pending payment notices (i.e., still owes the system money).
6. Extension Points
Step 2. If the Re-List Previously Listed Item use-case is implemented, the systems shows an potion to re-list as an extension of this use case.
1. Create Auction
http://cid-90dadd2e56b02895.skydrive.live.com/self.aspx/%e5%85%ac%e9%96%8b/Create%20Auction%20UC.DOC
1.1 Brief Description
The Create Auction use case allows a Seller to create an online auction. The Seller specifies auction information (including the start and end of the auction), his credit card information (if not provided or during account creation, see the Create Account use case, or different for this auction) and can provide an image of the item, and an online auction is created for the item. Buyers can then bid on the item in the auction (see the Bid on Item use case).
An end of auction timer is set for the entered end of the action day and time. When that auction time expires, the auction is closed (see the Close Auction use case).
The seller can use the credit card information that is stored with her/his account or input credit card information that will be used with this auction only.
The User must be signed in order to create an auction. See the Sign In use case.
If the User has any pending payment notices due, a message is displayed to the User informing him/her that an outstanding balance is due, and the User is not permitted to create an auction. The user must go into his/her account and modify the credit card information (see the Manage Account use case).
2. Flow of Events
2.1 Basic Flow
1. This use case starts when the Seller indicates to the system that he/she wishes to create an auction in order to sell an item.
2. The system prompts the Seller to enter the auction information and indicate if s/he wants to provide an image of the item.
3. The Seller enters the auction information. If the seller indicated that s/he wants to provide an image of the item, the systems prompts the seller to select the file with the item image (.gif or .jpag, …). The system validates the entered auction information.
4. The System displays the auction information and requests that the Seller confirm.
5. The Seller confirms the entered auction information.
6. The system prompts the Seller to enter credit card information to be used for payment of the auction fees. If the Seller provided credit card information when he/she created his/her account (see the Create Account use case), that credit information is displayed as the default values for the credit card information. The Seller can then use that credit card information (the credit card information “on file”), or the Seller can enter new credit card information.
Note: The new credit information is used for the auction being created (instead of the “on file” credit card information). The on file credit card information remains unchanged. The only way to change the on file credit card information is via the Manage Account use case.
Note: Any entered credit card information is not validated at this time since a credit card’s validity can change between when it is entered and when something actually needs to be charged to it. Thus, the credit card will be validated prior to charging something to it.
7. The system creates an auction with the entered information. The auction is now open for bidding.
8. The system sets an EndOfAuction timer to expire on the day and time specified for the auction duration.
9. The system displays an “auction created successfully” screen that the seller can print for his/her record.
10. The use case ends.
2.2 Alternative Flows
2.2.1 Seller Has Pending Payments
If the Seller has any pending payment notices, the following occurs at the start of the use case before the system prompts the Seller to enter the information for the new auction (i.e., before Step 2):
- The System displays a message to the Seller reminding him/her that he/she has pending payments that are due and that, until those payments are made, the Seller cannot participate in an auction, either as a Buyer or a Seller. To settle the payment notices, the Seller must enter new credit card information. Credit card information can be entered via the Manage Account use case.
- The use case ends (no auction is created).
-
2.2.2 Seller Cancels Create Auction Request
At any time, the User may choose to cancel the Create Auction request. In such a case, the use case ends and an auction is not created.
2.2.3 Seller Enters Invalid Auction Information
If the system determines that the Seller entered invalid auction information, the following occurs:
- The system describes which entered data was invalid and presents the Seller with suggestions for entering valid data.
- The system prompts the Seller to re-enter the auction information.
- The Seller re-enters the information and the system re-validates it.
- If valid information is entered, the auction information is stored.
- If invalid information is entered, the Seller Enters Invalid Auction Information alternative flow is executed again. This repeats until valid information is entered or the Seller cancels the create auction request.
3. Special Requirements
None
4. Pre-Conditions
4.1 Seller is Signed In
The Seller must be signed in before the Seller can create an auction. See the Sign In use case.
5. Post-Conditions
5.1 An auction is created.
An auction for the item with the entered auction characteristics has been created. Buyers may now bid on the item.
OR
5.2 An auction is not created because of pending payment notices or the Seller cancels the request
An auction for the item with the entered auction characteristics was not created because the User has pending payment notices (i.e., still owes the system money).
6. Extension Points
Step 2. If the Re-List Previously Listed Item use-case is implemented, the systems shows an potion to re-list as an extension of this use case.
2008年2月1日 星期五
use case sample - Maintain Issue Information
1. Abstract of Maintain Issue Information
1.1 Feature ID:
1.2 Actors: Tester, Developer, Manager
1.3 Description: 問題的追蹤與管理
1.4 Key Abstractions: Issue, Project, Role, Permission
2. Basic Flow
1. 系統顯示使用者可以查看的問題列表, refer 2.2
a. 顯示的欄位為Project name, issue id, description, category, reporter, report Time, priority, status, assign-to
2. 系統根據使用者角色顯示可以操作的功能
3. 使用者選擇功能
a. 新增問題
b. 選擇問題進行檢視
c. 輸入issue id進行檢視
d. 選擇問題進行修改
e. 選擇欄位進行排序
f. 撤銷問題
g. Import問題
h. export問題
4. 使用者登出系統
a. 使用者直接關閉browser
2.1 新增問題
1. 系統顯示輸入畫面
2. 使用者輸入問題報告
3. 系統建立問題，顯示詳細資料編輯功能
4. 使用者編輯詳細資料, refer 2.2
2.2 編輯詳細資料
1. 系統顯示issue id及詳細資料輸入畫面
2. 系統根據使用者角色顯示可以操作的功能
3. 使用者選擇功能
a. Attach file
b. 設定Mail notification list
c. Subscribe Mail notification
d. Send Mail
e. 設定關連的問題, relate to other issues.
f. Print
g. Export
4. 使用者完成動作
3. Alternative Flows
4. Subflows
5. Key Scenarios
6. Pre-Conditions
6.1 使用者已經登入系統
7. Post-Conditions
8. Extension Points
9. Special Requirements
9.1 Performance
9.1.1 每個畫面反應時間3 seconds
a) 上傳檔案另外規範
9.2 Usability
9.3 Security
10. Additional Information
10.1 User Interface
10.1.1 新增問題畫面需求
Description欄位提供textbox
Project欄位提供預設值, 及project listbox
Category欄位提供Category listbox
Priority欄位提供Priority listbox
Status欄位提供Status listbox
AssignTo欄位提供AssignTo listbox (如果是Manager自行submit, 可以指派處理人員)
Comment欄位提供textbox
10.1.2 Data Definition
Issue: Project name, issue id, description, category, reporter, report Time, priority, status, assign-to
Category: bug, enhancement, task, question
Priority: hi, me, lo
Status: new, in progress, checked in, re-opened, closed
2007年7月14日 星期六
Glossary - UC2 維護詞彙
1. Brief Description
Title: 維護詞彙
Requirement ID:
Intent: 讓管理員可以維護整個詞彙系統。
Actors: 管理員
Description: 管理員可以進入詞彙系統，對詞彙、詞彙所屬的領域、詞彙相關的專案進行增加、刪除、修改等工作（其中刪除領域、專案或詞彙並非真的刪除，而是將其移到一個查詢功能無法查到的位置即可）。同時還提供專案之間的詞彙複製功能。另外，管理員的所有動作都要被紀錄下來。
2. Flow of Events
2.1 Basic Flow: maintain logon status
1. 管理員連接到詞彙系統的管理網頁。
2. 系統顯示管理功能，管理員可以使用以下的功能：
A. 管理領域(ref 2.1.1)
B. 管理詞彙(ref 2.1.2)
C. 管理專案(ref 2.1.3)
D. 檢視保留區(ref 2.1.4)
E. 結束管理功能。系統會回到步驟1（使用者只要關閉網頁，就會結束Use Case）
3. 回到步驟1。
2.1.1 管理領域
2.1.1.1 新建領域
1. 系統要求使用者輸入領域的名稱。
2. 管理員輸入領域的名稱，長度要在255英文字或是127個中文字以內。
3. 詞彙系統建立新的領域。如果發現領域名稱重複（標示為已刪除者除外），就提示管理員，並回到步驟2。
4. 將管理員完成增加領域的日期，時間及動作紀錄（包含新增的領域名稱）到詞彙系統的資料庫中。
2.1.1.2 刪除領域
1. 系統列出目前所有的領域名稱。
2. 管理員選擇要刪除的領域。
3. 系統提示管理員是否刪除這個領域。如果管理員選擇否，就回到步驟1。
4. 系統再次提示管理員，這樣會刪除這個領域中所有的詞彙，是否確定。如果管理員選擇否，就回到步驟1。
5. 系統將這個領域所有的詞彙移到保留區當中，讓查詢功能無法查到。
6. 系統將這個領域標示為已經刪除。
7. 將管理員完成刪除領域的日期，時間及動作紀錄（包含刪除的領域名稱）到詞彙系統的資料庫中。
2.1.1.3 修改領域
1. 系統列出目前所有的領域名稱。
2. 管理員選擇要刪除的領域。
3. 系統提示管理員是否刪除這個領域。如果管理員選擇否，就回到步驟1。
4. 系統再次提示管理員，這樣會刪除這個領域中所有的詞彙，是否確定。如果管理員選擇否，就回到步驟1。
5. 系統將這個領域所有的詞彙移到保留區當中，讓查詢功能無法查到。
6. 系統將這個領域標示為已經刪除。
7. 將管理員完成刪除領域的日期，時間及動作紀錄（包含刪除的領域名稱）到詞彙系統的資料庫中。
2.1.2 管理詞彙
2.1.2.1 新建詞彙
1. 系統列出目前所有的領域名稱。
2. 管理員選擇要增加詞彙的領域，如果沒有選擇，預設是”通用”（表示所有領域都相同）。
3. 管理員輸入詞彙的以下內容：
A. 英文名稱
B. 簡體中文名稱
C. 繁體中文名稱
D. 英文解釋
E. 簡體中文解釋
F. 繁體中文解釋
G. 相關的專案(從列表中鈎選，可以不選，表示不屬於任何專案)
4. 系統將詞彙加入資料庫中。如果發現詞彙在相同的領域或相同的项目中已經有重複，就提示管理員，並回到步驟3。
5. 將管理員完成增加詞彙的日期，時間及動作紀錄（包含新增的詞彙）到詞彙系統的資料庫中。
2.1.2.2 刪除詞彙
1. 系統列出目前所有的領域名稱。
2. 管理員選擇要刪除詞彙的領域。
3. 系統列出該領域所有的詞彙，讓管理員選擇要刪除的詞彙。
4. 系統顯示該詞彙的以下資訊：
A. 英文名稱
B. 簡體中文名稱
C. 繁體中文名稱
D. 英文解釋
E. 簡體中文解釋
F. 繁體中文解釋
G. 相關的專案
5. 系統提示管理員是否刪除這個詞彙。如果管理員選擇否，就回到步驟1。
6. 系統再次提示管理員，這樣會從相關專案中刪除這個詞彙，是否確定。如果管理員選擇否，就回到步驟1。
7. 系統刪除這個詞彙與所有相關專案的相關關係，並將其移到保留區當中，讓查詢功能無法查到。
8. 將管理員完成刪除詞彙的日期，時間及動作紀錄（包含刪除的詞彙）到詞彙系統的資料庫中。
2.1.2.3 修改詞彙
1. 系統列出目前所有的領域名稱。
2. 管理員選擇要刪除詞彙的領域。
3. 系統列出該領域所有的詞彙，讓管理員選擇要修改的詞彙。
4. 系統顯示該詞彙的以下資訊：
A. 英文名稱
B. 簡體中文名稱
C. 繁體中文名稱
D. 英文解釋
E. 簡體中文解釋
F. 繁體中文解釋
G. 相關的專案(以列表鈎選的形式呈現，可以不選,表示不屬於任何專案)
5. 管理員可以變更這個詞彙的：
A. 英文名稱
B. 簡體中文名稱
C. 繁體中文名稱
D. 英文解釋
E. 簡體中文解釋
F. 繁體中文解釋
G. 適用的領域
H. 所在的專案((從列表中鈎選，可以不選,表示不屬於任何專案)
6. 系統提示管理員是否將這個詞彙變更，並顯示出這個詞彙新舊的：
A. 英文名稱
B. 簡體中文名稱
C. 繁體中文名稱
D. 英文解釋
E. 簡體中文解釋
F. 繁體中文解釋
G. 適用的領域
H. 相關的專案
如果管理員選擇否，就回到步驟1。
7. 系統變更資料庫中的詞彙。如果發現詞彙的英文名稱與適用的領域或相關的專案有重複，就提示管理員，並回到步驟1。
8. 將管理員完成修改詞彙的日期，時間及動作紀錄（包含詞彙的新舊資訊）到詞彙系統的資料庫中。
2.1.3 管理專案
2.1.3.1 新建專案
1. 系統要求使用者輸入專案的名稱。
2. 管理員輸入專案的名稱，長度要在255英文字或是127個中文字以內。
3. 詞彙系統建立新的專案。如果發現專案名稱重複（標示為已刪除者除外），就提示管理員，並回到步驟2。
4. 將管理員完成增加專案的日期，時間及動作紀錄（包含新增的專案名稱）到詞彙系統的資料庫中。
2.1.3.2 刪除專案
1. 系統列出目前所有的專案名稱。
2. 管理員選擇要刪除的專案。
3. 系統提示管理員是否刪除這個專案。如果管理員選擇否，就回到步驟1。
4. 系統再次提示管理員，這樣會刪除這個專案與所有的詞彙的相關關係，是否確定。如果管理員選擇否，就回到步驟1。
5. 系統刪除這個專案與所有的詞彙的相關關係。
6. 系統將這個專案標示為已經刪除。
7. 將管理員完成刪除專案的日期，時間及動作紀錄（包含刪除的專案名稱）到詞彙系統的資料庫中。
2.1.3.3 修改專案名稱
1. 系統列出目前所有的專案名稱。
2. 管理員選擇要更名的專案。
3. 系統要求管理員輸入新的專案名稱，預設是原來的專案名稱。
4. 系統提示管理員是否將這個專案更名，並顯示出新舊兩個專案名稱。如果管理員選擇否，就回到步驟1。
5. 系統變更資料庫中的專案名稱。如果發現專案名稱重複（標示為已刪除者除外），就提示管理員，並回到步驟2。
6. 將管理員完成刪除專案的日期，時間及動作紀錄（包含新舊專案名稱）到詞彙系統的資料庫中。
2.1.3.4 複製詞彙
1. 系統列出目前所有的專案名稱。
2. 管理員選擇要複製的詞彙所在的專案。
3. 系統列出專案相關的所有詞彙。
4. 管理員選擇要複製的詞彙。
5. 系統顯示該詞彙的以下資訊：
A. 英文名稱
B. 簡體中文名稱
C. 繁體中文名稱
D. 英文解釋
E. 簡體中文解釋
F. 繁體中文解釋
G. 適用的領域
6. 系統列出原專案之外所有的專案，提示管理員選擇要複製到的詞彙。
7. 系統提示管理員是否將這個詞彙複製到目標專案，並顯示出詞彙信息及目標專案名稱。如果管理員選擇否，就回到步驟1。
8. 系統向資料庫添加目标项目的新詞彙条目。如果發現目標專案詞彙名稱重複（標示為已刪除者除外），就提示管理員，並回到步驟2。
9. 將管理員完成复制專案詞彙的日期，時間及動作紀錄（包含源目標專案和詞彙名稱）到詞彙系統的資料庫中。
2.2 Alternative Flows
3. Special Requirements
1. 網站使用IIS建置
2. 詞彙資料庫使用SQL Server
4. Pre-Conditions
1. 每個使用者登入時都要經過伺服器的Windows認證
5. Post-Conditions
6. Uses/Dependency
6.1 Database definitions
6.2 User Interface prototypes
6.3 Dependent components
7. Extension Points
8. Appendix
1. 詞彙（glossary）：本系統的每個詞彙要包含以下資訊：
A. 英文名稱
B. 簡體中文名稱
C. 繁體中文名稱
D. 英文解釋
E. 簡體中文解釋
F. 繁體中文解釋
G. 適用的領域
H. 所在的專案
Title: 維護詞彙
Requirement ID:
Intent: 讓管理員可以維護整個詞彙系統。
Actors: 管理員
Description: 管理員可以進入詞彙系統，對詞彙、詞彙所屬的領域、詞彙相關的專案進行增加、刪除、修改等工作（其中刪除領域、專案或詞彙並非真的刪除，而是將其移到一個查詢功能無法查到的位置即可）。同時還提供專案之間的詞彙複製功能。另外，管理員的所有動作都要被紀錄下來。
2. Flow of Events
2.1 Basic Flow: maintain logon status
1. 管理員連接到詞彙系統的管理網頁。
2. 系統顯示管理功能，管理員可以使用以下的功能：
A. 管理領域(ref 2.1.1)
B. 管理詞彙(ref 2.1.2)
C. 管理專案(ref 2.1.3)
D. 檢視保留區(ref 2.1.4)
E. 結束管理功能。系統會回到步驟1（使用者只要關閉網頁，就會結束Use Case）
3. 回到步驟1。
2.1.1 管理領域
2.1.1.1 新建領域
1. 系統要求使用者輸入領域的名稱。
2. 管理員輸入領域的名稱，長度要在255英文字或是127個中文字以內。
3. 詞彙系統建立新的領域。如果發現領域名稱重複（標示為已刪除者除外），就提示管理員，並回到步驟2。
4. 將管理員完成增加領域的日期，時間及動作紀錄（包含新增的領域名稱）到詞彙系統的資料庫中。
2.1.1.2 刪除領域
1. 系統列出目前所有的領域名稱。
2. 管理員選擇要刪除的領域。
3. 系統提示管理員是否刪除這個領域。如果管理員選擇否，就回到步驟1。
4. 系統再次提示管理員，這樣會刪除這個領域中所有的詞彙，是否確定。如果管理員選擇否，就回到步驟1。
5. 系統將這個領域所有的詞彙移到保留區當中，讓查詢功能無法查到。
6. 系統將這個領域標示為已經刪除。
7. 將管理員完成刪除領域的日期，時間及動作紀錄（包含刪除的領域名稱）到詞彙系統的資料庫中。
2.1.1.3 修改領域
1. 系統列出目前所有的領域名稱。
2. 管理員選擇要刪除的領域。
3. 系統提示管理員是否刪除這個領域。如果管理員選擇否，就回到步驟1。
4. 系統再次提示管理員，這樣會刪除這個領域中所有的詞彙，是否確定。如果管理員選擇否，就回到步驟1。
5. 系統將這個領域所有的詞彙移到保留區當中，讓查詢功能無法查到。
6. 系統將這個領域標示為已經刪除。
7. 將管理員完成刪除領域的日期，時間及動作紀錄（包含刪除的領域名稱）到詞彙系統的資料庫中。
2.1.2 管理詞彙
2.1.2.1 新建詞彙
1. 系統列出目前所有的領域名稱。
2. 管理員選擇要增加詞彙的領域，如果沒有選擇，預設是”通用”（表示所有領域都相同）。
3. 管理員輸入詞彙的以下內容：
A. 英文名稱
B. 簡體中文名稱
C. 繁體中文名稱
D. 英文解釋
E. 簡體中文解釋
F. 繁體中文解釋
G. 相關的專案(從列表中鈎選，可以不選，表示不屬於任何專案)
4. 系統將詞彙加入資料庫中。如果發現詞彙在相同的領域或相同的项目中已經有重複，就提示管理員，並回到步驟3。
5. 將管理員完成增加詞彙的日期，時間及動作紀錄（包含新增的詞彙）到詞彙系統的資料庫中。
2.1.2.2 刪除詞彙
1. 系統列出目前所有的領域名稱。
2. 管理員選擇要刪除詞彙的領域。
3. 系統列出該領域所有的詞彙，讓管理員選擇要刪除的詞彙。
4. 系統顯示該詞彙的以下資訊：
A. 英文名稱
B. 簡體中文名稱
C. 繁體中文名稱
D. 英文解釋
E. 簡體中文解釋
F. 繁體中文解釋
G. 相關的專案
5. 系統提示管理員是否刪除這個詞彙。如果管理員選擇否，就回到步驟1。
6. 系統再次提示管理員，這樣會從相關專案中刪除這個詞彙，是否確定。如果管理員選擇否，就回到步驟1。
7. 系統刪除這個詞彙與所有相關專案的相關關係，並將其移到保留區當中，讓查詢功能無法查到。
8. 將管理員完成刪除詞彙的日期，時間及動作紀錄（包含刪除的詞彙）到詞彙系統的資料庫中。
2.1.2.3 修改詞彙
1. 系統列出目前所有的領域名稱。
2. 管理員選擇要刪除詞彙的領域。
3. 系統列出該領域所有的詞彙，讓管理員選擇要修改的詞彙。
4. 系統顯示該詞彙的以下資訊：
A. 英文名稱
B. 簡體中文名稱
C. 繁體中文名稱
D. 英文解釋
E. 簡體中文解釋
F. 繁體中文解釋
G. 相關的專案(以列表鈎選的形式呈現，可以不選,表示不屬於任何專案)
5. 管理員可以變更這個詞彙的：
A. 英文名稱
B. 簡體中文名稱
C. 繁體中文名稱
D. 英文解釋
E. 簡體中文解釋
F. 繁體中文解釋
G. 適用的領域
H. 所在的專案((從列表中鈎選，可以不選,表示不屬於任何專案)
6. 系統提示管理員是否將這個詞彙變更，並顯示出這個詞彙新舊的：
A. 英文名稱
B. 簡體中文名稱
C. 繁體中文名稱
D. 英文解釋
E. 簡體中文解釋
F. 繁體中文解釋
G. 適用的領域
H. 相關的專案
如果管理員選擇否，就回到步驟1。
7. 系統變更資料庫中的詞彙。如果發現詞彙的英文名稱與適用的領域或相關的專案有重複，就提示管理員，並回到步驟1。
8. 將管理員完成修改詞彙的日期，時間及動作紀錄（包含詞彙的新舊資訊）到詞彙系統的資料庫中。
2.1.3 管理專案
2.1.3.1 新建專案
1. 系統要求使用者輸入專案的名稱。
2. 管理員輸入專案的名稱，長度要在255英文字或是127個中文字以內。
3. 詞彙系統建立新的專案。如果發現專案名稱重複（標示為已刪除者除外），就提示管理員，並回到步驟2。
4. 將管理員完成增加專案的日期，時間及動作紀錄（包含新增的專案名稱）到詞彙系統的資料庫中。
2.1.3.2 刪除專案
1. 系統列出目前所有的專案名稱。
2. 管理員選擇要刪除的專案。
3. 系統提示管理員是否刪除這個專案。如果管理員選擇否，就回到步驟1。
4. 系統再次提示管理員，這樣會刪除這個專案與所有的詞彙的相關關係，是否確定。如果管理員選擇否，就回到步驟1。
5. 系統刪除這個專案與所有的詞彙的相關關係。
6. 系統將這個專案標示為已經刪除。
7. 將管理員完成刪除專案的日期，時間及動作紀錄（包含刪除的專案名稱）到詞彙系統的資料庫中。
2.1.3.3 修改專案名稱
1. 系統列出目前所有的專案名稱。
2. 管理員選擇要更名的專案。
3. 系統要求管理員輸入新的專案名稱，預設是原來的專案名稱。
4. 系統提示管理員是否將這個專案更名，並顯示出新舊兩個專案名稱。如果管理員選擇否，就回到步驟1。
5. 系統變更資料庫中的專案名稱。如果發現專案名稱重複（標示為已刪除者除外），就提示管理員，並回到步驟2。
6. 將管理員完成刪除專案的日期，時間及動作紀錄（包含新舊專案名稱）到詞彙系統的資料庫中。
2.1.3.4 複製詞彙
1. 系統列出目前所有的專案名稱。
2. 管理員選擇要複製的詞彙所在的專案。
3. 系統列出專案相關的所有詞彙。
4. 管理員選擇要複製的詞彙。
5. 系統顯示該詞彙的以下資訊：
A. 英文名稱
B. 簡體中文名稱
C. 繁體中文名稱
D. 英文解釋
E. 簡體中文解釋
F. 繁體中文解釋
G. 適用的領域
6. 系統列出原專案之外所有的專案，提示管理員選擇要複製到的詞彙。
7. 系統提示管理員是否將這個詞彙複製到目標專案，並顯示出詞彙信息及目標專案名稱。如果管理員選擇否，就回到步驟1。
8. 系統向資料庫添加目标项目的新詞彙条目。如果發現目標專案詞彙名稱重複（標示為已刪除者除外），就提示管理員，並回到步驟2。
9. 將管理員完成复制專案詞彙的日期，時間及動作紀錄（包含源目標專案和詞彙名稱）到詞彙系統的資料庫中。
2.2 Alternative Flows
3. Special Requirements
1. 網站使用IIS建置
2. 詞彙資料庫使用SQL Server
4. Pre-Conditions
1. 每個使用者登入時都要經過伺服器的Windows認證
5. Post-Conditions
6. Uses/Dependency
6.1 Database definitions
6.2 User Interface prototypes
6.3 Dependent components
7. Extension Points
8. Appendix
1. 詞彙（glossary）：本系統的每個詞彙要包含以下資訊：
A. 英文名稱
B. 簡體中文名稱
C. 繁體中文名稱
D. 英文解釋
E. 簡體中文解釋
F. 繁體中文解釋
G. 適用的領域
H. 所在的專案
訂閱：
文章 (Atom)
