『壹』 做軟體項目設計文檔怎麼寫啊
按照以下格式填就好了，不過是我自己寫的，有不好的地方大家互相學習修改一下~
詳細設計文檔規范
1.0概述
這部分提供對整個設計文檔的概述。描述了所有數據，結構，介面和軟體構件級別的設計。
1.1 目標和對象
描述軟體對象的所有目標。
1.2 陳述范圍
軟體描述。主要輸入，過程功能，輸出的描述，不考慮詳細細節。
1.3 軟體內容
軟體被置於商業或者產品線中，討論相關的戰略問題。目的是讓讀者能夠對「宏圖」有所了解。
1.4 主要系統參數
任何商務軟體或者產品線都包含軟體規定、設計、實現和測試的說明和規范。
2.0 數據設計
描述所有數據結構包括內部變數，全局變數和臨時數據結構。
2.1 內部軟體數據結構
描述軟體內部的構件之間的數據傳輸的結構。
2.2 全局數據結構
描述主要部分的數據結構。
2.3 臨時數據結構
為臨時應用而生成的文件的描述。
2.4 資料庫描述
作為應用程序的一部分，描述資料庫結構。
3.0 結構化和構件級別設計
描述程序結構。
3.1 程序結構
詳細描述應用程序所選定的程序結構。
3.1.1 結構圖
圖形化描述結構。
3.1.2 選擇性
討論其它可供考慮的結構。選定3.1.1中結構類型的原因。
3.2 構件描述
詳細描述結構中的每個軟體構件。
3.2.1 構件過程敘述(PSPEC)
描述構件的過程。
3.2.2 構件介面描述
詳細描述構件的輸入和輸出。
3.2.3 構件執行細節
每個構件的詳細演算描述。
3.2.3.1 介面描述
3.2.3.2 演算模型(e.g., PDL)
3.2.3.3 規范/限制
]3.2.3.4 本地數據結構
3.2.3.5 在3.2.3.6設計中包含的執行結果
3.3 軟體介面描述
軟體對外界的介面描述
3.3.1機器對外介面
與其他機器或者設備的介面描述。
3.3.2系統對外介面
對其它系統、產品和網路的介面描述。
3.3.3與人的介面
概述軟體與任何人的界面。
4.0 用戶界面設計
描述軟體的用戶界面設計。
4.1 描述用戶界面
詳細描述用戶界面，包括屏幕顯示圖標、圖片或者類型。
4.1.1 屏幕圖片
從用戶角度描述界面。
4.1.2 對象和操作
所有屏幕對象和操作的定義。
4.2 界面設計規范
用戶界面的設計和實現的規范和標准。
4.3 可見構件
實現的GUI可見構件說明。
4.4 UIDS描述
用戶界面開發系統描述。
5.0約束、限制和系統參數
會影響軟體的規格說明、設計和實現的特殊事件。
6.0測試標准
測試策略和預備測試用例描述。
6.1 測試的類別
規定實施測試的類別，包括盡量詳細的描述。這里是針對黑盒測試現象的描述。
6.2期待軟體反饋
測試期待的結果描述。
6.3執行界線
特殊執行需要的說明。
6.4 重要構件確認
決定性構件或者需要特殊注意的構件的測試確認。
7.0附錄
設計說明的補充信息。
7.1系統可跟蹤矩陣
一個定期回歸系統規格跟蹤軟體需求的矩陣。
7.2 產品戰略
如果規格說明書是為一個產品設計的，描述相關的產品戰略。
7.3 使用分析演算法
描述所有分析活動所使用到的分析演算法。
7.4 補充信息 (如果有需要特別說明的)
『貳』 軟體需求分析範文
http://www.souku.com.cn/dasous.jsp?key=%C8%ED%BC%FE%B1%A8%B8%E6&search_type=ALL
這里有很多，你到網上搜一下應該有。
參考資料：www.souku.com.cn
http://www.8wen.com/search/docs/%C8%ED%BC%FE%D0%E8%C7%F3%B7%D6%CE%F6%C0%FD%CE%C4/1
呵呵，希望能幫到你
『叄』 一個軟體項目要寫哪些文檔,又該怎樣寫
簡單的列一下：
立項前：市場調查報告，項目計劃書
需求階段：用戶需求規格說明書，技術可行性報告，風險評估報告
設計階段：概要設計說明書，詳細設計說明書
編碼階段：編碼規范
測試階段：測試計劃 測試分析報告
發布階段：項目開發總結報告 用戶手冊
『肆』 硬體需求文檔怎麼寫
1、首先根據功能分類
2、分別簡介結構、原理
3、介紹各部分採用的理由、特點
4、主要元器件的選擇及理由
5、列出元件列表。
不知是否是你需要的答復。
『伍』 軟體的需求分析怎麼寫啊
1. 引言
1.1編寫目的:編寫此文檔的目的是進一步定製軟體開發的細節問題,便於用戶與開發商協調工作.本文檔面向的讀者主要是項目委託單位的管理人員.希望能使本軟體開發工作更具體.
1.2項目背景
1.2.1項目委託單位:****公司
1.2.2開發單位:***公司
1.3定義
1.4參考資料
2. 任務概述
2.1目標:
<1> 決策支持:根據公司的要求及時提供所需報表及文件,並在適當時候對各部門領導給予銷售及進貨等方面的提示
<2>提高效率:利用軟體進行管理,避免人工管理的失誤以及 延遲性,從而實現高效率的管理.
2.2運行環境:
<1> 硬體方面:Pentium級處理晶元
1兆顯存的兼容顯卡
256色,800*600的兼容顯示器
標准兼容列印機
<2>軟體方面: WIN95操作系統
2.3條件與限制:
編程用計算機一台
完成期限2000/7/1
無資金供給
3. 數據概述
數據流程圖如下:
3.1靜態數據:包括系統登錄密碼,各資料庫所在位置,系統分析原始數據
3.2 動態數據:包括各資料庫內各項顯示數據,用戶登錄信息,系統時間
3.3資料庫描述:
人事管理資料庫:公司內人員的個人詳細信息,包括檔案信息
銷售管理資料庫:當日銷售記錄及以前的銷售統計,用於銷售分析
財務管理資料庫:公司內部賬目及收支情況詳表
技術管理資料庫:公司所需各技術檔案的詳細記錄(包括文檔)
3.4 數據字典:
<1>數據流詞條描述:
1.數據流名:登錄信息
來源:用戶的輸入
去向:系統內部檢驗部分
組成:用戶名,密碼
流通量:每次登錄輸入一次
2.數據流名:登錄結果
來源:系統
去向:用戶
組成:返回信息
流通量:每次登錄返回一次
3.數據流名:輸入修改信息
來源:用戶
去向:系統判斷部分
組成:根據各資料庫內容而不同
流通量:依用戶輸入而定
4.數據流名:反饋信息
來源:系統判斷部分
去向:用戶
組成:系統經判斷後發回的字元數據
流通量: 依系統當前信息而定
5.數據流名:識別信息
來源:系統內部檢驗部分
去向:系統判斷部分
組成:系統各資料庫的標識信息
流通量:用戶每次輸入流通一次
6.數據流名:處理信息
來源:系統判斷部分
去向:各資料庫處理部分
組成:讀取/修改標識,讀取/修改的變數名稱
流通量:用戶每次輸入流通一次
7.數據流名:讀取修改
來源:系統判斷部分
去向:系統各資料庫
組成:讀取/修改標識,讀取/修改內容
流通量: 用戶每次輸入流通一次
<2>數據文件詞條描述:
1.數據文件名:人事數據
簡述:存儲人員信息
數據文件組成:人員的各項信息(以CString類型為主)
2.數據文件名:銷售數據
簡述:存儲當日及從前的銷售記錄
數據文件組成:銷售的各項信息
3.數據文件名:財務數據
簡述:存儲財務管理信息
數據文件組成:財務管理的各項記錄
4.數據文件名:技術數據
簡述:存儲公司內部使用的技術檔案信息
數據文件組成:技術檔案名稱,內容
<3>加工邏輯詞條描述:
1.加工名:檢驗
簡要描述:判斷用戶的許可性
輸入數據流:登錄信息
輸出數據流:登錄結果
加工邏輯:判斷是否與系統內部用戶信息相符合
2.加工名:判斷
簡要描述:判斷用戶的操作並進行相應的讀取/存儲工作
輸入數據流:輸入修改信息
輸出數據流:反饋信息
加工邏輯:判斷用戶的操作->調用資料庫->讀取/修改->反饋
3.加工名:人事檔案管理
簡要描述:對人事資料庫進行相應要求的操作,並與判斷部分交互
輸入數據流:處理信息,讀取修改
輸出數據流: 讀取修改, 處理信息
加工邏輯:判斷用戶要讀取/修改的內容->反饋用戶所需信息
4.加工名:銷售統計
簡要描述:對銷售資料庫進行相應要求的操作,並與判斷部分交互
輸入數據流:處理信息,讀取修改
輸出數據流: 讀取修改, 處理信息
加工邏輯:判斷用戶要讀取/修改的內容->反饋用戶所需信息
5.加工名:財務統計
簡要描述:對財務資料庫進行相應要求的操作,並與判斷部分交互
輸入數據流:處理信息,讀取修改
輸出數據流: 讀取修改, 處理信息
加工邏輯:判斷用戶要讀取/修改的內容->反饋用戶所需信息
6.加工名:技術管理
簡要描述:對技術統計資料庫進行相應要求的操作,並與判斷部分交互信息
輸入數據流:處理信息,讀取修改
輸出數據流: 讀取修改, 處理信息
加工邏輯:判斷用戶要讀取/修改的內容->反饋用戶所需信息
<4>源點及匯點詞條描述:
名稱:用戶
簡要描述:既是源點又是匯點,發出動作信息給"檢驗"和"判斷"加工,通過交互界面接受反饋信息有關數據流:登錄結果,登錄信息,輸入修改信息,反饋信息
數目:一個
4. 功能需求
4.1功能劃分
可細分為四部分:人事管理,銷售管理,財務管理,技術檔案管理
4.2功能描述
<1>人事功能:
(1)能對公司內部的所有人員有關檔案詳細資料記錄並保存。
(2)能對資料庫內人事檔案的數據進行查閱和修改。
(3)能按部門或姓名檢索人員。
(4)當某員工的僱用期限達到整年時，按時提醒。
<2>銷售統計功能
(1)按日對公司的銷售情況進行統計,包括銷售額\銷售數量\各地區銷售比例\不同銷售方式的銷售量比例以及銷售毛利潤情況
(2)制定銷售情況的月報表\季報表以及年報表對銷售情況進行分析,對不同銷售人員的業績進行評定
<3>財務管理功能
(1)協助財務人員進行計算機管理,對庫存情況\進貨情況\銷貨進行登錄和輸出
(2) 根據預設的庫存情況提醒進貨
(3) 對收款情況進行統計,在應收帳款達到預設值時進行提示
<4>技術管理功能
(1)對技術資料進行登錄
(2)對維修記錄進行登錄和統計,按不同型號的機器進行故障整體分析,並作出分析報告
(3)對維修配件的需求進行管理並及時提示備貨
5. 性能需求
5.1數據精確度:因為此數據為公司內部數據,所以要求不能有誤差
5.2時間特性:當日銷售統計要求有即時性,馬上能反應出存貨的問題;同時財務管理數據計算當前存貨情況,並對進貨情況進行估算
5.3 適應性:此軟體只在公司內部管理人員的機器上使用,因此不考慮適應性
6. 運行需求
6.1用戶界面:
屏幕格式:
(1)要求有菜單及工具欄以方便操作
(2)各資料庫信息可在屏幕上直接修改
(3)各數據統計結果可在屏幕上顯示
(4)進行系統分析後的結果在另一窗口中顯示
報表格式:
(1)人事管理報表只要求有個人的普通數據
(2)銷售統計報表要求可分別列印當日統計或之前的統計
(3)財務統計報表要求列印出存貨及公司帳務詳表
(4)技術管理報表要求可以分別列印技術檔案總表和任一技術檔案文檔內容菜單格式:要求菜單項大致與WIN95標准相同,另外附加的功能做到新的單項中輸入輸出時間:年份以4位數字表示
6.2硬體介面:需要標准列印機介面進行報表列印
6.3 軟體介面:Windows標准介面
7. 其他需求
可使用性:要求容易使用,界面友好
安全保密性:因本數據屬於公司內部管理用關鍵數據,因此除公司管理人員外,其他人員不得訪問.要求設有登錄密碼檢驗功能,並且此密碼可以在以後進行修改
可維護性:要求本軟體的維護文檔齊全,便於維護
『陸』 軟體需求說明怎麼寫
近來學校的一些科研項目又在申報了，一些學弟開始Q我一些軟體工程上書面的問題。大概的總結了下，寫到這里。本文涉及到的是需求分析部分的書寫，主要是根據國家標准文檔中的要求來的。
在互聯網公司或者一些敏捷開發的公司里，其實大家都是秉承著重開發，重討論，而輕文檔的態度。這個輕文檔並不是指沒有文檔或者幾乎不做文檔，而是在嚴格的文檔流程中解脫出來，只把最最實際的部分寫出來。這個特徵是有互聯網本身迭代周期短，版本發布快等特點決定的。而在實際的兼職項目的時候，同學們就要注意了，最重要的應該就是在簽合同的時候一定要附上最清楚的一份需求分析，雖然這份需求說明可能不是按照某些標准文檔而來的，描述清楚每個功能達到的效果，而這個效果一定要讓客戶點頭確認，而不能出現「應該是」、「可能是」、「也許是」這樣的模糊回答。否則在項目後期就會比較難過了。在學校申請的項目和大型公司項目開發中，是重視文檔流程的，一部一部來。所以還是看情況來對待文檔的深度和標准。
一、目錄：目錄要用word的「引用」—>」目錄」，自動生成目錄，一般都是要三級目錄。通常這部分基本都不需要改結構，直接更新頁碼即可。
二、內容部分。國家標准軟體需求說明書G856T-88下載
1引言
1.1編寫目的
說明編寫這份軟體需求說明書的目的，指出預期的讀者。
（這部分說明需求分析報告的概況，例如：本X需求分析報告是為S系統而編寫的。+S系統的兩句話概述。+本X報告旨在使U1（需求者）明確S系統的要求和細節，給U2(開發人員)了解需求實現的難度和困難，最終提供給U3（審核人、管理者）討論和審核，達到溝通效果）
1.2背景
說明：
a．待開發的軟體系統的名稱；
b．本項目的任務提出者、開發者、用戶及實現該軟體的計算中心或計算機網路；
c．該軟體系統同其他系統或其他機構的基本的相互來往關系。
（這部分可以將a,b,c分為2部分，例子如下：
1.2.1項目概況
本需求分析報告所預期開發的軟體系統是:S。S是（不是則無）SS系統的某一個功能子模塊，S和S1、S2等系統之間的聯系，以及概述其他系統的狀態等等。
1.2.2任務分配
a.任務提出者：xxx
b.軟體開發者：xx
c.產品使用者：xx
d.文檔編寫者：xx
e.預期產品使用者：xx
）
1.3定義
列出本文件中用到的專門術語的定義和外文首字母組詞的原片語。
（這部分很簡單，就是描述專業詞彙，比如
1. XML(Extensible Markup Language)即可擴展標記語言,它與HTML一樣,都是SGML(Standard Generalized Markup Language,標准通用標記語言)。
2. Word2,解釋。。。
）
1.4參考資料
列出用得著的參考資料，如：
a．本項目的經核準的計劃任務書或合同、上級機關的批文；
b．屬於本項目的其他已發表的文件；
c．本文件中各處引用的文件、資料、包括所要用到的軟體開發標准。列出這些文件資料的標題、文件編號、發表日期和出版單位，說明能夠得到這些文件資料的來源。
2任務概述
2.1目標
敘述該項軟體開發的意圖、應用目標、作用范圍以及其他應向讀者說明的有關該軟體開發的背景材料。解釋被開發軟體與其他有關軟體之間的關系。如果本軟體產品是一項獨立的軟體，而且全部內容自含，則說明這一點。如果所定義的產品是一個更大的系統的一個組成部分，則應說明本產品與該系統中其他各組成部分之間的關系，為此可使用一張方框圖來說明該系統的組成和本產品同其他各部分的聯系和介面。|
（
本模塊開發主要是為SS的整體服務，完成SS工作中的XX部分以及相關的工作。其涉及的范圍就是，從下達A、B命令後，到給出C結果的過程。具體描述：B1，來完成B11功能；B2，來完成B22功能；等等。本部分是（否）耦合在分詞工具包其他部分中的，主要為嵌入方式和先後方式相互交互。
圖
圖1.該系統的組成同其他各部分的聯系和介面
）
2.2用戶的特點
列出本軟體的最終用戶的特點，充分說明操作人員、維護人員的教育水平和技術專長，以及本軟體的預期使甩頻度。這些是軟體設計工作的重要約束
（例如：二次開發和系統調用人員：具有很高的專業知識水平，理解XX的運行機制。可以對開放代碼進行閱讀和分析，以完成其系統獨特的需求，提供給這部分用戶開放API手冊和Debug版本的源代碼即可；預期這部分用戶會占本系統總用戶量的多大部分。
xx使用者：具有一定的計算機操作能力和知識，了解xx領域的相關概念和用途。提供給這部分用戶操作手冊即可。預期這部分使用者主要是來簡單的xx操作。
維護人員：具有較高的計算機專業水平，可以對常見的系統Bug進行追蹤和分析，具有一定的測試能力。這部分用戶主要是採用了本系統之後的後期工作維護者。
等等
）
2.3假定和約束
列出進行本軟體開發工作的假定和約束，例如經費限制、開發期限等。
（這部分重要是對你有的技術力量、資金狀況、人力資源等情況的假設，以使得你可以在什麼樣的情況和時間范圍內完成工作。工期約束，經費約束，人員約束，地理約束，設備約束等幾個方面列舉說明。）
3需求規定
3.1對功能的規定
用列表的方式（例如IPO表即輸入、處理、輸出表的形式），逐項定量和定性地敘述對軟體所提出的功能要求，說明輸入什麼量、經怎樣的處理、得到什麼輸出，說明軟體應支持的終端數和應支持的並行操作的用戶數。
（例如：
INPUT輸入
PROCESS處理
OUTPUT輸出
LOAD負載量
A
預處理,做怎樣的動作，
AA
CC
B
BBBB
Bb
v
C
CCCC
cc
v
表一、xx模塊IPO表
對IPO表的簡單文字描述。
）
3.2對性能的規定
3.2.1精度
說明對該軟體的輸入、輸出數據精度的要求，可能包括傳輸過程中的精度。
（例如：
Xx目標處理：1Byt–10M，包括左右邊界值。
yy精度范圍：….
ZZ的精度：由於xx的特殊性，本系統均採用xx型來進行字元統計運算，概率部分以及其他比率部分精度精確到0.0x%。
）
3.2.2時間特性要求
說明對於該軟體的時間特性要求，如對：
a．響應時間；
b．更新處理時間；
c．數據的轉換和傳送時間；
d．解題時間；等的要求。
(這部分只要一一列舉就可以：
由於xxx過程中，需要大量xxxx操作或怎樣，故xx解題時間占總時間的最大部分。其次就是xx轉換和存儲的開銷。其具體時間特性要求，如下：
a．xx響應時間：xxms左右；
b．yy更新處理時間：yy；
c．zz數據的轉換和傳送時間：zz；
d．vv解題時間：vv。
等等
)
3.2.3靈活性
說明對該軟體的靈活性的要求，即當需求發生某些變化時，該軟體對這些變化的適應能力，如：
a．操作方式上的變化；
b．運行環境的變化；
c．同其他軟體的介面的變化；
d．精度和有效時限的變化；
e．計劃的變化或改進。
對於為了提供這些靈活性而進行的專門設計的部分應該加以標明。
（這部分按列舉來即可，由於本模塊第一目的是用於xxx，其次則是xxxx。故本模塊的靈活性在於實際應用者的不同。當需求發生某些變化時，該軟體對這些變化的適應能力。具體情況如下：
f．操作方式上的變化：採用集成運行制和獨立運行制兩種模式，集成運行制是把本模塊嵌入到分詞工具包的主框架中，提供給用戶具有一定UI的可操作軟體；獨立運行制是可以獨立運行於後台，並提供給各種程序調用的模式的工作方式，以增強其生命力。
g．運行環境的變化：主採用Windows平台的編譯版本運行和調試，在時間允許的情況下，同步開發支持SUSE Linux的伺服器版本。；
h．同其他軟體的介面的變化：在盡量保證介面不出現變動的情況下，允許介面的重載和再定義。但介面的命名規則是統一的；
i．精度和有效時限的變化：精度在必須調整的條件下，可以上下浮動10個百分點；有效時限則依據現實的測試情況允許稍大范圍的變化。
j．計劃的變化或改進：工作時間安排會存在必然的浮動，這部分要協同分詞工具包課題設計組其他成員一同來進行商定，前期的計劃可以稍微有些變動，後期的安排盡量按照計劃執行。
等等
）
3.3輸人輸出要求
解釋各輸入輸出數據類型，並逐項說明其媒體、格式、數值范圍、精度等。對軟體的數據輸出及必須標明的控制輸出量進行解釋並舉例，包括對硬拷貝報告（正常結果輸出、狀態輸出及異常輸出）以及圖形或顯示報告的描述。
（這部分可以把輸入輸出分為3.3.1輸入要求和3.3.2輸出要求，如下給出一個單元的例子。
XXX輸出
數據名稱：XXX輸出數據
實際含義：用於XX,表示XXXX
數據類型：Character(字元串)
數據格式：XX
數據約束：由於xxx,，大小在xx以內
）
3.4數據管理能力要求
說明需要管理的文卷和記錄的個數、表和文卷的大小規模，要按可預見的增長對數據及其分量的存儲要求作出估算。
（
根據實際系統要求列舉即可
Name名稱
Number數量
Size大小
Increase增長
詞典xx
xx
xxxx
並行執行，其大小依據實際xx大文本而增長
）
3.5故障處理要求
列出可能的軟體、硬體故障以及對各項性能而言所產生的後果和對故障處理的要求。
（包括軟體壓力，內存不足，硬體損壞等，這部分可以根據網路到其常見故障。）
3.6其他專門要求
如用戶單位對安全保密的要求，對使用方便的要求，對可維護性、可補充性、易讀性、可靠性、運行環境可轉換性的特殊要求等。
（例如安全保密性：密鑰更換等；預期擴展：擴展兼容等；OS更換：Slackware轉SUSE等
）
4運行環境規定
4.1設備
列出運行該軟體所需要的硬設備。說明其中的新型設備及其專門功能，包括：
a．處理器型號及內存容量；
b．外存容量、聯機或離線、媒體及其存儲格式，設備的型號及數量；
c．輸入及輸出設備的型號和數量，聯機或離線；
d．數據通信設備的型號和數量；
e．功能鍵及其他專用硬體
（列舉說明即可）
4.2支持軟體
列出支持軟體,包括要用到的操作系統、編譯（或匯編）程序、測試支持軟體等。
（操作系統和版本：xxxx
支撐環境和版本：xxxx
備用IDE環境和版本：xxxx
與該軟體有關的軟體組件：xxxx
後續可能擴展環境：xxxx
）
4.3介面
說明該軟體同其他軟體之間的介面、數據通信協議等。
(例如：
a．用戶和主程序調用介面(圖中介面1)。這個介面採用封裝API形式和函數調用形式，分別以外部調用和內部調用的方式為不同用戶提供使用本機械分詞工具的入口。例如以xxxx方式調用DLL文件，以xxxx方式調用函數。如下圖2所示。
圖2.軟體介面調用圖
b.xx介面(圖中介面2)。這里是一個xxx的介面調用過程。xxxx
)
4.4控制
說明控制該軟體的運行的方法和控制信號，並說明這些控制信號的來源。
(例如：
下面通過圖表的形式，將本模塊以及涉及到本模塊的軟體模塊的運行方法、控制信號，以及這些控制信號的來源，其中箭頭所指方向對應的模塊的控制信號來自箭頭另一方向的模塊，具體情況如下：
圖3 .控制流程圖
圖3的具體說明情況如下表所示：
Name模塊名稱
Method運行方式
Signal控制信號
Forward控制去向
主程序模塊
運行框架
用戶調用或運行
1.調用xx模塊
2.調用xx方法
3.調用標准輸出模塊
xxx模塊
xxx
xxx調用
Xxx模塊
)
附錄：軟體設計文檔國家標准(GB8567–88)軟體設計文檔國家標准(GB8567–88)GB8567——88
操作手冊（GB8567——88）.doc 資料庫設計說明書（GB8567——88）.doc
測試分析報告（GB8567——88）.doc 數據要求說明書（GB856T——88）.doc
測試計劃（GB8567——88）.doc 圖1.doc
概要設計說明書（GB8567——88）.doc 文件給制實施規定的實例（GB8567-88）.doc
開發進度月報（GB8567——88）.doc 詳細設計說明書（GB8567——88）.doc
可行性研究報告（GB8567——88）.doc 項目開發計劃（GB856T——88）.doc
模塊開發卷宗（GB8567——88）.doc 項目開發總結報告（GB8567——88）.doc
軟體需求說明書（GB856T——88）.doc 用戶手冊（GB8567——88）.doc
『柒』 軟體開發文檔應該如何寫
如果我們知道軟體文檔的價值，那麼為什麼不經常使用它呢？對於新手，大多數軟體文檔都存在很多下面提到的這些問題：
· 糟糕的語法和/或拼寫錯誤的詞語
· 不完整
· 過期或不準確
· 篇幅太長
http://www.mscto.com
· 首字母縮寫沒有解釋或術語不專業
http://www.mscto.com
· 難於找到信息或在文檔中定位 軟體開發網
存在這些問題的主要原因是軟體文檔通常沒有被給予足夠的重視。項目預算被迫將主要活動花在了開發工作上，在那裡管理層很容易看到他們的收益。值得投入成本的文檔工作通常都是主觀的，而且通常被刻畫為需要避免的成本，因為它們被認為不能產生投資回報（ROI）。很多項目經理將客戶所需要的最少文檔看作是「鍍金」。
軟體開發網
軟體文檔的另外一個麻煩來源是文檔的作者。很多應用程序開發經理覺得軟體文檔是開發工作的一個標准部分，因此，要求他們的開發人員在編碼時也編寫軟體文檔。
雖然這在理論上是說得過去的，但是不應該將開發人員看成文檔作者。很簡單，技術人員只被培訓如何開發，而沒有被培訓如何寫文檔。為了解決這一問題，很多應用程序開發經理嘗試通過聘請一些技術性寫手或商業分析人員來提高他們的軟體文檔的質量。這就導致出現了一個相反的問題：技術寫手和商業分析人員通常只有有限的技術技能。
解決方案依賴於文檔，文檔應該迎合其潛在讀者的口味。這方面的通用規則是要求使用一個協同工作方法來編寫文檔，這種方法允許開發人員和寫手發揮他們的長處。例如，如果潛在的讀者是系統設計人員，那麼開發人員應該提供詳細的輸入，但是允許技術寫手去組織和編輯內容以使文檔符合語法。
不管潛在的讀者還是被選中的讀者，軟體文檔的質量與其可使用性相關，以下六個屬性可以用來測量軟體文檔的可使用性：
· 適用性：文檔提供了相關的信息嗎？
· 合時性：文檔所提供的是當時的信息嗎？
· 正確性：文檔所提供的信息正確嗎？
· 完整性：文檔是不是足夠詳細？
· 可用性：文檔隨手可用嗎？
· 可使用性：能夠快速直觀地找
希望能助你一臂之力
『捌』 怎麼寫項目需求文檔
如果你是真的想寫，希望你實地到超市去考察下，看看他們的工作流程，然後按流程寫，寫不好，至少是真實的，而且對你也會有幫助，如果不是，那你從網上找找，有很多
『玖』 需求文檔怎麼寫最有效
能將功能需求寫清楚的就是好的需求文檔，因為現在的需求文檔一般都是給開發看，一般來說創業公司追求小步快跑快速迭代的開發模式的話，需求文檔不是一個很有必要的東西，直接在原型上表述效率會更好。如果公司追求規范管理的話，建議還是需求文檔，寫清楚項目名稱，迭代版本，及相關的日期規劃。
『拾』 軟體文檔怎麼寫
1.0概述 這部分提供對整個設計文檔的概述。描述了所有數據，結構，介面和軟體構件級別的設計。
1.1 目標和對象 描述軟體對象的所有目標。
1.2 陳述范圍 軟體描述。主要輸入，過程功能，輸出的描述，不考慮詳細細節。
1.3 軟體內容 軟體被置於商業或者產品線中，討論相關的戰略問題。目的是讓讀者能夠對「宏圖」有所了解。
1.4 主要系統參數 任何商務軟體或者產品線都包含軟體規定、設計、實現和測試的說明和規范。
2.0 數據設計 描述所有數據結構包括內部變數，全局變數和臨時數據結構。
2.1 內部軟體數據結構 描述軟體內部的構件之間的數據傳輸的結構。
2.2 全局數據結構 描述主要部分的數據結構。
2.3 臨時數據結構 為臨時應用而生成的文件的描述。
2.4 資料庫描述 作為應用程序的一部分，描述資料庫結構。
3.0 結構化和構件級別設計 描述程序結構。
3.1 程序結構 詳細描述應用程序所選定的程序結構。
3.1.1 結構圖 圖形化描述結構。
3.1.2 選擇性 討論其它可供考慮的結構。選定3.1.1中結構類型的原因。
3.2 構件描述 詳細描述結構中的每個軟體構件。
3.2.1 構件過程敘述(PSPEC) 描述構件的過程。
3.2.2 構件介面描述 詳細描述構件的輸入和輸出。
3.2.3 構件執行細節 每個構件的詳細演算描述。
3.2.3.1 介面描述
3.2.3.2 演算模型(e.g., PDL)
3.2.3.3 規范/限制 ]
3.2.3.4 本地數據結構
3.2.3.5 在3.2.3.6設計中包含的執行結果
3.3 軟體介面描述 軟體對外界的介面描述
3.3.1機器對外介面 與其他機器或者設備的介面描述。
3.3.2系統對外介面 對其它系統、產品和網路的介面描述。
3.3.3與人的介面 概述軟體與任何人的界面。
4.0 用戶界面設計 描述軟體的用戶界面設計。
4.1 描述用戶界面 詳細描述用戶界面，包括屏幕顯示圖標、圖片或者類型。
4.1.1 屏幕圖片 從用戶角度描述界面。
4.1.2 對象和操作 所有屏幕對象和操作的定義。
4.2 界面設計規范 用戶界面的設計和實現的規范和標准。
4.3 可見構件 實現的GUI可見構件說明。
4.4 UIDS描述 用戶界面開發系統描述。
5.0約束、限制和系統參數 會影響軟體的規格說明、設計和實現的特殊事件。
6.0測試標准 測試策略和預備測試用例描述。
6.1 測試的類別 規定實施測試的類別，包括盡量詳細的描述。這里是針對黑盒測試現象的描述。
6.2期待軟體反饋 測試期待的結果描述。
6.3執行界線 特殊執行需要的說明。
6.4 重要構件確認 決定性構件或者需要特殊注意的構件的測試確認。
7.0附錄 設計說明的補充信息。
7.1系統可跟蹤矩陣 一個定期回歸系統規格跟蹤軟體需求的矩陣。
7.2 產品戰略 如果規格說明書是為一個產品設計的，描述相關的產品戰略。
7.3 使用分析演算法 描述所有分析活動所使用到的分析演算法。
7.4 補充信息 (如果有需要特別說明的)