今天給各位分享功能需求詳細設計文檔的知識，其中也會對功能需求描述進行解釋，如果能碰巧解決你現(xiàn)在面臨的問題，別忘了關注本站，現(xiàn)在開始吧！

本文目錄一覽：

• 1、美團小程序功能設計（需求文檔）
• 2、如何寫詳細設計文檔
• 3、軟件開發(fā)的需求文檔要具備哪些要素，格式如何？
• 4、產品需求文檔應該包含哪些內容

美團小程序功能設計（需求文檔）

? ? ? ? ?墨刀連接：?

一.需求背景

二.需求目的及明細

三.業(yè)務流程

? ? 3.1業(yè)務流程

? ? 3.2頁面流程

四.功能詳細設計

? ? 4.1交互設計

? ? 4.2原型

五.考核指標

六.總結

公司最近想把用戶約見這個場景在微信小程序上做深做透，基于這個業(yè)務訴求，設計聚餐投票的功能，便微信群用戶在線下聚會前，能先在線上把大家喜歡的美團店鋪匯總在一起，然后投票決策聚會去吃哪個店，可以節(jié)約用戶的時間成本。

使用投票聚餐一定是針對的一個小群體，這個小群體一定是有一定關系的，如;同事，朋友，同學，家人等，基于上述理論對用戶-場景-需求分析：

需求目的：完整的投票聚餐功能，選擇商戶到統(tǒng)計投票。解決用戶在聚餐選擇商家時意見不統(tǒng)一或者想要統(tǒng)計大家意見時的需求。

創(chuàng)建流程 ：

編輯流程 ：

1.我的

在我的頁面中新增入口圖標，點擊后可進入投票聚餐

2.新增投票頁

頁面分為新增投票模塊以及歷史投票模塊，歷史投票模塊以時間順序排列

創(chuàng)建投票：創(chuàng)建投票后進入選擇餐廳頁面

編輯：點擊編輯后，重新編輯此次記錄，進入確認頁面，可重新發(fā)起投票

3.選擇餐廳頁

選擇餐廳頁面分為3個模塊，頂部的搜索模塊，排序模塊以及商家展示模塊。

排序模塊分為4種篩選模式：

按照美食種類分類，其中默認為全部美食，用戶點擊后出現(xiàn)下拉菜單，用戶可選擇美食分類（如：食品保健，特色菜，福建菜等）

按照地理位置進行排序，分類模塊按城市區(qū)域地理性標志劃分，默認選擇為附近

為用戶篩選的常用關鍵字排序，分為：智能排序，離我最近，好評優(yōu)先，銷量最高，默認為智能排序

按照餐廳服務以及用餐人數(shù)為用戶進行篩選，默認狀態(tài)為關閉

確認添加：點擊確認添加后，進入確認頁

添加商戶：點擊加號添加商戶，再此點擊取消添加商戶

搜索：點擊搜索頁進入搜索頁面

已添加商戶:點擊后進入展開已添加商戶，可以對已添加商戶進行刪除

4.確認頁

確認頁分為主題元素，商戶展示模塊

主題默認為系統(tǒng)填寫，用戶點擊后可進行修改

生成投票分享好友：點擊后進入好友頁

添加喜歡餐廳：點擊后進入選擇餐廳頁，無人員限制

刪除商家：點擊后刪除商家

5.結果頁

模塊分為主題模塊，商戶展示模塊以及出現(xiàn)在商戶暫時模塊下面的統(tǒng)計模塊

投票：點擊投票按鈕投票，再次點擊取消投票；用戶若已選擇商戶，在點擊其他商戶的投票按鈕將自動取消已選的上加商戶。

隨機功能：場景為當出現(xiàn)平票時為用戶隨機一家商戶，沒有操作權限，任何人都可以操作，但點擊一次后默認10分鐘后才能再次點擊，隨機結果將一直展現(xiàn)，直到下次隨機出現(xiàn)新的結果

回首頁：點擊后返回首頁

添加喜歡餐廳：點擊后進入餐廳選擇頁，選擇完畢后直接進入到結果頁。

1.考察用戶日活增長指數(shù)：當天日貨量-前一天的日活量/前一天的日活量x100%。投票聚餐是有分享屬性存在的，純在分享屬性，進入小程序的用戶數(shù)應相應增多。

2.對投票聚餐的入口，新增投票以及生成投票分享好友進行埋點，統(tǒng)計訪問人數(shù)，分別計算轉化率。是考核功能的轉換率，用戶流入入口的數(shù)據(jù)，是判斷這個需求是真需求還是偽需求的根本。

3.使用流程轉化率：新增投票訪問人數(shù)/投票聚餐的訪問人數(shù)x100%，生成投票分享好友訪問人數(shù)/投票聚餐的訪問人數(shù)x100%。此數(shù)據(jù)是對流程的考察，用戶是否覺得流程好用，從此數(shù)據(jù)能夠得出一定的結論。

總結

投票聚餐是針對于當代年輕人常出現(xiàn)的聚餐場景，由于每個人都有自己的喜好而出現(xiàn)的意見不統(tǒng)一的需求，因此誕生出來的功能。此功能要包含完整的投票流程，從選擇餐廳-投票，并需將選擇餐廳的分類功能盡量做詳細，給用戶更多的參考意見。此功能完成后，用戶日活應有一定程度的增長。

如何寫詳細設計文檔

在大多數(shù)軟件項目中，要末不作詳細設計，要么開發(fā)完成后再補詳細設計文檔，質量也不容樂觀，文檔與系統(tǒng)往往不能同步，使詳細設計文檔完全流于形式，對工作沒有起到實際的幫助。

·

詳細設計是相對概要設計而言的，是瀑布開發(fā)流程的一個重要環(huán)節(jié)，在概要設計的高層設計的基礎上，從邏輯上實現(xiàn)了每一模塊的功能，是編碼階段的主要參考資料，是從高層到低層、逐步精化思想的具體實現(xiàn)。

詳細設計文檔的內容包括各個模塊的算法設計，

接口設計，

數(shù)據(jù)結構設計，交互設計等。必須寫清楚各個模塊/接口/公共對象的定義，列明各個模塊程序的

各種執(zhí)行條件與期望的運行效果，還要正確處理各種可能的異常。

·

在開發(fā)過程中，由需求及設計不正確、不完整所導致的問題是項目進度拖延、失敗的一個主要因素，而軟件系統(tǒng)的一個重要特性就是需求和設計的不斷構建和改進，在寫詳細設計文檔過程中，

詳細設計實際上是對系統(tǒng)的一次邏輯構建，可以有效驗證需求的完整性及正確性。

如果不寫詳細設計文檔，一般就從概設直接進入編碼階段，這時開發(fā)人員所能參考的資料就是需求規(guī)格說明書及頁面原型、數(shù)據(jù)庫設計等，不能直接進行開發(fā)，需要進行信息的溝通，把頁面原型不能體現(xiàn)的設計講清楚，這樣既容易遺忘，也容易發(fā)生問題，詳細設計文檔可以作為需求人員、總體設計人員與開發(fā)人員的溝通工具，把靜態(tài)頁面無法體現(xiàn)的設計體現(xiàn)出來，包含整體設計對模塊設計的規(guī)范，體現(xiàn)對設計上的一些決策，例如選用的算法，對一些關鍵問題的設計考慮等等，使開發(fā)人員能快速進入開發(fā)，提高溝通效率，減少溝通問題。

對于系統(tǒng)功能的調整，后期的維護，詳設文檔提供了模塊設計上的考慮、決策，包括模塊與整體設計的關系、模塊所引用的數(shù)據(jù)庫設計、重要操作的處理流程、重要的業(yè)務規(guī)則實現(xiàn)設計等等信息，提供了對模塊設計的概述性信息，闡明了模塊設計上的決策，配合代碼注釋，可以相對輕松讀懂原有設計。

·存在的問題要由專門的人寫，是比較麻煩的，也是很需要時間的，會對進度造成壓力，也容易形成工作瓶頸，使設計人員負擔過重，而開發(fā)人員無事可作。對于現(xiàn)在一般的以數(shù)據(jù)庫為中心的管理系統(tǒng)而言，這個工作始終是要作的，區(qū)別只不過是不是形成專門文檔，形成文檔可能會多花一兩周時間，但相對于規(guī)避的風險和問題來說，也是值得的，另外由于現(xiàn)在高級語言的流行，所以更詳細的設計應該直接體現(xiàn)在代碼的設計上，而文檔則只體現(xiàn)設計上的一些決策，協(xié)調整體設計與模塊設計的關系，把頁面原型所不能體現(xiàn)的設計情況文檔化，所以所花費的時間是有限的。

設計內容容易過細，但設計階段是不能考慮特別清楚地，時間也不允許。

對于這個問題，一個對策是上邊所提到的，文檔只體現(xiàn)設計上的決策，頁面原型所不能反映的信息，詳細設計只體現(xiàn)總體設計對模塊設計的一些考慮，例如對功能的數(shù)據(jù)庫設計等等，而具體的實現(xiàn)實現(xiàn)，則到代碼中再去實現(xiàn)，相關的設計也僅體現(xiàn)在代碼中。

需求、設計需要不斷的被更新、構建，則設計文檔需要不斷的重新調整，文檔的維護需要跟上，否則文檔和系統(tǒng)的同步就很難得到保障了，且造成多余的工作量。文檔的內容易流于形勢，質量糟糕，不能成為開發(fā)人員的參考手冊，一是要建立起相關制度，如有修改，先改文檔，后作開發(fā)，從工作流程上切實保障文檔與系統(tǒng)的同步，二是要規(guī)范文檔質量，對文檔該寫什么，不該寫什么，標準是什么，粒度是什么，語法應該如何組織，有明確的標準和考慮，同時，建立審計文檔評審、審核制度，充分保障系統(tǒng)的使用?！?/p>

首先是文檔的內容，根據(jù)項目和團隊的不同，詳細設計文檔的內容也有所不同，一般說來，粒度不宜過細，不能代替開發(fā)人員的設計和思考，但要把有關設計的決策考慮進去，包括與其他模塊、整體設計的關系、操作的處理流程，對業(yè)務規(guī)則的設計考慮等，有一個標準為，凡是頁面原型、需求規(guī)格說明書所不能反映的設計決策，而開發(fā)人員又需要了解的，都要寫入文檔。

其次是文檔所面向的讀者，主要為模塊開發(fā)人員、后期維護人員，模塊開發(fā)人員通過詳細設計文檔和頁面原型來了解所開發(fā)的功能，后期維護人員通過實際系統(tǒng)、模塊代碼、詳細設計文檔來了解一個功能。

再有就是誰來寫文檔，因為文檔主要考慮的是設計上的決策，所以寫文檔的人應該為負責、參加設計的技術經(jīng)理、資深程序員，根據(jù)團隊情況和項目規(guī)模、復雜度的不同，也有所不同。

還需要保證文檔的可讀性、準確性、一致性，要建立嚴格的文檔模板及標準，保證文檔的可讀性及準確性，同時建立審核及設計評審制度，來保障設計及文檔的質量，另外在工作流程中要強調，要先設計、先寫文檔，再進行開發(fā)。

軟件開發(fā)的需求文檔要具備哪些要素，格式如何？

需求文檔的編寫內容包括很多的，但是需要根據(jù)該軟件的規(guī)模和具體要求進行編寫。 一份比較完整的詳細需求分析應該包括：1. 前言 2. 摘要 3. 系統(tǒng)詳細需求分析 3.1. 詳細需求分析 3.1.1. 詳細功能需求分析 3.1.2. 詳細性能需求分析 3.1.3. 詳細信息需求分析 3.1.4. 詳細資源需求分析 3.1.5. 詳細組織需求分析 3.1.6. 詳細系統(tǒng)運行環(huán)境及限制條件需求分析 3.1.7. 信息要求 3.1.8. 性能要求 3.2. 接口需求分析 3.2.1. 系統(tǒng)接口需求分析 3.2.2. 現(xiàn)有軟、硬件資源接口需求分析 4. 總體方案設計4.1. 系統(tǒng)總體結構 4.1.1. 系統(tǒng)組成、邏輯結構 4.1.2. 應用系統(tǒng)結構 4.1.3. 支撐系統(tǒng)結構 4.1.4. 系統(tǒng)集成 4.1.5. 系統(tǒng)工作流程

.2. 分系統(tǒng)詳細界面劃分 4.2.1. 應用分系統(tǒng)與支撐分系統(tǒng)的詳細界面劃分 4.2.2. 應用分系統(tǒng)之間的界面劃分 5. 應用分系統(tǒng)詳細設計 5.1. XX分系統(tǒng)詳細需求分析 5.1.1. 功能詳細需求分析 5.1.2. 性能詳細需求分析 5.1.3. 信息詳細需求分析 5.1.4. 限制條件詳細分析 5.2. XX分系統(tǒng)結構設計及子系統(tǒng)劃分 5.3. XX分系統(tǒng)功能詳細設計 5.4. 分系統(tǒng)界面設計 5.4.1. 外部界面設計 5.4.2. 內部界面設計 5.4.3. 用戶界面設計 6. 數(shù)據(jù)庫系統(tǒng)設計 6.1. 設計要求 6.2. 信息模型設計 6.3. 數(shù)據(jù)庫設計 6.3.1. 數(shù)據(jù)訪問頻度和流量 6.3.2. 數(shù)據(jù)庫選型 6.3.3. 異構數(shù)據(jù)庫的連接與數(shù)據(jù)傳遞方式

6.3.5. 數(shù)據(jù)共享方式設計 6.3.6. 數(shù)據(jù)安全性及保密設計 6.3.7. 數(shù)據(jù)字典設計

8. 信息編碼設計 8.1. 代碼結構設計 8.2. 代碼編制 9. 關鍵技術 9.1. 關鍵技術的提出 9.2. 關鍵技術的一般說明 9.3. 關鍵技術的實現(xiàn)方案 10. 系統(tǒng)配置 10.1. 硬件配置 10.2. 軟件配置 11. 限制 12. 組織機構及人員配置 12.1. 機構調整與確認 12.2. 組織機構的任務和職責 12.3. 人員配置方案 12.4. 培訓計劃 13. 工程實施計劃 13.1. 分期實施內容 13.2. 進度計劃 13.3. 實施條件 13.4. 測試與驗收 14. 投資預算 15. 參考和引用資料

16. 術語

這里還有很需要補充的，也有很多是可以不寫的；因為一份需求文檔不是誰能寫的，呵呵，在實際的工作中

是那些負責人才能寫這個的。如果是課設的話，只要在流程圖 邏輯結構 或者是XX分系統(tǒng)的設計圖上下點功夫就好了。說到格式 就是按上面的寫 然自己弄一個目錄 就像是我們平時翻書的時候看到的那種，這樣好閱讀。

產品需求文檔應該包含哪些內容

我們先假如產品需求文檔（PRD）是一個產品，那么該如何做出一個擁有良好用戶體驗的PRD？

首先先來考察下PRD的用戶群體（User Persona）：主要是開發(fā)人員，在繁忙的開發(fā)任務中最希望看到“簡潔易懂”的產品需求文檔。

梳理下PRD的功能：

傳達出產品需求；

管理記錄產品迭代過程；

各部門共享產品信息，以促進溝通；

因此一個好的PRD的原則是：

結構清晰

語言簡潔易懂

實時共享

具體我們該如何制作？

答案很簡單——一個PRD文檔即可

現(xiàn)在，越來越多的產品經(jīng)理采用將文本說明和原型結合成一個PRD文檔的方式，因為之前的word+原型的方式管理起來繁瑣，而且還容易產生信息疏漏。

將原型和文本說明統(tǒng)一，直接分享一個鏈接，開發(fā)人員就能看到所有信息，是理想狀態(tài)。

多級導航結構展示PRD信息

通常來講，一個產品需求文檔里包含“產品概述”、“流程圖”、“功能詳情和原型”，“全局說明”，“非功能性需求”。

如何把這些內容清晰有條理地呈現(xiàn)在一個文檔里呢？使用一個網(wǎng)頁般的多級導航結構即可。

1、產品概述

產品概述部分用于展示文檔修訂歷史、版本說明、開發(fā)周期、和產品介紹。

「文檔修訂歷史」用來記錄產品經(jīng)理對該PRD文檔的修改狀況，也方便成員能及時了解到PRD是否有改動；

「版本說明」展示上線產品各版本的核心功能；

「開發(fā)周期」用于梳理開發(fā)、測試、上線的預計開始和結束日期。

「產品介紹」用來記錄產品名稱、簡介、用戶畫像、使用場景、產品定位等等。

（墨刀“PRD模版A”中的“版本信息”模塊，by 小龍）

2、流程圖

流程圖是產品經(jīng)理梳理產品邏輯和功能的一個思維Map，一般會有“功能結構圖’、“信息結構圖”、“任務流程圖”。

「功能結構圖」 展示產品的功能模塊，一般展開用戶可見的最小單元。

「信息結構圖」則是以信息為維度，用來描述有哪些數(shù)據(jù)字段，展現(xiàn)用戶信息/行為信息等。

「流程圖」記錄著用戶使用產品的路徑，也是一種產品線路圖，展示著產品的所有頁面及對應關系，有助于產品理解。

（墨刀“PRD模版A”中的“結構圖”模塊，by 小龍）

3、功能詳情和原型

這個模塊是開發(fā)人員查看頻率最高的模塊了。目前一種快捷高效的呈現(xiàn)方式便是“原型”+“注釋”。

圖文互補，把圖片傳遞不了的信息用文字補充清楚，比如產品的一些使用邏輯，方便同事理解。

使用墨刀的話，可以創(chuàng)建一個大的畫布，然后把墨刀制作的原型頁面粘貼到畫布里，并添加文字注釋，在關鍵位置有一些邊界條件的說明。

或者，直接在產品原型項目里通過“批注”添加注釋。

（“PRD模版A”中的“交互原型”模塊，直接嵌入了墨刀原型，by 小龍）

4、全局說明

這個頁面用來展示整個產品的設計規(guī)范，一些通用的規(guī)則可以附在這里。

對于這點，使用墨刀制作的方便之處在于：

可以直接把有關設計規(guī)范的原型項目通過網(wǎng)頁鏈接的方式嫁接過來，還能點擊“標注”查看各元素的細節(jié)信息。

（ 墨刀“PRD模版A”中的“全局說明”模塊，by 小龍）

5、非功能性需求

對于不同類型的產品，非功能性需求會有各種差異，一般會涉及到的有：

性能需求

系統(tǒng)需求

運營需求

安全需求

統(tǒng)計需求

財務需求

……

這部分就要自己按需要調整。

總結

PRD作為一種重要的公司內部溝通的文檔，能把必要的信息匯集在一個邏輯清晰的結構里是提高工作效率的一個優(yōu)勢。語言上的簡潔易懂，再結合可視化的結構圖和原型，都是為了增強易讀性，讓溝通更高效。

把PRD當作一個小產品去打磨一下，不是浪費時間，一個好的PRD文檔可以繼用很久。

墨刀新出了兩種產品需求文檔的模版，這兩種PRD里的各級頁面內容、導航和交互都為大家設計好了。

現(xiàn)在大家可以點擊“創(chuàng)建項目”，從墨刀模版中選取“產品需求文檔A”或者“產品需求文檔B”，點擊“使用模版”，再按照自家產品需要做一些更改就okay！

通過墨刀的分享鏈接還能直接讓公司內部人員在線實時同步PRD的更新，不用再擔心信息滯后或者文檔不兼容問題。

讓我們著手開始創(chuàng)建或者優(yōu)化您的產品需求文檔吧～

希望采納！謝謝！

配圖來自 ?“運維派”以及墨刀官網(wǎng)截圖

功能需求詳細設計文檔的介紹就聊到這里吧，感謝你花時間閱讀本站內容，更多關于功能需求描述、功能需求詳細設計文檔的信息別忘了在本站進行查找喔。