1. 需求文檔怎麼寫最有效
摘要：對於產品經理來說，撰寫一份完整的產品需求文檔往往需要花費很長時間，那麼
如何提升產品需求文檔的撰寫效率呢？
使用摹客等高效便捷的產品文檔撰寫工具，可以簡化產品文檔撰寫流程，提升產品經理的文檔撰寫能力，讓產品經理事半功倍。
總結
產品需求文檔作為產品開發團隊的重要溝通文檔，文檔的質量好壞會直接影響到各部門是否能夠明確產品的功能和邏輯。一份簡潔易懂、邏輯清晰的產品需求文檔，可以讓團隊溝通更加高效，從而有效提高產品開發團隊的工作效率。
2. 產品經理應該怎麼寫BRD、MRD、PRD（需求文檔）呢
因為內容較多，我就簡要說一下寫作目錄
BRD文檔
01 BRD說明
概念：BRD文檔是產品生命周期中最早的文檔，是我們產品定義階段的匯總。
用於：說明市場分析，銷售策略，盈利預測，產品構思等。
目的：說服領導及同事為此項目提供資源支持。
02 BRD撰寫
撰寫結構：方案背景、產品規劃、運營規劃、收益&成本、盈利模式、風險&對策
整體結構梳理如下：
1. 方案背景
描述背景的所有的數據最好註明數據來源。可以通過上市公司財報，艾瑞咨詢，或一些知名網站的采訪文章來獲取數據，甚至是內部人士的消息，都是重要的參考來源。
基於整個行業，描述以下內容：
(1)行業背景和現狀
(2)商業價值/市場規模(開辟新市場的情況下)
(3)用戶需求
(4)盈利模式
(5)發展趨勢
(6)競爭對手發展情況
2. 產品規劃
產品規劃主要是包括對於產品的定位、產品的核心目標、產品的結構和迭代路線進行一個整體的呈現。這部分內容可以借鑒產品的迭代更新文件(如果有的話)，主要是基於當前產品的規劃，描述以下內容：
(1)產品定位
(2)核心目標
(3)產品結構
(4)產品路線
3. 運營規劃
完整的運營規劃，包括內容運營，用戶運營，社區運營，活動運營，產品運營五個方面，但是並不是所有的產品都會占據所有的運營方式，每個產品的運營涉及的部分不一定一樣，側重點也不一樣。
(1)內容運營
(2)用戶運營
(3)社區運營
(4)活動運營
(5)產品運營
4. 盈利模式
簡單的說，就是介紹產品將通過怎樣的模式、渠道來獲得收益
5. 收益與成本
6. 風險與對策
SWOT分析：優勢、劣勢、機會、威脅;(SWOT就不多敘述了，網站內有詳細的介紹哦)
MRD文檔
1、概述:包含兩個點，背景和目標。
2、市場概述:描述一下你們要做的是什麼市場。
2.1市場特徵
從全局說說目前市場個競品的產品定位。
2.1.1市場問題
列舉市場痛點，用戶在需求產生後，遇到的各個環節的問題，目前市場是如何滿足的，以及那些需求點尚未得到滿足?或滿足不夠有深度挖掘的空間。
2.1.2市場機會
根據市場的問題，分析問題，是否還有機會做這個市場?根據市場凸顯的問題，舉例出幾種解決方案，逐一舉例。
2.2市場趨勢
可預見的估測評估未來市場的發展，可能會出現那種情況?出現巨頭壟斷?還是三足鼎立?垂直細分?020線上線下結合等等。
2.3市場細分
舉例市場都有哪些細分?和這些細分相對應的產品都有哪些?
2.4市場壁壘
要切入市場，有哪些難題，有什麼壁壘?
成熟壁壘。市場已經非常成熟，品牌體驗已經深入人心，不細分切入幾乎沒用勝算。
資金壁壘。市場處於初期紅海或者到了火拚時代如以前的百團大戰、打車、拼車、外賣市場等。一種就是起動需要大量的資金，如京東的自建物料。
技術壁壘。如人工智慧、搜索這些需要高精尖技術人才，才能實現的。
壟斷壁壘。例如醫療、電信、支付等，需要國家批準的。
2.5市場緊迫性
基於市場發展的趨勢，項目的啟動是否需要一些特殊的需求?
3.用戶需求分析:詳細說明用戶需求的動機。
3.1用戶類型細分
說明用戶群體的細分維度，對用戶進行分解，可通過典型用戶、類型特徵特徵等進行描述。不同需求用戶，對產品的關注點不同。
3.2用戶場景
用戶發生需求的場景，和不同場景的特徵。比如睡覺時、坐地鐵坐公交時、開車時等等。
4、競品分析
直接競品
間接競品
競品模式分析
PRD文檔
一、PRD文檔頭
文檔名稱、作者或則撰寫人、文檔編寫日期、版本紀錄、目錄。
二、PRD文檔內容結構
PRD文檔內容結構包括：概述、產品需求說明、產品流程說明、產品結構和功能說明、其他產品需求、上線需求說明。如果需要的話有相關文檔，附件說明。
1、概述
從大的方向，講講項目的相關背景、有什麼目標、有沒有競品對像?而階段性計劃是什麼?傳遞做這個需求的目的是什麼?要達到什麼樣的目標?要達到這個目標階段性計劃是什麼?
2、產品需求
落到具體的地方，產品有哪些需求?增加了哪些需求?調整了什麼?取消了什麼?需不需要其他資源的配合?有什麼影響?，從這幾個地方說清楚。
3、產品流程說明
講清楚每個邏輯點，每個地方應該怎麼走?應該做什麼樣的判斷?如果進行這個操作返回給用戶什麼內容?用戶觸發之後得到什麼內容?
4、產品結構說明
根據產品的內在邏輯，分解、細化需求，將需求細化說明。
5、其他產品需求
涉及到其他產品的產品線時，需要協同多個產品線進行多方面考慮。協同調整，避免出現遺漏，出現不必要的偏差。
6、相關文檔
如果一個項目分解成多個團隊。多個需求文檔協同合作。如一個UGC社區，有PC端社區，有APP端社區。
7、上線需求
測試通過的需求，具體的上線時間，具體一些特殊的流程需求等。
8、其他需求、附件
作為需求的一種補充，對一些需求進行補充說明，或者需要的文件說明等
歡迎來起點學院學習更多產品文檔寫作方法
3. 怎麼寫需求說明書
需求說明書範文
漢語編程企業管理應用軟體
需求說明書
1 引言
對軟體需求完全理解對於軟體開發工作的成功是至關重要的，需求說明的任務是發現、規范的過程，有益於提高軟體開發過程中的能見度，便於對軟體開發過程中的控制與管理，便於採用工程方法開發軟體，提高軟體的質量，便於開發人員、維護人員、管理人員之間的交流、協作，並作為工作成果的原始依據，並且在向潛在用戶傳遞軟體功能、性能需求，使其能夠判斷該軟體是否與自己的需求相關。
1.1 編寫目的
1.1.1 為開發人員、維護人員、客戶之間提供共同的協議而創立基礎，對企業管理軟體功能的實現作使命描述。
1.1.2 本說明書的預期讀者為客戶、業務或需求分析人員、測試人員、用戶文檔編寫者、項目管理人員。
1.2 背景及范圍
1.2.1 工程的名稱：漢語編程企業管理應用軟體 1.2.2 工程產品的名稱：漢語編程企業管理應用軟體 1.2.3 工程的組織者：北京元易達科技發展有限責任公司 產品的生產者：漢語編程企業管理應用軟體開發課題組 產品的設計者：漢語編程企業管理應用軟體開發課題組
1.2.4 產品的所有權：漢語編程企業管理應用軟體開發課題組
1.3 定義,術語,縮寫詞和略語 企業管理應用系統軟體：它是由企業管理應用系統軟體課題組完全自主開發的企業管理軟體，以企業各部門為基本元素的、用漢語編程來實現其功能的軟體。 需求：用戶解決問題或達到目標所需的條件或功能；系統或系統部件要滿足合同、標准，規范或其它正式規定文檔所需具有的條件或權能。
需求分析：包括提煉，分析和仔細審查已收集到的需求，以確保所有的風險承擔者都明其含義並找出其中的錯誤，遺憾或其它不足的地方。
模塊的獨立性：是指軟體系統中每個模塊只涉及軟體要求的具體的子功能，而和軟體系統中其他的模塊的介面是簡單的。 1.4 參考資料
《漢語程序設計語言》---- 沈志斌 編著 電子工業出版社
《 計算機系統導論》 ---- 劉瑞挺 編著 高等教育出版社
《 資料庫原理與方法》---- 鄭若忠 王鴻武 編著 湖南科學技術出版社 《 軟體需求 》 ---- （美） Karl E.Wiegers 著
陸麗娜 王忠民 王志敏 等譯
2 項目概述
2.1 目標
本軟體的目標使企業管理電子化、簡單化，以節省企業管理方面的不必要的資源浪費。對於企業管理應用系統軟體最終用戶為企業的管理人員。 2.1.1 開發意圖
目前中小企業在日常工作中採用人工管理，因而存在著大量的浪費和多餘，本軟體根據此要求進行開發。 2.1.2 應用目標
企業管理應用系統軟體將解決企業管理人工化，工作繁余的問題，實現企業管理電子化。
2.1.3 作用及范圍
本企業管理應用系統軟體是應用於中小企業的。目前，中小企業管理比較落後，它將產生的影響將使中小企業管理從人力化到數字化進展，使管理人員思想上向數字化轉變，能使企業的管理在機制上轉換，人員上得到精簡。 2.1.4 背景
企業管理應用系統軟體以漢語編程為開發語言，各部門以模塊的形式完成。 2.2 產品描述
本產品開發語言核心為漢語編程語言，具體實現是漢語編程和VF資料庫技術相結合開發而成的。本產品面向中小企業，易懂好學，幫助企業管理人員從手工勞動向電子化、數字化轉變。 2.2.1 相關關系
本產品是一項獨立的軟體，全部內容自含。 2.2.2 子集說明
本產品分別有五個模塊組成，每個模塊各有不同的功能。但都能完成查詢和存儲功能，各模塊的數據都存放在資料庫中。數據的調用和連接都有程序來完成，硬體外部設備需奔騰133以上的pc機，內存需16兆以上。
2.3 產品功能 2.3.1 外部功能
企業管理應用系統軟體外部功能包括可視化窗口，查找存儲。 2.3.2 內部功能
企業管理應用系統軟體內部功能：過濾、定位、使用庫等。 2.3.3 功能表
2.3.4 功能表述圖
2.4 用戶特點
漢語編程企業管理應用軟體面向於中小企業，其使用人員應為具備一定的計算機基礎知識和企業管理基本知識。而本產品的維護人員需要具備有漢語編程知識。
2.5 一般約束
a. 本系統開發人員為12人。
b. 有CPU133、16兆內存配置的計算機就可運行本系統。 c. 在管理方針、並行操作、安全與保密方面無約束。
2.6 假設與依據
本軟體在開發的過程中，分為技術實現與軟體工程兩大部分，兩部分都有側重點，若技術支持出現故障或疑難問題無法解決、程序開發出現偏差，會延誤工程進度，影響工程的按期完工。若軟體工程陳述出現問題，部分描述含混不清，
則會影響系統的完整性與可繼承性。在管理方面，如管理者沒有預見性，對出向的問題無法採用可行的解決手段，都會影響開發模塊之間的互動，從而影響工程的順利開展，導致工程無法按期完工。 3 具體需求 3.1 功能需求 3.1.1 使用庫
3.1.1.1 規格說明
3.1.1.2 引言
顯示所調用的資料庫。 3.1.1.3 輸入
指定的庫文件名。 3.1.1.4 加工
調用指定的資料庫。 3.1.1.5 輸出
顯示所指定的資料庫的庫結構。 3.1.2 編輯框控制 3.1.2.1 規格說明
生成編輯框。 3.1.2.3 輸入 編輯框名稱。 3.1.2.4 加工 生成編輯框。 3.1.2.5 輸出
顯示生成的編輯框。 3.1.3 為當前記錄 3.1.3.1 規格說明
3.1.3.2 引言
將指定的記錄置為當前記錄，下一步可以開始對此記錄進行操作。 3.1.3.3 輸入
指定的項名及庫文件名。 3.1.3.4 加工
將指定的資料庫里指定的記錄置為當前記錄。 3.1.4 建庫文件 3.1.4.1 規格說明
輸入庫文件名,使用"建庫文件"命令，建立一個新的資料庫。 3.1.4.3 輸入 庫文件名。 3.1.4.4 加工
建立新的資料庫。 3.1.4.5 輸出 新建的資料庫。 3.1.5 開始尺寸 3.1.5.1 規格說明
3.1.5.2 引言 在程序中，在"開始尺寸"前給出參數值，能確定指定的對象的開始尺寸的大小。
3.1.5.3 輸入 參數值。 3.1.5.4 加工
確定指定對象在窗體中的開始尺寸的大小 3.1.5.5 輸出
確定開始尺寸的四個參數 3.1.6 開始位置 3.1.6.1 規格說明
3.1.6.2 引言 在程序中，在"開始位置"前給出參數值，能確定指定的對象的開始尺寸的大小。
3.1.6.3 輸入 參數值。 3.1.6.4 加工
確定指定對象在窗體中的開始位置。 3.1.6.5 輸出
確定開始位置的四個參數 3.1.7最大尺寸 3.1.7.1 規格說明
3.1.7.2 引言 在程序中，在"最大尺寸"前給出參數值，能確定指定的對象在窗體中的最大尺寸。
3.1.7.3 輸入 參數值。 3.1.7.4 加工
確定指定對象在窗體中的最大尺寸。 3.1.7.5 輸出
確定指定對象最大尺寸的四個參數。
3.1.8 最小尺寸 3.1.8.1 規格說明
3.1.8.2 引言 在程序中，在"最小尺寸"前給出參數值，能確定指定的對在窗體中的最小尺寸。
3.1.8.3 輸入 參數值。 3.1.8.4 加工
確定指定對象在窗體中的最小尺寸。 3.1.8.5 輸出
確定指定對象最小尺寸的四個參數 3.1.9 查詞編輯框（編輯框控制） 3.1.9.1 規格說明
3.1.9.2 引言
主要是定義的一個編輯框，供用戶輸入一個詞名，為程序生成查找條件做准備。
3.1.9.3 輸入
在查詞編輯框中輸入要查找的詞名。 " 編輯框控制 查找編輯框 " 3.1.9.4 加工
用輸入的詞名以供程序生成查找條。 3.1.9.5 輸出
地址、長度。 。
3.1.10 內容編輯框（編輯框控制） 3.1.10.1 規格說明
3.1.10.2 引言
主要是定義的一個編輯框，將程序查找到的用戶所輸入詞的相關內容顯示出來，為用戶提供幫助信息。 3.1.10.3 輸入
資料庫中查找到的記錄的項的內容的地址、長度。 " 編輯框控制 內容編輯框 " 3.1.10.4 加工 置控制標題或值。 3.1.10.5 輸出
顯示用戶所輸入詞的相關內容（如該詞的格式、用法……）。 3.1.11 過濾
3.1.11.1 規格說明
3.1.11.2 引言
定義用戶輸入的詞名與內容庫中的詞名欄位中的詞名進行串比較，即定義詞名欄位為過濾欄位。 3.1.11.3 輸入 用戶輸入的詞名。 3.1.11.4 加工
把代碼寫入過濾條件指針之中。 3.1.11.5 輸出 查找條件。
3.1.12 執行過濾 3.1.12.1 規格說明
3.1.12.2 引言
將定義的過濾作為內容庫的過濾條件。 3.1.12.3 輸入 查找條件。
3.1.12.4 加工
與查找編輯框中的內容比較。 3.1.12.5 輸出 庫過濾顯 。 3.1.13 取低字 3.1.13.1 規格說明
3.1.13.2 引言
取數摞中的一個32位數的低16位放在數摞上。 3.1.13.3 輸入
調用WINDOWS API 函數。 3.1.13.4 加工 3.1.13.5 輸出 相應的執行功能 3.1.14 白線框 3.1.14.1 規格說明
3.1.14.2 引言
定義查看區一個白顏色的線框。
3.1.14.3 輸入
參數、顏色
3.1.14.4 加工
空心矩形： 設備描述表
3.1.14.5 輸出
線框。
3.2.1 動態數值需求
預處理的窗口正常情況下和峰值工作條件下為20個，一定時間周期中要處理的數據的數量：窗口開始尺寸2個數據，開始位置2個數據，最大尺寸2個數據，最小尺寸2個數據，編輯框位置4個數據，按鈕位置4個數據，平均處理的數據約為16個數據。
3.2.2 靜態數值需求
a. 支持的終端數為1台；
b. 支持並行操作的用戶總數為5位；
c. 處理5個文件及10條記錄；
d. 表或文件的最小為266位元組,最大為4位元組；
3.2.3 精度需求
在進行向資料庫文件提取數據時，要求數據記錄定位準確，在往資料庫文件數組中添加數時，要求輸入數准確。
3.2.4 時間特性需求
a. 響應時間應在人的感覺和視覺事件范圍內；
b. 更新處理時間，隨著漢語編程系統的版本升級，漢語編程企業管理應用系統將相應的進行更新；
3.2.5 靈活性
當需求發生某些變化時，漢語編程企業管理應用軟體操作方式、數據結構、運行環境基本不會發生變化，變化只是將對應的資料庫文件內的記錄改變，或將過濾條件改變即可。
3.2.6 數據管理能力需求
漢語編程企業管理應用軟體需要管理5個文件和10條記錄，表文件的大小平均約為1.5k位元組，漢語編程企業管理應用軟體基本約用10 M位元組空間，所有文件均放置在資料庫中，調用，查詢數據，文件，記錄時，通過庫文件名直接進行操作。
3.2.7 故障處理需求
無故障。
3.3 設計約束條件
3.3.1 技術約束
本工程產品的約束條件包括：
a. 資料庫、各種控鍵的使用和消息的調用；
b. 漢語資料庫過濾完成、編輯框的觸發等；
3.3.2 環境約束
運行本軟體需要奔騰133以上 PC，內存需要在16兆以上，對使用設備的速度、規模要求不高。
3.3.3 標准約束
漢語編程企業管理應用軟體完全按照北京元易達科技發展有限責任公司企業標准開發，包括硬體、軟體和文檔規模。
3.4 介面需求
3.4.1 用戶介面
本工程產品通過PC機進行運行、操作，對報表、菜單的列印將使用漢語編程編輯器或調入WORd進行列印。輸出、輸入的相對時間將由pc機本身處理速度來決定。對程序的維護，需進行必要的備份。
3.4.2 硬體介面
本工程產品不需要特定的硬體或硬體介面進行支撐。
3.4.3 軟體介面
本工程產品的軟體介面由漢語編程操作系統、漢語編程資料庫以及漢語編程企業管理應用軟體的詞典和數據結構組成。
3.4.4 通訊介面
本工程產品的沒有特殊的通訊介面，通訊介面由所使用的pc機決定。
3.5 屬性
3.5.1 可用性
本軟體是完全由漢語程序設計語言開發的，漢語編程最大特點編譯解釋和一，它可以進行單步跟蹤。一旦出現錯誤就可以通過單步跟蹤進行查找處理，所以本軟體也可以通過單步跟蹤的操作進行檢查處理。
3.5.2 安全性
本軟體大量的參數及文本內容全部放於漢語編程資料庫中，所以參數不容易被錯改、破壞，萬一參數受到破壞也不會影響源程序。
3.5.3 可維護性
本軟體利用資料庫進行編程，系統結構由程序基本確定，大量的參數及文本內容全部放於漢語編程中。修改、更新數據只要在資料庫進行修改添加，而不需要對系統結構進行修改，這樣系統維護性、升級都十分方便。
3.5.4 可轉移、可轉換性
漢語編程的兼容性很高，在windows95/98 .windowsNT .windows1700 .操作系統都可以直接運行。
3.5.5 注釋
通過"看數摞"、"看內存"、"印字元"三條漢編基本指令，就可以將所有漢編
成程序進行調試和檢查。本系統的大量參數和文本全部放在資料庫中，通過"使用庫"、"庫顯"等一些漢編資料庫基本操作就可以查看、添加、修改系統。 4 支持信息
4.1 支持軟體
本軟體開發是使用漢語編程編寫，編譯系統為"32位漢語編程系統"，版本號為2.01.0061。在庫調用時兼容Visual Foxpro 6.0英文版，源程序的測試是使用漢語編程自身含有的"看數摞、看內存、看詞"的方法進行測試，即支持測試的軟體也是漢語編程操作系統本身。由於漢語編程本身的特點，它的關鍵詞、命令等全部為中文，所以在使用漢語編程系統時需要中文輸入法的支持。
4.2 設備
a. 具有奔騰133、16兆內存配置的計算機；
b. Microsoft滑鼠或其它兼容滑鼠；
c. 最少15MB的硬碟空間，常規安裝需要100MB硬碟空間，完全安裝需要240MB硬碟空間。
d. 最少8MB的RAM存儲器。
e. VGA顯示器或更高。
f. Windows95中文版或Windows NT中文版或更高。
g. 一般計算機外設，如：列印機、掃描儀。如要配置網路環境，還需網路連接設備。
4.3 控制
本軟體是在漢語編程系統的支持下，展示界面由主窗口與子窗口嵌套而成，窗口操作通過按鈕控制，不同的按鈕進行不同的操作實現不同的功能。
4.4 介面
本軟體在庫的調用時兼容Visual Foxpro 6.0英文版的表結構文件，但不能與Visual Foxpro 6.0英文版在一個操作系統環境中同時運行。
4.5 文檔 本系統相關的文檔為： 《漢語編程企業管理應用軟體可行性研究報告》 編號：MNQB01-QG-01 《漢語編程企業管理應用軟體需求說明書》 編號：MNQB03-QG-01 《漢語編程企業管理應用軟體操作手冊》 編號：MNQB11-QG-01
4.6 附錄
a. 輸入輸出格式樣本採用IPO表逐項定量的敘述對本系統軟體提出的功能需求，如下圖：
b. 本系統軟體的背景信息如下：
漢語編程是本公司自行開發，自主版權的以漢語為描述語言的計算機程序設計語言。該語言絕非曾流行過的任何一種計算機語言的簡單漢化，或是為某種軟體製造一個中文環境。這是一個完全由本公司自行開發，由本公司掌握全部源代碼，從形式到內容全面符合中國人的思維方式，使用漢文字表達的計算機程序設計通用語言。Windows環境下的漢語編程，可以用於Windows窗口程序、多媒體應用、資料庫開發、網路傳輸、電子商務等應用領域。對於較初級計算機用戶，在極短的時間內，可以達到很高的編程水平。
4. 軟體需求說明怎麼寫
如何寫需求分析報告（軟體需求說明書GB856T-88）
近來學校的一些科研項目又在申報了，一些學弟開始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
5. 怎樣寫開發軟體產品策劃書
樓主應該先寫需求分析文檔吧
然後才是設計文檔
=================================
需求分析文檔結構
=================================
1. 引言
1.1. 編寫目的
1.2. 背景說明
1.3. 術語定義
1.4. 參考資料
2. 任務概述
2.1. 目標
2.2. 用戶的特點
2.3. 假定與約束
3. 需求規定
3.1. 對功能的規定
3.2. 對性能的規定
3.2.1. 精度
3.2.2. 時間特性要求
3.2.3. 靈活性
3.3. 輸入輸出要求
3.4. 數據管理能力要求
3.5. 故障處理要求
3.6. 其它專門要求
4. 運行環境設定
4.1. 設備
4.2. 支持軟體
4.3. 介面
4.4. 控制
5. 縮寫詞表
6. 參考文獻
=================================
設計文檔結構
=================================
1. 前言
2. 摘要
3. 需求分析
3.1. 企業生產經營概況
3.2. 企業經營目標及策略（近期及遠期）
3.3. 實施需求
3.4. 實施目標
3.5. 實施約束
3.6. 實施功能要求
3.7. 實施信息要求
3.8. 實施性能要求
4. 總體方案與結構
4.1. 制定總體結構的出發點
4.2. 體系結構
4.3. 應用系統結構
4.4. 支撐系統結構
4.5. 信息分類編碼體系
5. I2DEF模型
5.1. 模型選擇說明
5.2. I2DEF模型設計規范
5.3. 結構模型
5.3.1. 系統/功能分解樹
5.3.2. 構件圖
5.4. 動態模型
5.4.1. 事件流程圖
5.4.2. 事件匯總圖
5.4.3. 工作案例圖
5.4.4. 典型事件跟蹤圖
5.5. 功能模型
5.5.1. 數據流程圖
5.5.2. 數據匯總圖
5.5.3. 功能調用圖
6. 資源需求
7. 系統配置
7.1. 配置原則
7.2. 硬體配置
7.3. 軟體配置
8. 介面
8.1. 內部介面
8.2. 外部介面
9. 組織機構及人員配置
9.1. 現行組織機構
9.2. 開發運行的組織機構
9.3. 人員配置與培訓
10. 關鍵技術
10.1. 關鍵技術的提出
10.2. 關鍵技術的一般說明
10.3. 關鍵技術的實現方案
11. 方案實施的技術路線和實施計劃
11.1. 實施的技術路線
11.2. 實施計劃
12. 投資概算及資金規劃
12.1. 投資概算
12.2. 資金規劃
13. 經濟分析
13.1. 經濟效益分析
13.2. 財務評價分析
13.3. 社會效益、戰略效益分析
13.4. 經濟評價的結論和建議
14. 縮寫詞表
15. 參考文獻
6. 項目需求分析怎麼寫
項目需求分析的概念需求分析是指理解用戶需求，就軟體功能與客戶達成一致，估計軟體風險和評估項目代價，最終形成開發計劃的一個復雜過程。（這個和我在微軟體驗到的又不太一樣，微軟的需求分析大多是市場人員和用戶協助小組的人去評估用戶的接受程度，這一點也可以理解，因為公司的性質有根本差別）在這個過程中，用戶的確是處在主導地位，需求分析工程師和項目經理要負責整理用戶需求，為之後的軟體設計打下基礎。需求分析階段結束後，要求得到：1.SRS文檔(System Requirement Specification); 2.DRM 文檔；3.Acceptance Plan. 從廣義上理解：需求分析包括需求的獲取、分析、規格說明、變更、驗證、管理的一系列需求工程。
狹義上理解：需求分析指需求的分析、定義過程。 一、為什麼要需求分析需求分析就是分析軟體用戶的需求是什麼.如果投入大量的人力，物力,財力,時間,開發出的軟體卻沒人要,那所有的投入都是徒勞.如果費了很大的精力,開發一個軟體,最後卻不滿足用戶的要求,從而要重新開發過,這種返工是讓人痛心疾首的.(相信大家都有體會)比如,用戶需要一個for linux的軟體,而你在軟體開發前期忽略了軟體的運行環境,忘了向用戶詢問這個問題,而想當然的認為是開發for windows的軟體,當你千辛萬苦地開發完成向用戶提交時才發現出了問題,那時候你是欲哭無淚了,痕不得找塊豆腐一頭撞死.
需求分析之所以重要,就因為他具有決策性,方向性,策略性的作用,他在軟體開發的過程中具有舉足輕重的地位.大家一定要對需求分析具有足夠的重視.在一個大型軟體系統的開發中,他的作用要遠遠大於程序設計. 二、需求分析的任務簡言之,需求分析的任務就是解決"做什麼"的問題,就是要全面地理解用戶的各項要求,並准確地表達所接受的用戶需求.三、需求分析的過程需求分析階段的工作,可以分為四個方面:問題識別,分析與綜合,制訂規格說明,評審.
問題識別
就是從系統角度來理解軟體,確定對所開發系統的綜合要求,並提出這些需求的實現條件,以及需求應該達到的標准.這些需求包括：功能需求(做什麼),性能需求(要達到什麼指標),環境需求(如機型,操作系統等),可靠性需求(不發生故障的概率）,安全保密需求,用戶界面需求,資源使用需求(軟體運行是所需的內存,CPU等),軟體成本消耗與開發進度需求,預先估計以後系統可能達到的目標.
分析與綜合
逐步細化所有的軟體功能,找出系統各元素間的聯系,介面特性和設計上的限制,分析他們是否滿足需求,剔除不合理部分,增加需要部分.最後,綜合成系統的解決方案,給出要開發的系統的詳細邏輯模型(做什麼的模型).
制訂規格說明書
即編制文檔,描述需求的文檔稱為軟體需求規格說明書.請注意,需求分析階段的成果是需求規格說明書(好象軟考曾經考過這個問題),向下一階段提交.
評審
對功能的正確性,完整性和清晰性,以及其它需求給予評價.評審通過才可進行下一階段的工作,否則重新進行需求分析。 四、需求分析的方法需求分析的方法有很多.這里只強調原型化方法,其它的方法如:結構化方法,動態分析法等(個人認為,對初學者不必深究這些方法,實際上我也從來沒用過這些方法)在此不討論.
原型化方法是十分重要的(是軟考等常考的知識點).原型就是軟體的一個早期可運行的版本,它實現了目標系統的某些或全部功能.
原型化方法就是盡可能快地建造一個粗糙的系統,這系統實現了目標系統的某些或全部功能,但是這個系統可能在可靠性,界面的友好性或其他方面上存在缺陷.建造這樣一個系統的目的是為了考察某一方面的可行性,如演算法的可行性,技術的可行性,或考察是否滿足用戶的需求等.如,為了考察是否滿足用戶的要求,可以用某些軟體工具快速的建造一個原型系統,這個系統只是一個界面,然後聽取用戶的意見,改進這個原型.以後的目標系統就在原型系統的基礎上開發.
原型主要有三種類型(軟考考過):探索型,實驗型,進化型.探索型:目的是要弄清楚對目標系統的要求,確定所希望的特性,並探討多種方案的可行性.實驗型:用於大規模開發和實現前,考核方案是否合適,規格說明是否可靠.進化型:目的不在於改進規格說明,而是將系統建造得易於變化,在改進原型的過程中,逐步將原型進化成最終系統。
在使用原型化方法是有兩種不同的策略:廢棄策略,追加策略.廢棄策略:先建造一個功能簡單而且質量要求不高的模型系統，針對這個系統反復進行修改,形成比較好的思想,據此設計出較完整,准確,一致,可靠的最終系統.系統構造完成後,原來的模型系統就被廢棄不用.探索型和實驗型屬於這種策略。
追加策略:先構造一個功能簡單而且質量要求不高的模型系統，作為最終系統的核心,然後通過不斷地擴充修改,逐步追加新要求，發展成為最終系統。進化型屬於這種策略.
7. 項目需求說明書,怎麼寫
一 ：引言
1、編寫目的：說明編寫這份項目需求說明書的目的，指出預期的讀者。
2、背景說明：待開發的軟體系統的名稱。本項目的任務提出者、開發者、用戶及實現該軟體的計算中心或計算機網路。該軟體系統同其他系統或其他機構的基本的相互來往關系。
3、定義
列出本文件中用到的專門術語的定義和外文首字母組詞的原片語。
4、參考資料
列出用得著的參考資料，項目相關的計劃書，或者合同，批文之類的。
二：任務概述
1、目標
敘述該項目開發的意圖、應用目標、作用范圍以及其它應向讀者說明的有關該軟體開發的背景材料。解釋被開發軟體與其它有關軟體之間的關系。如果本軟體產品是一項獨立的軟體，而且全部內容自含，則說明這一點。
2、用戶的特點
列出本項目的最終用戶的特點，充分說明操作人員、維護人員的教育水平和技術專長，以及本軟體的預期使用頻度。這些是軟體設計工作的重要約束。
3、假定和約束
列出進行本軟體開發工作的假定和約束，例如經費限制、開發期限等。
三：需求規定
1、對功能的規定
用列表的方式（例如IPO表即輸入、處理、輸出表的形式），逐項定量和定性地敘述對軟體所提出的功能要求，說明輸入什麼量、經怎樣的處理、得到什麼輸出，說明軟體應支持的終端數和應支持的並行操作的用戶數。
2、對性能的規定：精度說明對該軟體的輸入、輸出數據精度的要求，可能包括傳輸過程中的精度。時間特性要求：說明對於該軟體的時間特性要求。
四：運行環境規定
1、設備
列出運行該軟體所需要的硬體設備。說明其中的新型設備及其專門功能。
2、支持軟體
列出支持軟體,包括要用到的操作系統、編譯（或匯編）程序、測試支持軟體等。
3、介面
說明該軟體同其他軟體之間的介面、數據通信協議等。
4、控制
說明控制該軟體的運行的方法和控制信號，並說明這些控制信號的來源。
五 數據要求
數據的邏輯描述：
對數據進行邏輯描述時可把數據分為動態數據和靜態數據。所謂靜態數據，指在運行過程中主要作為參考的數據，它們在很長的一段時間內不會變化，一般不隨運行而改變。所謂動態數據．包括所有在運行中要發生變化的數據以及在運行中要輸入、輸出的數據。進行描述時應把各數據元素邏輯地分成若干組，列如函數、源數據或對於其應用更為恰當的邏輯分組。給出每一數據元的名稱（包括縮寫和代碼）、定義（或物理意義）度量單位、值域、格式和類型等有關信息。
(7)產品開發資源需求怎麼填寫擴展閱讀
需求分析也稱為軟體需求分析、系統需求分析或需求分析工程等，是開發人員經過深入細致的調研和分析，准確理解用戶和項目的功能、性能、可靠性等具體要求，將用戶非形式的需求表述轉化為完整的需求定義，從而確定系統必須做什麼的過程。
參考資料
網路-需求分析
8. 如何寫一份易用的產品需求文檔
產品需求文檔分很多種，這里我只說一種讓程序員看起來舒服的需求文檔格式吧：
作為程序員，在需求文檔當中，最關注的內容是哪幾種呢？
1、流程：包括業務流程和基本流程；
2、數據：包括輸入數據和展示數據；
3、事件流：特別是分支事件流和例外事件流，感覺很多需求文檔中，缺少了這部分；
那麼，文檔的模板是怎麼樣的呢？
1、需求說明：主要闡述為什麼要做這個需求；
2、業務流程：最好使用VISIO來繪制，畫出整個業務的流程圖，特別是其中所要涉及的判定，分支等，都要畫出來，越詳細越好；
3、基本流程：繼續使用VISIO，畫出基本流程即可，一般來說都是業務流程中的最主要部分，但是可以加入更多的細節；
4、分支事件流：VISIO，各種分支事件的詳細流程，越詳細越好；
5、例外事件流：這里要使用表格，示例如下：主要是系統判定和對應的提示；6、輸入數據：用戶可以輸入數據的欄位，已經相應的定義，包括是否必填，欄位長度，錄入方式，對應規則等；
7、顯示數據：頁面顯示給用戶的數據，對應的欄位，取數規則，對應規則等;
8、補充說明；這個需求文檔模板，更傾向於傳統的軟體模板，而不是網路上比較流行的AXURE文檔。
9. 產品研發策劃怎麼寫
品牌策劃的基本步驟
1、品牌設計：是品牌定位的設計表現，設計的重點是讓顧客清楚地看到價值和興趣；包括品牌標志設計、品牌廣告語言設計、渠道形象設計。
2、品牌營銷：就是讓顧客知道並且能夠購買到品牌的產品或服務。讓顧客覺得他需要這樣的產品或服務；當他想買的時候，他知道在哪裡買，可以買。
3、品牌初創：品牌的產品或服務給顧客第一次嘗試。客戶進行了嘗試就是實現銷售，並建立了與品牌的關系，這很好，可以維持。
產品開發的關鍵節點：
1、產品管理部根據研發計劃編制具體的產品設計方案。
2、產品管理部針對產品設計方案，組織相關部門進行可行性論證，包括財務部、生產部、市場營銷部、采購部等，產品管理部根據論證意見，對產品設計方案進行修正。
3、產品管理部根據市場測試反饋的信息，進行樣品修改，以完善產品設計。
10. 如何寫新產品開發項目計劃書啊求教不勝感謝!
· 研究、開發、推出一項新的產品或服務，在現代企業制度條件下，項目計劃書的作用尤為重要，一個醞釀中的產品開發項目，不是至今還不存在的一個主觀概念，就是難以窺其全貌的稀缺事物，往往很模糊，通過制訂項目計劃書，可以使項目管理者對自己的項目有更清晰的認識，重大項目還要據此說服董事會，同時也可作為向銀行或其他投資者籌集資金的輔助文件。主要內容應包括：
一．產品介紹
1．產品的概念。
2．相關產品或被替代品正處於什麼樣的發展階段?
3．本產品的差異性或獨特性怎樣?
4．企業將本產品推向市場方法或渠道是什麼?
5．誰會使用本產品，為什麼?
6．研發成本之外，產品的生產成本是多少，售價是多少?
7．本產品的生命周期預測，有無升級、改良或創新的准備計劃?
二．市場分析
1．市場是否存在對這種產品的需求?需求程度是否可以給企業帶來所期望的利益?新產品的市場規模有多大?需求發展的未來趨向及其狀態如何?影響需求都有哪些因素。
2．細致分析經濟、地理、職業以及心理等因素對消費者選擇購買本開發產品這一行為的影響，以及各個因素所起的作用。
3．推出一個主要的營銷計劃，計劃中應列出本企業打算開展廣告、促銷以及公共關系活動的地區，明確每一項活動的預算和收益。
4．產品的市場競爭力、預計的市場佔有率和市場前景預測。
5．策劃好新產品的品牌和專利。
三．生產條件
1．如何設計或改良生產線，如何製造或組裝產品?
2．新產品生產需要哪些原料?企業擁有那些生產資源，還需要什麼生產資源?
3．生產和設備的成本是多少?
4．怎樣保證新產品在進入規模生產時的穩定性和可靠性。
5．生產周期標準的制定以及生產作業計劃的編制。
6．質量控制的方法是怎樣的。
7．解釋與產品製造、組裝、儲存以及發送有關的固定成本和變動成本的情況。
四．項目團隊
1．組織結構設計。
2．崗位職責說明。
3．項目經理自己的背景、經歷、經驗和特長等。
3．介紹主要研發人員的特殊才能、特點和造詣。
五．財務規劃
著眼於一項新技術或創新產品的創業企業不可能參考現有市場的數據、價格和營銷方式。因此，它要自己預測所進入市場的成長速度和可能獲得純利，並把它的設想、管理隊伍和財務模型推銷給決策者和投資者。
1． 商業計劃書的條件假設。
2． 預計的資產負債表。
3． 預計的損益表。
4． 現金收支分析。
5． 資金的來源和使用。