A. 如何寫網站建設需求說明書
一個網站項目的確立是建立在各種各樣的需求上面的，這種需求往往來自於客戶的實際需求或者是出於公司自身發展的需要，其中客戶的實際需求也就是說這種交易 性質的需求佔了絕大部分。面對對網站開發擁有不同知識層面的客戶，項目的負責人對用戶需求的理解程度，在很大程度上決定了此類網站開發項目的成敗。因此如 何更好地的了解、分析、明確用戶需求，並且能夠准確、清晰以文檔的形式表達給參與項目開發的每個成員，保證開發過程按照滿足用戶需求為目的正確項目開發方 向進行，是每個網站開發項目管理者需要面對的問題。就這個問題，本文想提出自己的一些看法和建議，希望各位讀者批評指正： 一、 那些人應該參與網站開發項目的需求分析活動需求分析活動其實本來就是一個和客戶交流，正確引導客 戶能夠將自己的實際需求用較為適當的技術語言進行表達（或者由相關技術人員幫助表達）以明確項目目的的過程。這個過程中也同時包含了對要建立的網站基本功 能和模塊的確立和策劃活動。所以項目小組每個成員、客戶甚至是開發方的部門經理（根據項目大小而定）的參與是必要的。而項目的管理者在需求分析中的職責有 如下幾個方面：1、 負責組織相關開發人員與用戶一起進行需求分析。2、 組織美術和技術骨幹代表或者全部成員（與用戶討論）編寫《網站功能描述書（初稿）》文檔。3、 組織相關人員對《網站功能描述書（初稿）》進行反復討論和修改，確定《網站功能描述書》正式文檔。4、 如果用戶有這方面的能力或者用戶提出要求，項目管理者也可以指派項目成員參與，而由用戶編寫和確定《網站功能描述書》文檔。5、 如果項目比較大的話，最好能夠有部門經理或者他授權的人員參與到《網站功能描述書》的確定過程中來。二、 完整的需求調查文檔記錄體系在整個需求分析的過程中，將按照一定規范的編寫需求分析的相關文檔不但可以幫助項目成員將需求分析結果更加明確化，也為以後開發過程中做到了現實文本形式的備忘，並且有助於公司日後的開發項目提供有益的借鑒和模範，成為公司在項目開發中積累的符合自身特點的經驗財富。 需求分析中需要編寫的文檔主要是《網站功能描述書》，他基本上是整個需求分析活動的結果性文檔，也是開發工程中項目成員主要可供參考的文檔。為了更加清 楚的描述《網站功能描述書》往往還需要編寫《用戶調查報告》和《市場調研報告》文檔來輔助說明。各種文檔最好有一定的規范和固定格式，以便增加其可閱讀性 和方便閱讀者快速理解文檔內容，相關規定將在本文後面討論。三、 向用戶調查些什麼在需求分析的工程中，往往有很多不明確的用戶需求，這個時候項目負責人 需要調查用戶的實際情況，明確用戶需求。一個比較理想化的用戶調查活動需要用戶的充分配合，而且還有可能需要對調查對象進行必要的培訓。所以調查的計劃安 排：時間、地點、參加人員、調查內容，都需要項目負責人和用戶的共同認可。調查的形式可以是：發需求調查表、開需求調查座談會或者現場調研。調查的內容主 要如下：1、 網站當前以及日後可能出現的功能需求。2、 客戶對網站的性能（如訪問速度）的要求和可靠性的要求。3、 確定網站維護的要求。4、 網站的實際運行環境。5、 網站頁面總體風格以及美工效果（必要的時候用戶可以提供參考站點或者由公司向用戶提供）。6、 主頁面和次級頁面數量，是否需要多種語言版本等7、 內容管理及錄入任務的分配。8、 各種頁面特殊效果及其數量（js,flash等）9、 項目完成時間及進度（可以根據合同）10、明確項目完成後的維護責任。調查結束以後，需要編寫《用戶調查報告》，《報告》的要點是：1、 調查概要說明：網站項目的名稱；用戶單位；參與調查人員；調查開始終止的時間；調查的工作安排。2、 調查內容說明：用戶的基本情況；用戶的主要業務；信息化建設現狀；網站當前和將來潛在的功能需求、性能需求、可靠性需求、實際運行環境；用戶對新網站的期望等。3、 調查資料匯編：將調查得到的資料分類匯總（如調查問卷，會議記錄等等）。四、 市場調研活動內容通過市場調研活動，清晰的分析相似網站的性能和運行情況。可以幫助項目負責人更加清楚的構想出自己開發的網站的大體架構和模樣，在總結同類網站優勢和缺點的同時項目開發人員可以博採眾長開發出更加優秀的網站。 但是由於實際中時間、經費、公司能力所限，市場調研覆蓋的范圍有一定的局限性，在調研市場同類網站的時候，應盡可能調研到所有比較出名和優秀的同類網 站。應該了解同類網站的使用環境與用戶的詫異點、類似點，同類產品所定義的用戶詳細需求（需要公司或者項目負責人有一定的關系）。市場調研的重點應該放在 主要競爭對手的作品或類似網站作品的有關信息上。市場調研可以包括下列內容：1、 市場中同類網站作品的確定。2、 調研作品的使用范圍和訪問人群。3、 調研產品的功能設計（主要模塊構成，特色功能，性能情況等等）4、 簡單評價所調研的網站情況。調研的目的是明確並且引導用戶需求。對市場同類產品調研結束後，應該撰寫《市場調研報告》主要包括一下要點：1、 調研概要說明：調研計劃；網站項目名稱、調研單位、參與調研、調研開始終止時間。2、 調研內容說明：調研的同類網站作品名稱、網址、設計公司、網站相關說明、開發背景、主要適用訪問對象、功能描述、評價等3、 可採用借鑒的調研網站的功能設計：功能描述、用戶界面、性能需求、可採用的原因。4、 不可採用借鑒的調研網站的功能設計：功能描述、用戶界面、性能需求、不可採用的原因。5、 分析同類網站作品和主要競爭對手產品的弱點和缺陷以及本公司產品在這些方面的優勢。6、 調研資料匯編：將調研得到的資料進行分類匯總。
五、 清晰的需求分析輸出——《網站功能描述書》 在擁有前期公司和客戶簽訂的合同或者是標書的約束之下，通過較為詳細具體的用戶調查和市場調研活動，借鑒其輸出的《用戶調查報告》和《市場調研報告》文 檔，項目負責人應該對整個需求分析活動進行認真的總結，將分析前期不明確的需求逐一明確清晰化，並輸出一份詳細清晰的總結性文檔──《網站功能描述書（最 終版）》以供作為日後項目開發過程中的依據。《網站功能描述書》必須包含以下內容：1、 網站功能2、 網站用戶界面（初步）3、 網站運行的軟硬體環境4、 網站系統性能定義5、 網站系統的軟體和硬體介面6、 確定網站維護的要求7、 確定網站系統空間租賃要求8、 網站頁面總體風格及美工效果。9、 主頁面及次頁面大概數量。10、管理及內容錄入任務分配。11、各種頁面特殊效果及其數量。12、項目完成時間及進度（根據合同）13、明確項目完成後的維護責任。綜上所述，在網站項目的需求分析中主要是由項目負責人來確定對用戶需求的理解程度，而用戶調查和市場調研等需求分析活動的目的就是幫助項目負責人加深對用戶需求的理解和對前期不明確的地方進行明確化，以便於日後在項目開發過程中作為開發成員的依據和借鑒。
當然一次成功的需求分析不僅需要項目負責人甚至是客戶等所有項目相關人員的共同努力，還和公司的能力范圍有一定關系。需要說明的是本文所述的需求分析活 動內容是建立在較為理想的基礎上的。由於各個公司現實情況的不同，讀者可以根據自身情況不一借鑒吸收利用。重要的是能構根據本公司的情況，系統的規范此類 文檔做好保存和收集，相信對公司以後其他網站項目的進行以及公司自身實力的增強都會有很大幫助。
星想互聯 http://www.hbxnseo.com，一個專門從事網站建設與seo優化推廣網 http://www.hbxnseo.com/a/wangzhanjianshe/2011/0317/177.html
功能與現實中超市裡的購物車差不多,看到中意的商品,點擊"購買該商品"之類的鏈接,它就被放進購物車了,之後可以按此法繼續購物.最後一並結帳.當然,在沒付款之前,隨時可以把不想要的商品挪出購物車:)
C. 國內一家大型購物網站會定時清空購物車，簡要分析為什麼
實際上這是一個減庫存的功能性問題，並不是誘導購買的情感性問題。減庫存有三種方式。分別是：拍下減庫存、付款減庫存、放進購物車減庫存。每種減庫存方式都有其特定的使用場景
1、拍下減庫存：顧名思義就是拍下後、無論消費者是否付款，都會把庫存減掉。如果商家出售的寶貝只剩最後一件，被消費者拍下之後沒能及時付款，那別的消費者在這個店裡就買不了這個商品了。拍下減庫存的方案無法規避商品惡意被拍的風險。如果商家的商品大量被拍下，但一直未付款，就會造成別的消費者無法購買。前幾年淘寶中小商家大鬧天貓，狂刷韓都衣舍等大店就是這樣，瘋狂拍下商品，造成韓都衣舍大量商品庫存為零被迫下架，導致大量需要正常消費者無法購買。
2、付款減庫存：付款減庫存的意思是，消費者沒成功付款之前，不會減庫存，也就是說任何別的消費者都能繼續拍下剩餘庫存的商品。直到消費者付款成功，才會減掉相應的庫存。「付款減庫存」會在消費者成功付款後，商品的庫存數量才會相應減少，所以會導致超賣，尤其是在促銷的時候會非常明顯。
舉個栗子，某個商家在做櫻桃促銷，共100箱庫存，上了活動促銷後，消費者在一個小時內一共拍下了106箱，這個時候，這100箱櫻桃顯然不夠賣給106個消費者了。誰先付款就發給誰，剩下的不管？顯然不行。
3、放進進購物車減庫存：「添加進購物車減庫存」實際上是「拍下減庫存」的衍生出來的新方式，本質上依然是拍下減庫存，特點是將減庫存鎖定時間縮短，加快了流動速度。
比如唯品會這類特賣網站，一個特賣活動很可能只有3小時，如果還按照淘寶的做法「拍下後減庫存，72小時內不成交，系統才自動關閉交易」，顯然不可取，因為整個特賣活動可能也就3小時呀。
特賣的時候大量消費者同一時間湧入，如果消費者拍下後，給很長的思考時間是否購買，特賣根本沒法玩，所以得給拍下減庫存增加更敏感的時間限制。也就是說，為了加快流動，需要增加自動清空購物車功能，盡可能的將庫存更快的釋放出來，一方面可以給真正需要購買的消費者，另一方面帶來了大家說的催促購買。
這一場景就是要買趕緊，不買趕緊拉倒，系統加快自動把你踢出，把商品趕緊讓給真正想買的消費者。盡快結束這個活動（相比淘寶的72小時）。因為還有千千萬萬個特賣活動等著上線啊。
在這個過程中，現在你感受到了吧，根本原因是為了處理庫存問題，當然，自然而然的就帶來了其它答案所說的「造成緊迫感、引誘消費者快速下單」等情感引導能力。這里千萬別本末倒置，不是為了情感需求而設計庫存，而且真的為了處理庫存問題帶來了情感引導。這很重要，舉個栗子，設計uber是為了打車，而不是約炮。約炮是自然而然帶來的附屬情感能力。如果一開始就奔著設計約炮的目的去設計uber，得到的結果就不是這樣啦。
D. 第二章 系統框架 2.1 網路架構 2.2 系統架構 2.3模塊功能說明 怎麼寫
目錄如下：
第1章 蜀玉網路購物商城 1
1.1 概述 2
1.2 系統分析 2
1.2.1 需求分析 2
1.2.2 可行性分析 2
1.3 總體設計 3
1.3.1 項目規劃 3
1.3.2 系統功能結構圖 3
1.4 系統設計 4
1.4.1 設計目標 4
1.4.2 開發及運行環境 4
1.4.3 邏輯結構設計 5
1.5 技術准備 9
1.5.1 MVC概述 9
1.5.2 Struts概述 10
1.5.3 在MyEclipse中配置應用Struts結構文件 12
1.6 系統架構設計 13
1.6.1 系統文件夾架構圖 13
1.6.2 文件架構設計 14
1.7 JavaBean的設計 15
1.7.1 資料庫連接的JavaBean的編寫 15
1.7.2 設置系統中使用的SQL語句的JavaBean 15
1.7.3 解決Struts中文亂碼問題 16
1.7.4 檢查用戶是否已經在線的公共類 16
1.8 會員管理模塊 18
1.8.1 會員登錄 18
1.8.2 用戶注冊 21
1.8.3 找回密碼 23
1.9 網站主頁設計 25
1.9.1 網站首頁面導航信息版塊 26
1.9.2 網站首頁面左部信息版塊 27
1.9.3 網站首頁面右部信息版塊 27
1.9.4 網站首頁面版權信息版塊 28
1.10 會員資料修改模塊 28
1.11 購物車模塊 30
1.11.1 添加購物車 30
1.11.2 查看購物車 32
1.11.3 生成訂單 34
1.11.4 清空購物車 35
1.12 商品銷售排行模塊 35
1.12.1 商品銷售排行榜 36
1.12.2 分頁顯示特價商品 37
1.13 網站後台主要功能模塊設計 39
1.13.1 網站後台首頁設計 39
1.13.2 後台管理員身份驗證模塊 40
1.13.3 商品設置模塊 41
1.13.4 訂單設置模塊 45
1.13.5 公告設置模塊 46
1.14 退出模塊 48
1.15 疑難問題分析 48
1.15.1 中文亂碼問題的處理 48
1.15.2 關閉網站後session沒有被注銷 49
第2章 博客網站 50
2.1 概述 51
2.2 系統分析 51
2.2.1 需求分析 51
2.2.2 可行性分析 51
2.3 總體設計 51
2.3.1 項目規劃 51
2.3.2 系統功能結構圖 52
2.4 系統設計 52
2.4.1 設計目標 52
2.4.2 開發及運行環境 53
2.4.3 邏輯結構設計 53
2.5 技術准備 55
2.5.1 Hibernate框架概述 55
2.5.2 Hibernate配置文件 55
2.5.3 創建持久化類 56
2.5.4 Hibernate映射文件 57
2.6 系統構架設計 57
2.6.1 系統文件夾架構圖 57
2.6.2 文件夾架構設計 58
2.7 公共類設計 58
2.7.1 獲得當前系統時間類 58
2.7.2 字元處理類的編寫 59
2.7.3 將字元串轉化成字元數組類 60
2.7.4 Hibernate的初始化與Session管理類的編寫 60
2.8 網站前台主要功能設計 61
2.8.1 網站首頁頁面設計 61
2.8.2 網站計數功能實現 62
2.8.3 網路日歷功能 62
2.8.4 博主信息顯示模塊 64
2.8.5 瀏覽博主發表文章模塊 66
2.8.6 添加評論模塊 70
2.9 網站後台主要功能模塊設計 72
2.9.1 後台首頁設計 74
2.9.2 博客文章管理模塊 74
2.9.3 個人相片設置模塊 83
2.9.4 博主設置模塊 89
2.10 疑難問題分析 91
2.10.1 Hibernate的映射類型 91
2.10.2 如何使用Hibernate聲明事務邊界 92
2.11 程序調試與錯誤處理 92
第3章 圖書館管理系統 94
3.1 概述 95
3.2 系統分析 95
3.2.1 需求分析 95
3.2.2 可行性分析 95
3.3 總體設計 95
3.3.1 項目規劃 95
3.3.2 系統功能結構圖 96
3.4 系統設計 96
3.4.1 設計目標 96
3.4.2 開發及運行環境 97
3.4.3 邏輯結構設計 97
3.5 技術准備 101
3.5.1 利用MySQL創建、刪除資料庫及數據表 101
3.5.2 查看、修改數據表結構及重命名數據表 102
3.6 系統總體架構 103
3.6.1 文件夾架構 103
3.6.2 文件架構 103
3.6.3 網站首頁架構 104
3.7 配置Struts 105
3.8 工具類的編寫 106
3.8.1 資料庫連接及操作類的編寫 106
3.8.2 字元串處理類的編寫 109
3.9 管理員功能模塊 110
3.9.1 管理員功能模塊總體架構 110
3.9.2 定義管理員的ActionForm實現類 110
3.9.3 創建管理員的Action實現類 111
3.9.4 系統登錄設計 112
3.9.5 查看管理員列表設計 115
3.9.6 添加管理員信息設計 118
3.9.7 設置管理員許可權設計 121
3.9.8 刪除管理員設計 124
3.10 圖書檔案管理功能模塊設計 125
3.10.1 圖書檔案管理功能模塊總體架構 125
3.10.2 定義圖書檔案的ActionForm實現類 125
3.10.3 創建圖書檔案的Action實現類 126
3.10.4 查看圖書信息列表設計 127
3.10.5 添加圖書信息設計 129
3.10.6 修改圖書信息設計 131
3.10.7 刪除圖書信息設計 132
3.11 圖書借還管理功能模塊設計 133
3.11.1 圖書借還管理功能模塊總體架構 133
3.11.2 定義圖書借還管理的ActionForm實現類 134
3.11.3 創建圖書借還管理的Action實現類 134
3.11.4 圖書借閱設計 135
3.11.5 圖書歸還設計 138
3.11.6 圖書借閱查詢設計 140
3.11.7 借閱到期提醒設計 143
3.11.8 圖書借閱排行榜設計 145
3.12 疑難問題分析與解決 146
3.12.1 如何自動計算圖書歸還日期 146
3.12.2 如何對圖書借閱信息進行統計排行 147
第4章 醫葯進銷存管理系統 148
4.1 概述 149
4.2 系統分析 149
4.2.1 需求分析 149
4.2.2 可行性分析 149
4.3 總體設計 149
4.3.1 項目規劃 149
4.3.2 系統功能結構圖 150
4.4 系統設計 150
4.4.1 設計目標 150
4.4.2 開發及運行環境 150
4.4.3 資料庫設計 151
4.5 技術准備 154
4.5.1 Spring框架 154
4.5.2 Hibernate框架 155
4.6 系統總體架構設計 156
4.6.1 文件架構設計 156
4.6.2 系統架構設計 156
4.7 系統公共類設計 157
4.7.1 編寫訪問資料庫的DAO類 157
4.7.2 編寫DAO的代理操作類AdapterDao 159
4.7.3 編寫Spring的配置文件appcontext.xml 160
4.7.4 編寫處理菜單欄和工具欄按鈕的公共類MenuBarEvent 161
4.7.5 編寫生成表格模型的公共類BuildTable 162
4.8 Java實體類及Hibernate映射文件的設計 163
4.8.1 葯品信息的實體類obj_medicine 163
4.8.2 實體類obj_medicine.java的映射文件 164
4.9 系統主要功能模塊設計 164
4.9.1 系統登錄模塊 164
4.9.2 主界面設計 167
4.9.3 葯品基本情況模塊 170
4.9.4 葯品采購模塊 175
4.9.5 庫存檔點模塊 180
4.9.6 銷售退貨模塊 182
4.9.7 入庫明細查詢模塊 185
4.9.8 用戶維護功能模塊 189
4.10 疑難問題解析 191
4.10.1 配置Spring訪問資料庫文件 191
4.10.2 在Hibernate中利用關聯關系操縱實體對象 192
4.11 系統常見錯誤處理 193
4.11.1 通過Spring框架連接資料庫 193
4.11.2 配置sessionFactory會話文件 194
4.11.3 配置Hibernate映射文件 195
第5章 銷售管理系統 196
5.1 概述 197
5.2 系統分析 197
5.2.1 需求分析 197
5.2.2 可行性分析 197
5.3 總體設計 197
5.3.1 項目規劃 197
5.3.2 系統功能結構圖 198
5.4 系統設計 198
5.4.1 設計目標 198
5.4.2 開發及運行環境 198
5.4.3 邏輯結構設計 199
5.5 技術准備 201
5.5.1 命名規則 201
5.5.2 Servlet簡介 202
5.5.3 Servlet的生命周期 203
5.5.4 載入和實例化Servlet 204
5.5.5 初始化Servlet 204
5.5.6 請求處理 204
5.5.7 Servlet的終結與卸載 204
5.6 系統架構設計 205
5.6.1 系統文件夾架構圖 205
5.6.2 文件架構設計 205
5.6.3 類的分布架構設計 206
5.7 工具類的設計與實現 207
5.7.1 資料庫連接類的設計與實現 207
5.7.2 字元串處理類的設計與實現 208
5.7.3 保存當前登錄員工信息類的實現方法 209
5.7.4 監聽當前登錄員工的方法 209
5.8 員工操作模塊的設計與實現 210
5.8.1 對資料庫中表取值和賦值的方法 210
5.8.2 員工登錄的實現 212
5.8.3 員工注冊的實現 216
5.8.4 員工許可權的實現 218
5.8.5 分頁的實現 223
5.9 基礎信息設置模塊的設計與實現 226
5.9.1 職務信息查詢的實現 227
5.9.2 職務信息添加的實現 228
5.9.3 職務信息修改的實現 229
5.9.4 職務信息刪除的實現 230
5.10 業務管理模塊的設計與實現 230
5.10.1 樣式層的代碼列表 231
5.10.2 訂貨信息的添加 231
5.10.3 出貨信息的添加 233
5.10.4 退貨信息的添加 234
5.11 疑難問題解析 236
5.11.1 java.lang.NullPointerException異常 236
5.11.2 JSP區分大小寫 236
5.11.3 未被初始化錯誤 236
第6章 酒店管理系統 237
6.1 概述 238
6.2 系統分析 238
6.2.1 需求分析 238
6.2.2 可行性分析 238
6.3 總體設計 239
6.3.1 項目規劃 239
6.3.2 系統功能結構圖 239
6.4 系統設計 239
6.4.1 設計目標 239
6.4.2 開發及運行環境 240
6.4.3 邏輯結構設計 240
6.5 技術准備 242
6.5.1 重新定義表格 242
6.5.2 創建支持行標題欄的表格 243
6.5.3 創建日期選擇框 246
6.6 系統架構設計 251
6.6.1 系統文件夾架構圖 251
6.6.2 文件架構設計 252
6.7 數據持久層設計 252
6.7.1 編寫資料庫連接類 252
6.7.2 編寫操作資料庫的方法 253
6.8 主窗體的格局設計 255
6.9 開台簽單功能的設計與實現 257
6.9.1 開台與查看 257
6.9.2 點菜與簽單 259
6.10 自動結賬功能的設計與實現 263
6.11 銷售統計功能的設計與實現 265
6.11.1 日銷售統計 265
6.11.2 月銷售統計 266
6.11.3 年銷售統計 267
6.12 人員管理功能的設計與實現 268
6.12.1 員工檔案管理 268
6.12.2 系統管理員管理 270
6.13 系統維護功能的設計與實現 271
6.13.1 台號管理 271
6.13.2 菜系管理 273
6.13.3 菜品管理 274
6.14 系統安全功能的設計與實現 276
6.14.1 系統的鎖定與解除 276
6.14.2 安全退出系統 278
6.15 疑難問題分析 278
6.15.1 如何彈出菜單 278
6.15.2 如何實現時鍾 279
第7章 學生成績管理系統 281
7.1 概述 282
7.2 系統分析 282
7.2.1 需求分析 282
7.2.2 可行性分析 282
7.3 總體設計 282
7.3.1 項目規劃 282
7.3.2 系統功能結構圖 283
7.4 系統設計 283
7.4.1 設計目標 283
7.4.2 開發及運行環境 283
7.4.3 邏輯結構設計 283
7.5 技術准備 285
7.5.1 通過Swing組件開發系統窗體界面 285
7.5.2 通過JDBC訪問SQL Server 2000資料庫 286
7.5.3 批處理 287
7.5.4 ResultSetMetaData類的介紹 287
7.6 系統架構設計 288
7.6.1 系統文件夾架構圖 288
7.6.2 文件架構設計 288
7.7 系統實體對象與公共類設計 288
7.7.1 各種實體類的編寫 289
7.7.2 操作資料庫公共類的編寫 289
7.8 登錄模塊 295
7.9 系統主窗體設計 297
7.10 系統主要模塊設計 299
7.10.1 班級信息設置模塊設計 299
7.10.2 學生基本信息管理模塊設計 301
7.10.3 學生考試成績信息管理模塊設計 304
7.10.4 基本信息數據查詢模塊設計 308
7.10.5 學生考試成績明細查詢模塊設計 310
7.11 疑難問題分析 313
7.11.1 批處理操作學生成績表 313
7.11.2 生成動態列的查詢語句 314
第8章 企業QQ 315
8.1 概述 316
8.2 系統分析 316
8.2.1 需求分析 316
8.2.2 可行性分析 316
8.3 總體設計 316
8.3.1 項目規劃 316
8.3.2 系統功能結構圖 317
8.4 系統設計 317
8.4.1 設計目標 317
8.4.2 開發及運行環境 317
8.4.3 資料庫設計 318
8.5 技術准備 318
8.5.1 Java系統托盤 318
8.5.2 嵌入式連接JavaDB資料庫 319
8.6 系統總體架構設計 319
8.6.1 文件架構設計 319
8.6.2 系統架構設計 320
8.7 系統公共類設計 320
8.7.1 編寫訪問資料庫的DAO類 320
8.7.2 編寫代碼創建系統托盤 323
8.7.3 編寫系統工具類 325
8.8 系統主要功能模塊設計 329
8.8.1 主窗體設計 329
8.8.2 用戶列表模塊 334
8.8.3 用戶通信模塊 338
8.8.4 系統工具模塊 343
8.8.5 系統設置模塊 347
8.9 疑難問題解析 350
8.9.1 程序埠被佔用 350
8.9.2 發送信使信息 351
可以看出，他使用了現在比較滸的框架：hibernate,Struts1,但是是否使用Structs2,我也不知道
E. Android APP開發需求文檔範本
軟體需求文檔格式的標准寫法
1．引言
1．1 編寫目的
· 闡明開發本軟體的目的；
1．2 項目背景
· 標識待開發軟體產品的名稱、代碼；
· 列出本項目的任務提出者、項目負責人、系統分析員、系統設計員、程序設計員、程序員、資料員以及與本項目開展工作直接有關的人員和用戶；
· 說明該軟體產品與其他有關軟體產品的相互關系。
1．3 術語說明
列出本文檔中所用到的專門術語的定義和英文縮寫詞的原文。
1．4 參考資料（可有可無）
列舉編寫軟體需求規格說明時所參考的資料，包括項目經核準的計劃任務書、合
同、引用的標准和規范、項目開發計劃、需求規格說明、使用實例文檔，以及相關產品
的軟體需求規格說明。
在這里應該給出詳細的信息，包括標題、作者、版本號、發表日期、出版單位或資
料來源。
2．項目概述
2．1 待開發軟體的一般描述
描述待開發軟體的背景，所應達到的目標，以及市場前景等。
2．2 待開發軟體的功能
簡述待開發軟體所具有的主要功能。為了幫助每個讀者易於理解，可以使用列表或
圖形的方法進行描述。使用圖形表示，可以採用：
· 頂層數據流圖；
· 用例UseCase圖；
· 系統流程圖；
· 層次方框圖。
2．3 用戶特徵和水平（是哪類人使用）
描述最終用戶應具有的受教育水平、工作經驗及技術專長。
2．4 運行環境
描述軟體的運行環境，包括硬體平台、硬體要求、操作系統和版本，以及其他的軟
件或與其共存的應用程序等。
2．5 條件與限制
給出影響開發人員在設計軟體時的約束條款，例如：
· 必須使用或避免使用的特定技術、工具、編程語言和資料庫；
· 硬體限制；
· 所要求的開發規范或標准。
3．功能需求
3．1 功能劃分
列舉出所開發的軟體能實現的全部功能，可採用文字、圖表或數學公式等多種方法
進行描述。
3．2 功能描述
對各個功能進行詳細的描述。
4．外部介面需求
4．1 用戶界面
對用戶希望該軟體所具有的界面特徵進行描述。以下是可能要包括的一些特徵：
· 將要採用的圖形用戶界面標准或產品系列的風格；
· 屏幕布局；
· 菜單布局；
· 輸入輸出格式；
· 錯誤信息顯示格式；
建議採用RAD開發工具， 比如Visio，構造用戶界面。
4．2 硬體介面
描述系統中軟體產品和硬體設備每一介面的特徵，以及硬體介面支持的設備、軟體與硬體介面之間，以及硬體介面與支持設備之間的約定，包括交流的數據和控制信息的性質以及所使用的通信協議。
4．3 軟體介面
描述該軟體產品與其有關軟體的介面關系，並指出這些外部軟體或組件的名字和版本號。比如運行在什麼操作系統上，訪問何種類型的資料庫，使用什麼資料庫連接組件，和什麼商業軟體共享數據等。
4．4 通信介面
描述和本軟體產品相關的各種通信需求，包括電子郵件、Web瀏覽器、網路通信協議等。
4．5 故障處理
對可能的軟體、硬體故障以及對各項性能而言所產生的後果進行處理。
5．性能需求
5．1 數據精確度
輸出結果的精度。
5．2 時間特性
時間特性可包括如下幾方面
·響應時間；
·更新處理時間；
·數據轉換與傳輸時間；
·運行時間等。
5．3 適應性
在操作方式、運行環境、與其他軟體的介面以及開發計劃等發生變化時，軟體的適應能力。
6．其他需求
列出在本文的其他部分未出現的需求。如果不需要增加其他需求，可省略這一部分。
7．數據描述
7．1 靜態數據
7．2 動態數據
包括輸入數據和輸出數據。
7．3 資料庫描述
給出使用資料庫的名稱和類型。
7．4 數據字典
對於數據流圖、層次方框圖中出現的所有圖形元素在數據字典中都要作為一個詞條加以定義，使得每一個圖形元素都有唯一的一個清晰明確的解釋。
數據字典中所有的定義必須是嚴密的、精確的，不可有二意性。
7．5 數據採集
·列出提供輸入數據的機構、設備和人員
·列出數據輸入的手段、介質和設備；
·列出數據生成的方法、介質和設備。
8．附錄
包括分析模型，待定問題圖表等。
F. 關於帶有支付介面購物車等功能的網站需求分析
購物網站，到建鵲互聯 找客服要一份就可以了
G. 類似網上購物管理系統需求分析（比如鮮花）
ASP網上購物系統
需求說明
文件名稱：概要設計說明書
文件編號： QDHYASP1001
編 制 人： 周峰
編制日期：2005年 8月 30日
審 核 人： 周峰
版本標識：2.50版
1.引言
1.1.編寫目的
編寫此需求分析報告，實現商場、中小企業或個人在互聯網上進行新產品展示，網上通信留言功能，重點實現網上商品的查找、在線購買功能。實現普通用戶只能瀏覽，注冊用戶可以在線定購，後台管理人員可以進行產品上傳更新、注冊用戶的管理等功能。
1.2.項目背景
項目名稱：ASP網上購物系統
項目委託單位： hyst105040701
項目開發單位：040701班
項目簡介：本系統主要實現網上產品展示與在線定購及人員的管理，一、不同身份有不同的許可權功能（管理人員、注冊用戶、遊客） 二、在線產品展示（分頁顯示） 三、在線定購 四、後台管理（用戶管理、商品的管理）
（本系統為040701班的畢業設計項目）
1.3.問題陳述
對用戶提供的服務有：
l 在線產品展示
l 在線查找功能
l 在線下訂單。
l
2.任務概述
2.1.需求概述
2.1.1.在線展示
只要登錄到網站後，就可以在線瀏覽展示商品，
最新商品動畫展示
在線購買商品從後台資料庫動態顯示商品圖片與產品名。
單擊產品名或圖片就看到產品的詳細介紹。要添加購買與收藏功能。
2.1.2.在線下訂單：
只有注冊用戶才能利用該系統下訂單。注冊後並且處於激活狀態才可以購物下訂單。非注冊用戶和處於非激活狀態的用戶，只能瀏覽商品的基本情況。用戶登錄後，就可以使用系統提供的各種功能。
單擊產品對應的購買按鈕後，要顯示購物車界面，在該界面中要實現購買產品數量統計、總價格統計及每種產品的購買時間。
在購物車中，可以實現繼續購買、產品數量的修改、刪除購買物品、到收銀台付款功能。
在信息填寫與提交中，要實現「返回上一步」修改功能，實現所以信息統計界面。實現產生訂購單號功能。
2.1.3後台管理服務
管理員修改功能
商品管理功能
會員管理功能
2.1.4留言功能
2.2.運行環境
伺服器端： ASP+SQLSERVER2000+IIS 5.0
客戶端： IE瀏覽器
2.3.開發環境
SQLServer資料庫+IIS5.0+Windows2000+Dreamweaver2004
2.5.限制和約束
l 一個客戶在系統中只有一個賬號。
l 客戶要想購物必須先登陸。
l 管理員只能進行三次登錄
3.總體設計
3.1.參與者(不同使用身份)