需求文件可能是很多產品的學習第一課，到底怎麼寫好乙份需求文件，還是要追根溯源從根本上說起
本著萬物可追溯，萬物可分解的原則，這個問題可以分解成三個問題
1、不寫行不行
推動需求落地的一般來說需要以下幾個步驟
1）前期溝通
2）宣講
3）原型+文件
4）後續溝通
所以原型+需求文件在整個落地過程中處於中流砥柱的位置，起的是承上啟下的作用
承上：階段性成果交付
啟下：定調（專案週期開始的標誌）
原型和文件之間互為補充，一起完成了這個任務，那要不要寫文件就要綜合考慮以下情況
1）考慮公司情況
每個公司的規模和制度不一樣，有些公司強制要求文件且有固定模板，這種就不能省了
有些公司強調敏捷開發，可能不會做太多要求
2）考慮需求型別
大需求還是小需求
流程優化還是頁面改動
為了節省溝通成本，一般大的需求還是要寫的
從表達力上來說
流程類需求更適合 流程圖+需求文件為主，原型為輔
頁面改動則原型為主，文件為輔，直接在原型上做標註，看起來也輕鬆些，不用兩個檔案來回對照
最終目的是為了將資訊有效的傳遞開，使整體效率達到最大化，這個傳遞的載體不限於原型、文件等任何形式，關鍵是根據情況來選擇合適的載體
2、寫了給誰看
完成乙個專案需要多方角色協作完成，一般來說，是以下幾個角色為主
ui、前端開發、後台開發、測試人員
首先提取共性，他們都需要知道的是什麼？
1）為什麼要做這個需求？解決了什麼問題或者實現了什麼目標？
2）需求內容是什麼？
3）做到什麼程度？未來是否有拓展和改進
如果是打磨很久的緊密合作型團隊好說，不過很多時候開發和運營之間會存在乙個壁壘，互相不了解彼此的工作情況，這個時候開發人員對這個需求究竟了解多少，也要考慮進去，充分敘述專案背景是很有必要的，只有大家的認知偏差足夠小，最後出來的成果才會更接近理想
上面說的是共性，不同的角色之間對乙個需求的側重點也是不一樣的
從上面各個角色的側重點可以總結出文件內容需要包括哪些東西
專案背景
預期目標
流程圖需求大綱
功能需求（需求內容、功能型別、極限情況處理）
非功能需求（效能要求、拓展性說明等）
像版本記錄（作者、時間、版本號、修改記錄）、設計規範（字型大小、全域性說明）、角色說明（目標人群）這種可以根據不同的專案、不同的情景選擇加入
3、怎麼寫比較好看？
好看有兩種含義
1）內容好看
其他人看文件的時候等於是跟著筆者的思路在走，如果邏輯混亂，東一榔頭西一棒子，看的人也就不知所云
乙個好的文件結構可以使內容看起來上下連貫、邏輯通順，有個好的文件結構這篇文件也就成功了一半
文件結構可以遵循由淺入深、由大及小的原則，增加內容的層次感，盡量避免上下文來回引用
而另外一半就在功能需求的詳細描述中，詳細寫功能需求的其實更考驗乙個人的提煉能力，盡量用準確簡潔的語言描述內容，避免大段文字，多用短句，多提煉123
2）頁面好看
而視覺效果上，清晰的目錄、統一的字型和行距、該加粗加粗、該換顏色換顏色、該用小標題就用小標題，這些都是不太花時間卻加分很多的東西，畢竟人都是視覺動物嘛
小結
汝欲學詩，功夫在詩外
這個道理放在這裡也行得通，在基於對需求的深刻理解前提下，前期的思考和準備也是一篇優秀的文件的必備工作，這些都想好了，真正去寫才能下筆如有神
初學的時候可以上網多找幾個模板，然後根據自己的專案情況進行刪改，這樣能最大程度避免錯漏，但是最根本的還是要知道為什麼要這麼寫，這樣遇到不同的專案和情景時才能做到有的放矢、鬆弛有度。
軟體需求文件範例 如何寫好PRD文件
圖2 5是撰寫prd文件的通用模板，整個模板框架主要分為六個部分 1.基本規範 2.文件概述 3.產品說明 4.功能說明 5.非功能說明，6.結尾附錄。前面小節中介紹brd 和mrd文件的撰寫方法時，建議統一採用ppt的表現形式來輸出，而prd文件的目的和閱讀物件決定了它更適合用傳統的word文件格...
如何寫好軟體文件
今天看到一篇介紹寫作技術文件的文章，試著翻譯了一下，翻得不好，請大家幫忙改正。正文如下 我不知道是不是有人會將閱讀或書寫技術文件當 好。雖然很討厭這樣做，但是通常為了解決問題或介紹乙個技術產品，我們不得不去做這些事情。要想寫好文件很難。技術文件有幾種形式 基本概覽，高階概覽，一步一步的演示，自動生成...
如何寫好乙份產品需求文件
二 產品概述 三 功能說明 四 其他產品需求 五 風險分析 六 相關文件 版本編號 修訂人修訂日期 修訂描述 1.0.0 2021.1.22 初步確定產品需求 確定產品需求的實現方案 此文件的目的主要是清晰 有條理的說明 平台應具備的相關功能以及開發需求。此文件主要描述 平台中前端頁面涉及到的功能點...