1. Product Features
1.1 Easy to Install
1.1.1 Standard installation
1.1.2 Quick Installation
1.1.2.1 Build-in DB
1.1.2.2 Build-in Web server
1.1.2.3 Start & stop batch command
1.2 User definable space/project
1.2.1 Custom Fields
1.2.1.1 Support custom fields: Text Field, Number, Drop Down List, Date Picker
1.2.2 Custom Workflow
1.2.3 Custom Roles and state transition
1.3 Detailed History View
1.4 Attachments Support
1.5 Search Custom Fields
1.6 Search Across All Projects
1.7 Full Text Search
1.8 Dashboard
1.9 Export to Excel
1.9.1 Export any item list to excel
1.10 Simple Navigation
1.11 Cross Referencing of Items
1.11.1 Able to establish bi-directional links between items, such as duplication
1.12 Anonymous Read-Only Access
1.12.1 Per-space or per-project setting
1.13 E-mail Integration
1.13.1 Customize status changes notification
1.13.2 Provide html email
1.13.3 Support role-based selection
1.13.4 Support user-based selection
1.14 Multi-Language Support
1.14.1 change the user interface language instantly
1.14.2 preserve selection in user-profile
1.14.3 end-user translation tool
1.15 Multi-platform authentication support
1.15.1 LDAP
1.15.2 MS AD
2007年12月7日 星期五
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. 所在的專案
Glossary - UC1查詢詞彙
1. Brief Description
Title: 搜尋詞彙
Requirement ID:
Intent: 讓使用者依據條件找到詞彙的英文、簡體中文與繁體中文的名稱，以及解釋。
Actors: 使用者，管理員
Description: 使用者可以連接到詞彙系統的網頁，詞彙系統會依據使用者輸入的條件，從系統中找出符合條件的詞彙，顯示在網頁上。如果找不到符合條件的詞彙，使用者可以重新輸入條件進行搜尋；或是發出一個郵件要求管理員增加詞彙。
2. Flow of Events
2.1 Basic Flow: maintain logon status
1. 使用者連接到詞彙系統的網頁。
2. 系統顯示查詢網頁，可用的條件有
· 英文
· 繁體中文
· 簡體中文
· 英文解釋
· 簡體中文解釋
· 繁體中文解釋
· 適用的領域（以下拉框顯示，包含目前詞彙系統中所有的領域，預設為”通用”，表示所有領域都適用）
· 相關的專案（以下拉框顯示，包含目前詞彙系統中所有的專案，預設為空，表示不與任何專案相關）
使用者輸入的條件可以是片段的。
3. 使用者在上述的條件中輸入所需的條件之後，要求系統開始搜尋。
4. 系統在資料庫中搜尋出符合條件的詞彙顯示在網頁上
A. 如果找不到符合的資料ref 2.2.2
5. 使用者可以執行以下的動作：
A. 重新搜尋：跳回步驟3（讓使用者重新輸入條件，預設是使用者上次輸入的條件）
B. 結束搜尋：回到步驟1（使用者只要關閉網頁，就會結束Use Case）
2.2 Alternative Flows
2.2.1 系統找不到符合條件的詞彙
1. 系統顯示”找不到符合條件的詞彙，你要重新輸入條件”。
2. 使用者如果要重新搜尋， 跳回基本流程步驟3（讓使用者重新輸入條件，預設是使用者上次輸入的條件）
3. Special Requirements
1. 網站使用IIS建置
2. 詞彙資料庫使用Access建置
3. 查詢過的object使用Cache
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. 系統顯示查詢網頁，可用的條件有
· 英文
· 繁體中文
· 簡體中文
· 英文解釋
· 簡體中文解釋
· 繁體中文解釋
· 適用的領域（以下拉框顯示，包含目前詞彙系統中所有的領域，預設為”通用”，表示所有領域都適用）
· 相關的專案（以下拉框顯示，包含目前詞彙系統中所有的專案，預設為空，表示不與任何專案相關）
使用者輸入的條件可以是片段的。
3. 使用者在上述的條件中輸入所需的條件之後，要求系統開始搜尋。
4. 系統在資料庫中搜尋出符合條件的詞彙顯示在網頁上
A. 如果找不到符合的資料ref 2.2.2
5. 使用者可以執行以下的動作：
A. 重新搜尋：跳回步驟3（讓使用者重新輸入條件，預設是使用者上次輸入的條件）
B. 結束搜尋：回到步驟1（使用者只要關閉網頁，就會結束Use Case）
2.2 Alternative Flows
2.2.1 系統找不到符合條件的詞彙
1. 系統顯示”找不到符合條件的詞彙，你要重新輸入條件”。
2. 使用者如果要重新搜尋， 跳回基本流程步驟3（讓使用者重新輸入條件，預設是使用者上次輸入的條件）
3. Special Requirements
1. 網站使用IIS建置
2. 詞彙資料庫使用Access建置
3. 查詢過的object使用Cache
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. 相關的專案
2007年7月13日 星期五
eStore - UC6 Checkout
1. Abstract
1.1 Feature ID:
1.2 Actors: Customer
1.3 Description: 使用者Checkout採購項目，輸入shipping & payment資訊，完成採購
2. Basic Flow
使用者在維護購物車畫面中選擇Checkout
1. 系統顯示購物金額
a) 每個項目金額，稅及總額
b) 提醒使用者, 運費需待輸入shipping details後才會計算出來
2. 使用者確認採購項目金額
3. 使用者輸入送貨資料, ref 4.1-輸入送貨資料
4. 使用者輸入付款資訊, ref 4.2-輸入付款資料
5. 系統顯示訂單明細及總金額
6. 使用者確認交易
7. 系統處理訂單 (如果交易失敗, 進入流程 3.3-交易失敗)
8. 系統顯示交易完成訊息，訂單編號及交貨訊息
3. Alternative Flows
3.1 送貨資料錯誤
系統回到輸入送貨資料流程 , 並顯示失敗訊息
a) 使用紅色*提示錯誤的欄位
b) 保留使用者輸入的資料
3.2 付款資料錯誤
系統回到輸入付資資料流程 , 並顯示失敗訊息
c) 使用紅色*提示錯誤的欄位
d) 保留使用者輸入的資料
3.3 交易失敗
1. 輸入的資料沒通過檢查, 系統顯示錯誤訊息，並讓使用者修正輸入的資料
4. Subflows
4.1 輸入送貨資料
1. 系統顯示送貨資料(shipping details)的輸入畫面
2. 使用者輸入下列送貨資料
A. 收件人名稱
B. 地址
C. 連絡電話
D. 送貨方式: 緊急空運, 正常空運, 海運
3. 系統檢查送貨資料, (如果輸入錯誤, 進入流程 3.1-送貨資料錯誤)
4. 系統顯示運費金額
4.2 輸入付款資訊
1. 系統顯示付款資訊輸入畫面
2. 使用者輸入下列付款資料
A. 信用卡類別
B. 名稱
C. 卡號
D. 有效期
3. 系統檢查付款資料(如果輸入錯誤, 進入流程 3.2-付款資料錯誤)
5. Key Scenarios
6. Pre-Conditions
6.1 使用者已經登入系統
7. Post-Conditions
7.1 保留使用者登入狀態
7.2 Web系統清除購物車內容
7.3 Web系統清除客戶的Credit Card資料
8. Extension Points
9. Special Requirements
9.1 交易時間最長8 seconds
9.2 顯示交易處理中的提示訊息
10. Additional Information
10.1 Data definitions
10.2 User Interface prototypes
1.1 Feature ID:
1.2 Actors: Customer
1.3 Description: 使用者Checkout採購項目，輸入shipping & payment資訊，完成採購
2. Basic Flow
使用者在維護購物車畫面中選擇Checkout
1. 系統顯示購物金額
a) 每個項目金額，稅及總額
b) 提醒使用者, 運費需待輸入shipping details後才會計算出來
2. 使用者確認採購項目金額
3. 使用者輸入送貨資料, ref 4.1-輸入送貨資料
4. 使用者輸入付款資訊, ref 4.2-輸入付款資料
5. 系統顯示訂單明細及總金額
6. 使用者確認交易
7. 系統處理訂單 (如果交易失敗, 進入流程 3.3-交易失敗)
8. 系統顯示交易完成訊息，訂單編號及交貨訊息
3. Alternative Flows
3.1 送貨資料錯誤
系統回到輸入送貨資料流程 , 並顯示失敗訊息
a) 使用紅色*提示錯誤的欄位
b) 保留使用者輸入的資料
3.2 付款資料錯誤
系統回到輸入付資資料流程 , 並顯示失敗訊息
c) 使用紅色*提示錯誤的欄位
d) 保留使用者輸入的資料
3.3 交易失敗
1. 輸入的資料沒通過檢查, 系統顯示錯誤訊息，並讓使用者修正輸入的資料
4. Subflows
4.1 輸入送貨資料
1. 系統顯示送貨資料(shipping details)的輸入畫面
2. 使用者輸入下列送貨資料
A. 收件人名稱
B. 地址
C. 連絡電話
D. 送貨方式: 緊急空運, 正常空運, 海運
3. 系統檢查送貨資料, (如果輸入錯誤, 進入流程 3.1-送貨資料錯誤)
4. 系統顯示運費金額
4.2 輸入付款資訊
1. 系統顯示付款資訊輸入畫面
2. 使用者輸入下列付款資料
A. 信用卡類別
B. 名稱
C. 卡號
D. 有效期
3. 系統檢查付款資料(如果輸入錯誤, 進入流程 3.2-付款資料錯誤)
5. Key Scenarios
6. Pre-Conditions
6.1 使用者已經登入系統
7. Post-Conditions
7.1 保留使用者登入狀態
7.2 Web系統清除購物車內容
7.3 Web系統清除客戶的Credit Card資料
8. Extension Points
9. Special Requirements
9.1 交易時間最長8 seconds
9.2 顯示交易處理中的提示訊息
10. Additional Information
10.1 Data definitions
10.2 User Interface prototypes
eStore - UC 5 Maintain Shopping Cart
1. Abstract
1.1 Feature ID:
1.2 Actors: Customer
1.3 Description: Customer新增/修改/刪除採購項目
2. Basic Flow of Events: 維護購物車內容
User新增項目或按maintain shopping cart button/hyperlink進入Maintain shopping cart畫面
1. 系統顯示購物車內容
a) 顯示採購項目的名稱, 數量，描述, price, item total
2. 使用者修改數量
a) 若數量修改為0表示刪除該項目
3. 使用者執行下列功能
a) Update按鈕更新購物車內容, 執行2.2-更新購物車內容
b) Check out: 執行2.2 更新購物車內容後, 進入UC 6 Checkout
2.1 新增項目
使用者從瀏覽產品的畫面,選擇新增採購項目, 進入此流程
1. 系統增加該品項到購物車, 數量為1
2. 回到主流程(basic flow)
2.2 更新購物車內容
1. 系統更新購物車內容, 如果更新錯誤進入3.1-更新失敗
2. 回到主流程(basic flow)
3. Alternative Flows
3.1 更新失敗
系統回到主流程, 並顯示失敗訊息
a) 使用紅色*提示錯誤的欄位
b) 保留使用者輸入的資料
4. Subflows
5. Key Scenarios
6. Pre-Conditions
1. 執行更新功能時，使用者必需先登入成功
7. Post-Conditions
8. Extension Points
9. Special Requirements
9.1 線上購物每個項目的採購數量最多50
9.2 更新反應時間小於5 seconds
10. Additional Information
10.1 Data definitions
10.2 User Interface prototypes
1.1 Feature ID:
1.2 Actors: Customer
1.3 Description: Customer新增/修改/刪除採購項目
2. Basic Flow of Events: 維護購物車內容
User新增項目或按maintain shopping cart button/hyperlink進入Maintain shopping cart畫面
1. 系統顯示購物車內容
a) 顯示採購項目的名稱, 數量，描述, price, item total
2. 使用者修改數量
a) 若數量修改為0表示刪除該項目
3. 使用者執行下列功能
a) Update按鈕更新購物車內容, 執行2.2-更新購物車內容
b) Check out: 執行2.2 更新購物車內容後, 進入UC 6 Checkout
2.1 新增項目
使用者從瀏覽產品的畫面,選擇新增採購項目, 進入此流程
1. 系統增加該品項到購物車, 數量為1
2. 回到主流程(basic flow)
2.2 更新購物車內容
1. 系統更新購物車內容, 如果更新錯誤進入3.1-更新失敗
2. 回到主流程(basic flow)
3. Alternative Flows
3.1 更新失敗
系統回到主流程, 並顯示失敗訊息
a) 使用紅色*提示錯誤的欄位
b) 保留使用者輸入的資料
4. Subflows
5. Key Scenarios
6. Pre-Conditions
1. 執行更新功能時，使用者必需先登入成功
7. Post-Conditions
8. Extension Points
9. Special Requirements
9.1 線上購物每個項目的採購數量最多50
9.2 更新反應時間小於5 seconds
10. Additional Information
10.1 Data definitions
10.2 User Interface prototypes
eStore - UC 4 Maintain Account
1. Abstract
1.1 Feature ID:
1.2 Actors: Customer
1.3 Description: 新增使用者帳戶或修改帳戶資訊
2. Basic Flow of Events: 維護帳戶資訊
1. 系統根據登入狀況，顯示新增或修改的功能
1. 如果使用者未登入, 在Page功能表中顯示Register button
2. 如果使用者已經登入, 在Page功能表中顯示Maintain account button
2. 使用者選擇下列功能
a) 使用者選擇註冊新帳戶(ref 2.1-Register Account)
b) 使用者選擇維護帳戶資料(ref 2-2Maintain Account)
2.1 Register Account
1. 系統顯示註冊畫面
a) 包含Email, password, confirm-password, name, country, address, phone, fax
2. 使用者輸入資料
3. 系統進行新增Account (如果新增失敗，ref 3.1-新增失敗)
4. 系統顯示新增成功訊息，並自動進行登入動作
2.2 Maintain Account
1. 系統顯示維護帳戶資料畫面
a) 顯示登入使用者的資料, 包含Email, name, country, address, phone, fax
b) 密碼欄位不顯示資料, 顯示Change password按鈕
2. 使用者輸入資料，按Update按鈕
a) 如果使用者按Change password按鈕, 則進入流程 2.3-Change Password
3. 系統進行更新資料 (如果更新失敗，ref 3.2更新失敗)
4. 系統顯示更新的結果
2.3 Change Password
1. 系統顯示修改密碼的畫面, 包含new password, confirm new password兩個欄位
2. 使用者輸入資料, 按Confirm按鈕
3. 系統進行更新資料 (如果更新失敗，ref 3.3-修改密碼失敗)
4. 系統顯示更新的結果, 系統返回前一步驟
3. Alternative Flows
3.1 新增失敗
1. 回註冊畫面
2. 系統顯示失敗訊息，使用紅色*提示錯誤的欄位，但保留使用者輸入的資料，清除密碼欄位
3.2 更新失敗
1. 返回維護帳戶資料畫面
2. 系統顯示失敗訊息，使用紅色*提示錯誤的欄位，但保留使用者輸入的資料
3.3 修改密碼失敗
1. 返回修改密碼畫面, 顯示失敗訊息，清除密碼欄位
4. Subflows
5. Key Scenarios
6. Pre-Conditions
6.1 執行維護帳戶資料功能時，使用者必需先登入成功
7. Post-Conditions
7.1 新增帳戶成功後，則自動進行登入, 並回到登入前一網頁
8. Extension Points
9. Special Requirements
9.1 輸入畫面必須檢查輸入資料的格式與正確性
9.2 回應時間不可超過5seconds
10. Additional Information
10.1 Data definitions
10.2 User Interface prototypes
1.1 Feature ID:
1.2 Actors: Customer
1.3 Description: 新增使用者帳戶或修改帳戶資訊
2. Basic Flow of Events: 維護帳戶資訊
1. 系統根據登入狀況，顯示新增或修改的功能
1. 如果使用者未登入, 在Page功能表中顯示Register button
2. 如果使用者已經登入, 在Page功能表中顯示Maintain account button
2. 使用者選擇下列功能
a) 使用者選擇註冊新帳戶(ref 2.1-Register Account)
b) 使用者選擇維護帳戶資料(ref 2-2Maintain Account)
2.1 Register Account
1. 系統顯示註冊畫面
a) 包含Email, password, confirm-password, name, country, address, phone, fax
2. 使用者輸入資料
3. 系統進行新增Account (如果新增失敗，ref 3.1-新增失敗)
4. 系統顯示新增成功訊息，並自動進行登入動作
2.2 Maintain Account
1. 系統顯示維護帳戶資料畫面
a) 顯示登入使用者的資料, 包含Email, name, country, address, phone, fax
b) 密碼欄位不顯示資料, 顯示Change password按鈕
2. 使用者輸入資料，按Update按鈕
a) 如果使用者按Change password按鈕, 則進入流程 2.3-Change Password
3. 系統進行更新資料 (如果更新失敗，ref 3.2更新失敗)
4. 系統顯示更新的結果
2.3 Change Password
1. 系統顯示修改密碼的畫面, 包含new password, confirm new password兩個欄位
2. 使用者輸入資料, 按Confirm按鈕
3. 系統進行更新資料 (如果更新失敗，ref 3.3-修改密碼失敗)
4. 系統顯示更新的結果, 系統返回前一步驟
3. Alternative Flows
3.1 新增失敗
1. 回註冊畫面
2. 系統顯示失敗訊息，使用紅色*提示錯誤的欄位，但保留使用者輸入的資料，清除密碼欄位
3.2 更新失敗
1. 返回維護帳戶資料畫面
2. 系統顯示失敗訊息，使用紅色*提示錯誤的欄位，但保留使用者輸入的資料
3.3 修改密碼失敗
1. 返回修改密碼畫面, 顯示失敗訊息，清除密碼欄位
4. Subflows
5. Key Scenarios
6. Pre-Conditions
6.1 執行維護帳戶資料功能時，使用者必需先登入成功
7. Post-Conditions
7.1 新增帳戶成功後，則自動進行登入, 並回到登入前一網頁
8. Extension Points
9. Special Requirements
9.1 輸入畫面必須檢查輸入資料的格式與正確性
9.2 回應時間不可超過5seconds
10. Additional Information
10.1 Data definitions
10.2 User Interface prototypes
eStore - UC 3 Login
1. Abstract
1.1 Feature ID:
1.2 Actors: Customer
1.3 Description: User logon to the system
2. Basic Flow of Events: 登入網站
使用者未登入網站, 按Login按鈕或要存取secured pages時進入此流程
1. 系統顯示登入畫面
a) 顯示ID, Password欄位 與登入按鈕
2. 使用者輸入id/password, 按登入按鈕
3. 系統進行登入認證
a) 如果登入失敗，ref 3.1-登入失敗
4. 系統顯示使用者欲瀏覽的網頁
a) 如果使用者是按功能表的登入按鈕, 則回到原網頁
b) 如果使用者是要存取secured page時, 被要求登入, 則顯示欲瀏覽的secured page
c) 在page header中, 顯示Welcome {Username}
d) 在Page功能表中, Hide Login button, display logout button
e) 在Page功能表中, Hide Register button, display maintain account button
3. Alternative Flows
3.1 登入失敗
1. 系統回到basic flow的登入畫面，
a) 提示登入失敗訊息
b) 保留使用者輸入的ID
4. Subflows
5. Key Scenarios
6. Pre-Conditions
7. Post-Conditions
8. Extension Points
9. Special Requirements
9.1 每分鐘同時100使用者登入, 回應時間最長5 seconds
10. Additional Information
10.1 Data definitions
10.2 User Interface prototypes
1.1 Feature ID:
1.2 Actors: Customer
1.3 Description: User logon to the system
2. Basic Flow of Events: 登入網站
使用者未登入網站, 按Login按鈕或要存取secured pages時進入此流程
1. 系統顯示登入畫面
a) 顯示ID, Password欄位 與登入按鈕
2. 使用者輸入id/password, 按登入按鈕
3. 系統進行登入認證
a) 如果登入失敗，ref 3.1-登入失敗
4. 系統顯示使用者欲瀏覽的網頁
a) 如果使用者是按功能表的登入按鈕, 則回到原網頁
b) 如果使用者是要存取secured page時, 被要求登入, 則顯示欲瀏覽的secured page
c) 在page header中, 顯示Welcome {Username}
d) 在Page功能表中, Hide Login button, display logout button
e) 在Page功能表中, Hide Register button, display maintain account button
3. Alternative Flows
3.1 登入失敗
1. 系統回到basic flow的登入畫面，
a) 提示登入失敗訊息
b) 保留使用者輸入的ID
4. Subflows
5. Key Scenarios
6. Pre-Conditions
7. Post-Conditions
8. Extension Points
9. Special Requirements
9.1 每分鐘同時100使用者登入, 回應時間最長5 seconds
10. Additional Information
10.1 Data definitions
10.2 User Interface prototypes
eStore - UC 2 Search Product
1. Abstract
1.1 Feature ID:
1.2 Actors: User
1.3 Description: search product by Title, Author, ISBN, Subject
2. Basic Flow of Events
1. 使用者選擇條件種類
a) 搜尋條件的種類：Title, Author, ISBN, Subject,
2. 使用者輸入條件字串, 進行搜尋
3. 系統搜尋產品，顯示產品簡介清單
a) 每個產品顯示: 品名, 價格, 及描述
b) 每個產品旁邊顯示一個Add To Cart 按鈕
c) 如果沒有找到產品, 進入流程-3.1找不到產品
4. 使用者選擇下列功能
a) 點選產品, 查看產品的詳細資訊(ref UC 1-Browse Catalog)
b) 使用者按Add To Cart 按鈕採購產品 (ref UC 5-Maintain Shopping Cart)
3. Alternative Flows
3.1 找不到產品
1. 顯示”沒有商品符合搜索條件”的訊息
4. Subflows
5. Key Scenarios
6. Pre-Conditions
7. Post-Conditions
8. Extension Points
9. Special Requirements
9.1 每分鐘內同時1,000使用者搜索目錄, 回應時間最長8 seconds
10. Additional Information
10.1 Data definitions
10.2 User Interface prototypes
1.1 Feature ID:
1.2 Actors: User
1.3 Description: search product by Title, Author, ISBN, Subject
2. Basic Flow of Events
1. 使用者選擇條件種類
a) 搜尋條件的種類：Title, Author, ISBN, Subject,
2. 使用者輸入條件字串, 進行搜尋
3. 系統搜尋產品，顯示產品簡介清單
a) 每個產品顯示: 品名, 價格, 及描述
b) 每個產品旁邊顯示一個Add To Cart 按鈕
c) 如果沒有找到產品, 進入流程-3.1找不到產品
4. 使用者選擇下列功能
a) 點選產品, 查看產品的詳細資訊(ref UC 1-Browse Catalog)
b) 使用者按Add To Cart 按鈕採購產品 (ref UC 5-Maintain Shopping Cart)
3. Alternative Flows
3.1 找不到產品
1. 顯示”沒有商品符合搜索條件”的訊息
4. Subflows
5. Key Scenarios
6. Pre-Conditions
7. Post-Conditions
8. Extension Points
9. Special Requirements
9.1 每分鐘內同時1,000使用者搜索目錄, 回應時間最長8 seconds
10. Additional Information
10.1 Data definitions
10.2 User Interface prototypes
eStore - UC1 Browse Catalog
1. Abstract
1.1 Feature ID:
1.2 Actors: User
1.3 Description: 瀏覽商品目錄與商品資訊
2. Basic Flow of Events:
1. 使用者開啓首頁
2. 系統顯示商品類別及促銷的商品 (如果沒有促銷商品, ref 3.1-沒有促銷商品)
3. 使用者選擇下列功能
a. 選取次類別 (進入流程 2.1- 顯示類別內的商品清單)
b. 點選促銷商品, 查看商品的詳細資訊 (進入流程2.2 顯示商品詳細資訊)
c. 採購促銷商品 (進入UC5-Maintain Shopping Cart)
2.1 顯示類別內的商品清單
1. 系統顯示商品類別內的促銷商品與商品清單，
a) 顯示每個商品的簡易資訊, 包含品名, 價格, 及描述
b) 如果類別內沒有促銷商品, (ref 3.1-沒有促銷商品)
2. 使用者選擇下列功能
a) 使用者點選商品, 查看商品的詳細資訊 (ref 2.2 顯示商品詳細資訊)
b) 使用者採購商品 ((進入UC5-Maintain Shopping Cart)
2.2 顯示商品詳細資訊
1. 系統顯示下列商品資訊, 如果找不到商品(ref 3.2-找不到商品資訊)
a) 商品編號, 名稱, 價格, 促銷價格, 商品描述, 詳細規格.
2. 使用者採購商品 (進入UC5-Maintain Shopping Cart)
3. Alternative Flows
3.1 沒有促銷商品
1. 系統顯示”目前沒有促銷商品”
3.2 找不到商品資訊
1. 系統顯示”目前沒有商品詳細”
4. Subflows
5. Key Scenarios
6. Pre-Conditions
7. Post-Conditions
8. Extension Points
9. Special Requirements
9.1 每分鐘同時1,000使用者瀏覽目錄, 回應時間5 seconds
10. Additional Information
10.1 Data definitions
10.2 User Interface prototypes
1.1 Feature ID:
1.2 Actors: User
1.3 Description: 瀏覽商品目錄與商品資訊
2. Basic Flow of Events:
1. 使用者開啓首頁
2. 系統顯示商品類別及促銷的商品 (如果沒有促銷商品, ref 3.1-沒有促銷商品)
3. 使用者選擇下列功能
a. 選取次類別 (進入流程 2.1- 顯示類別內的商品清單)
b. 點選促銷商品, 查看商品的詳細資訊 (進入流程2.2 顯示商品詳細資訊)
c. 採購促銷商品 (進入UC5-Maintain Shopping Cart)
2.1 顯示類別內的商品清單
1. 系統顯示商品類別內的促銷商品與商品清單，
a) 顯示每個商品的簡易資訊, 包含品名, 價格, 及描述
b) 如果類別內沒有促銷商品, (ref 3.1-沒有促銷商品)
2. 使用者選擇下列功能
a) 使用者點選商品, 查看商品的詳細資訊 (ref 2.2 顯示商品詳細資訊)
b) 使用者採購商品 ((進入UC5-Maintain Shopping Cart)
2.2 顯示商品詳細資訊
1. 系統顯示下列商品資訊, 如果找不到商品(ref 3.2-找不到商品資訊)
a) 商品編號, 名稱, 價格, 促銷價格, 商品描述, 詳細規格.
2. 使用者採購商品 (進入UC5-Maintain Shopping Cart)
3. Alternative Flows
3.1 沒有促銷商品
1. 系統顯示”目前沒有促銷商品”
3.2 找不到商品資訊
1. 系統顯示”目前沒有商品詳細”
4. Subflows
5. Key Scenarios
6. Pre-Conditions
7. Post-Conditions
8. Extension Points
9. Special Requirements
9.1 每分鐘同時1,000使用者瀏覽目錄, 回應時間5 seconds
10. Additional Information
10.1 Data definitions
10.2 User Interface prototypes
Library online - Use Case
1. Introduction
This document represents a draft use-case summary that would be created early in the lifecycle of the development effort. It is by no means a complete requirements specification, but it represents enough data to get the designers started. In fact a number of the “Manage” use cases that appear in the use-case diagram are not even described herein at all. At this point in time, the application does not fully implement the use cases described here.
2. Glossary
Key terms are denoted in italics within the use-case specifications.
Item - A tangible copy of a Title.
Title - The descriptive identifying information for a book or magazine. Includes attributes like name and description.
Reservation - Whenever a borrower wishes to checkout an Item that is not available due to previous checkout by a different borrower a request can be made (a reservation) that locks the borrower in as the next person able to checkout the Item.
3. Actors
Borrower - Interactive actor who uses the library to search for Titles, make reservations, checkout, and return Items.
Librarian - Interactive actor responsible for maintenance of the inventory, acting on behalf of the borrowers, and general support of the library (non-automated as well).
Master Librarian - Interactive actor, themselves a Librarian, who is also responsible for maintaining the set of librarians for the system.
Registered User - Any interactive user for whom the system maintains a system account. This includes borrowers, librarians, and master librarians. Capabilities include basic login, browsing and searching for Titles.
4. Use Cases
5. Use-Case Specification: Login
5.1 Description
A registered user can log in and, upon verification, can initiate subsequent actions.
5.2 Basic Flow
1. Initiated when a registered user chooses to Login.
2. The system prompts for username and password.
3. The registered user enters a username and password and submits them.
4. The system authenticates the username and password combination.
5. The system authorizes the registered user according to the role(s) to which the registered user has been assigned.
6. The system displays the main page and awaits subsequent action.
5.3 Alternative Flows
5.3.1 Invalid Username/Password
1. The system displays the Authentication Failed message.
5.3.2 Account Locked
1. The system displays the.
5.3.3 Authentication Service Unavailable
1. The system displays a Service Unavailable message and does not permit any further attempts to login.
5.4 Subflows
5.5 Key Scenarios
5.6 Preconditions
None.
5.7 Postconditions
5.7.1 Login Success
The user is considered authenticated and is viewing the main page from which additional actions can be initiated.
5.7.2 Login Failure
If the Login fails as described in any of the alternatives above, an appropriate message is displayed and the user is not considered authenticated.
5.8 Extension Points
5.9 Special Requirements
1. Up to three consecutive failed tries to login with invalid username/password combination until locking an account.
2. Minimum password length is 8 characters, and must include a combination of characters including at least one non-alphabetic character.
5.10 Additional Information
1. So far we are not doing much with roles.
2. The “appropriate message” above is vague; we need to come up with how we report this to the user.
3. We need to talk to security people about how reasonable it is to lock the user account after some number of failed attempts. If we keep that rule, we’ll need an Unlock Account use case.
6. Use-Case Specification: Browse
6.1 Description
A registered user can browse the contents of the library as a precursor to other actions.
6.2 Basic Flow
1. Initiated when a registered user chooses to browse Titles.
2. The system responds by displaying all of the Titles in the system, along with topical descriptions.
3. The registered user selects a Title for further information.
4. The system displays Title detail along with the Items and the available action on each Item.
6.3 Alternative Flows
6.3.1 No records
1. The system displays message indicating no Titles are in the system.
6.4 Subflows
6.5 Key Scenarios
6.6 Preconditions
The user has been authenticated.
6.7 Postconditions
None
6.8 Extension Points
6.9 Special Requirements
6.9.1 The Titles will be sorted alphabetically by the name.
6.10 Additional Information
7. Use-Case Specification: Search
7.1 Description
A registered user can search the contents of the library as a precursor to other actions.
7.2 Basic Flow
1. Initiated when a registered user chooses to perform a search of Titles.
2. The system responds by providing the registered user a means to enter search criteria.
3. The registered user enters search criteria and initiates the query.
4. The system determines results and displays the matching Titles, along with topical descriptions.
5. The registered user selects a Title for further information.
6. The system displays Title detail along with the Items and the available action on each Item.
7.3 Alternative Flows
7.3.1 No matches
1. The system displays message indicating no Titles in the system match this criteria.
7.4 Subflows
7.5 Key Scenarios
7.6 Preconditions
The user has been authenticated.
7.7 Postconditions
None
7.8 Extension Points
7.9 Special Requirements
7.9.1 Search conditions
The search only searches based on the name of the Item, not description or any other field.
7.9.2 Search patterns
The system shall use the percent sign as a wildcard (in keeping with standard SQL idioms).
7.9.3 Sorting rules
The results will be sorted alphabetically by the name.
7.10 Additional Information
8. Use-Case Specification: Make Reservation
8.1 Description
A borrower can reserve an Item that is currently checked out but has no pending reservations.
8.2 Basic Flow
1. Initiated when a borrower chooses to make a reservation for an Item.
2. The system demarks the Item as reserved and associates the borrower with the reservation.
8.3 Alternative Flows
8.4 Subflows
8.5 Key Scenarios
8.6 Preconditions
The borrower is viewing a particular Title with an Item that is not currently available.
8.7 Postconditions
None
8.8 Extension Points
8.9 Special Requirements
8.10 Additional Information
9. Use-Case Specification: Remove Reservation
9.1 Description
A borrower can remove an existing reservation from an Item and free it up for other borrowers.
9.2 Basic Flow
1. Initiated when a borrower chooses to remove a reservation for an Item.
2. The system demarks the Item as no longer reserved.
9.3 Alternative Flows
9.4 Subflows
9.5 Key Scenarios
9.6 Preconditions
The borrower is viewing a particular Title with an Item that is reserved by the borrower.
9.7 Postconditions
None
9.8 Extension Points
9.9 Special Requirements
9.10 Additional Information
10. Use-Case Specification: Checkout Item
10.1 Description
A librarian checkout an available Item when a borrower takes the item out.
10.2 Basic Flow
1. Initiated when a librarian chooses to checkout an Item.
2. The system demarks the Item as checked out to the borrower.
10.3 Alternative Flows
10.4 Subflows
10.5 Key Scenarios
10.6 Preconditions
The borrower is viewing a particular Title with an Item that is currently available.
10.7 Postconditions
10.8 Extension Points
10.9 Special Requirements
10.10 Additional Information
11. Use-Case Specification: Return Item
11.1 Description
The librarian marks an Item as available or reserved when the item is returned.
11.2 Basic Flow
1. Initiated when a borrower chooses to return an Item.
2. The system demarks the Item as available.
11.3 Alternative Flows
11.4 Subflows
11.5 Key Scenarios
11.6 Preconditions
The borrower is viewing a particular Title with an Item that is checked out by the borrower.
11.7 Postconditions
11.7.1 Success condition
The Item is marked as available, or marked as reserved when some borrower had made a reservation on it.
11.8 Extension Point
11.8.1 Notify anyone with a reservation on the Item.
11.9 Special Requirements
11.10 Additional Information
This document represents a draft use-case summary that would be created early in the lifecycle of the development effort. It is by no means a complete requirements specification, but it represents enough data to get the designers started. In fact a number of the “Manage” use cases that appear in the use-case diagram are not even described herein at all. At this point in time, the application does not fully implement the use cases described here.
2. Glossary
Key terms are denoted in italics within the use-case specifications.
Item - A tangible copy of a Title.
Title - The descriptive identifying information for a book or magazine. Includes attributes like name and description.
Reservation - Whenever a borrower wishes to checkout an Item that is not available due to previous checkout by a different borrower a request can be made (a reservation) that locks the borrower in as the next person able to checkout the Item.
3. Actors
Borrower - Interactive actor who uses the library to search for Titles, make reservations, checkout, and return Items.
Librarian - Interactive actor responsible for maintenance of the inventory, acting on behalf of the borrowers, and general support of the library (non-automated as well).
Master Librarian - Interactive actor, themselves a Librarian, who is also responsible for maintaining the set of librarians for the system.
Registered User - Any interactive user for whom the system maintains a system account. This includes borrowers, librarians, and master librarians. Capabilities include basic login, browsing and searching for Titles.
4. Use Cases
5. Use-Case Specification: Login
5.1 Description
A registered user can log in and, upon verification, can initiate subsequent actions.
5.2 Basic Flow
1. Initiated when a registered user chooses to Login.
2. The system prompts for username and password.
3. The registered user enters a username and password and submits them.
4. The system authenticates the username and password combination.
5. The system authorizes the registered user according to the role(s) to which the registered user has been assigned.
6. The system displays the main page and awaits subsequent action.
5.3 Alternative Flows
5.3.1 Invalid Username/Password
1. The system displays the Authentication Failed message.
5.3.2 Account Locked
1. The system displays the
5.3.3 Authentication Service Unavailable
1. The system displays a Service Unavailable message and does not permit any further attempts to login.
5.4 Subflows
5.5 Key Scenarios
5.6 Preconditions
None.
5.7 Postconditions
5.7.1 Login Success
The user is considered authenticated and is viewing the main page from which additional actions can be initiated.
5.7.2 Login Failure
If the Login fails as described in any of the alternatives above, an appropriate message is displayed and the user is not considered authenticated.
5.8 Extension Points
5.9 Special Requirements
1. Up to three consecutive failed tries to login with invalid username/password combination until locking an account.
2. Minimum password length is 8 characters, and must include a combination of characters including at least one non-alphabetic character.
5.10 Additional Information
1. So far we are not doing much with roles.
2. The “appropriate message” above is vague; we need to come up with how we report this to the user.
3. We need to talk to security people about how reasonable it is to lock the user account after some number of failed attempts. If we keep that rule, we’ll need an Unlock Account use case.
6. Use-Case Specification: Browse
6.1 Description
A registered user can browse the contents of the library as a precursor to other actions.
6.2 Basic Flow
1. Initiated when a registered user chooses to browse Titles.
2. The system responds by displaying all of the Titles in the system, along with topical descriptions.
3. The registered user selects a Title for further information.
4. The system displays Title detail along with the Items and the available action on each Item.
6.3 Alternative Flows
6.3.1 No records
1. The system displays message indicating no Titles are in the system.
6.4 Subflows
6.5 Key Scenarios
6.6 Preconditions
The user has been authenticated.
6.7 Postconditions
None
6.8 Extension Points
6.9 Special Requirements
6.9.1 The Titles will be sorted alphabetically by the name.
6.10 Additional Information
7. Use-Case Specification: Search
7.1 Description
A registered user can search the contents of the library as a precursor to other actions.
7.2 Basic Flow
1. Initiated when a registered user chooses to perform a search of Titles.
2. The system responds by providing the registered user a means to enter search criteria.
3. The registered user enters search criteria and initiates the query.
4. The system determines results and displays the matching Titles, along with topical descriptions.
5. The registered user selects a Title for further information.
6. The system displays Title detail along with the Items and the available action on each Item.
7.3 Alternative Flows
7.3.1 No matches
1. The system displays message indicating no Titles in the system match this criteria.
7.4 Subflows
7.5 Key Scenarios
7.6 Preconditions
The user has been authenticated.
7.7 Postconditions
None
7.8 Extension Points
7.9 Special Requirements
7.9.1 Search conditions
The search only searches based on the name of the Item, not description or any other field.
7.9.2 Search patterns
The system shall use the percent sign as a wildcard (in keeping with standard SQL idioms).
7.9.3 Sorting rules
The results will be sorted alphabetically by the name.
7.10 Additional Information
8. Use-Case Specification: Make Reservation
8.1 Description
A borrower can reserve an Item that is currently checked out but has no pending reservations.
8.2 Basic Flow
1. Initiated when a borrower chooses to make a reservation for an Item.
2. The system demarks the Item as reserved and associates the borrower with the reservation.
8.3 Alternative Flows
8.4 Subflows
8.5 Key Scenarios
8.6 Preconditions
The borrower is viewing a particular Title with an Item that is not currently available.
8.7 Postconditions
None
8.8 Extension Points
8.9 Special Requirements
8.10 Additional Information
9. Use-Case Specification: Remove Reservation
9.1 Description
A borrower can remove an existing reservation from an Item and free it up for other borrowers.
9.2 Basic Flow
1. Initiated when a borrower chooses to remove a reservation for an Item.
2. The system demarks the Item as no longer reserved.
9.3 Alternative Flows
9.4 Subflows
9.5 Key Scenarios
9.6 Preconditions
The borrower is viewing a particular Title with an Item that is reserved by the borrower.
9.7 Postconditions
None
9.8 Extension Points
9.9 Special Requirements
9.10 Additional Information
10. Use-Case Specification: Checkout Item
10.1 Description
A librarian checkout an available Item when a borrower takes the item out.
10.2 Basic Flow
1. Initiated when a librarian chooses to checkout an Item.
2. The system demarks the Item as checked out to the borrower.
10.3 Alternative Flows
10.4 Subflows
10.5 Key Scenarios
10.6 Preconditions
The borrower is viewing a particular Title with an Item that is currently available.
10.7 Postconditions
10.8 Extension Points
10.9 Special Requirements
10.10 Additional Information
11. Use-Case Specification: Return Item
11.1 Description
The librarian marks an Item as available or reserved when the item is returned.
11.2 Basic Flow
1. Initiated when a borrower chooses to return an Item.
2. The system demarks the Item as available.
11.3 Alternative Flows
11.4 Subflows
11.5 Key Scenarios
11.6 Preconditions
The borrower is viewing a particular Title with an Item that is checked out by the borrower.
11.7 Postconditions
11.7.1 Success condition
The Item is marked as available, or marked as reserved when some borrower had made a reservation on it.
11.8 Extension Point
11.8.1 Notify anyone with a reservation on the Item.
11.9 Special Requirements
11.10 Additional Information
訂閱：
文章 (Atom)
