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

本文目錄一覽：

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

美團小程序功能設(shè)計（需求文檔）

? ? ? ? ?墨刀連接：?

一.需求背景

二.需求目的及明細

三.業(yè)務(wù)流程

? ? 3.1業(yè)務(wù)流程

? ? 3.2頁面流程

四.功能詳細設(shè)計

? ? 4.1交互設(shè)計

? ? 4.2原型

五.考核指標(biāo)

六.總結(jié)

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

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

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

創(chuàng)建流程 ：

編輯流程 ：

1.我的

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

2.新增投票頁

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

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

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

3.選擇餐廳頁

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

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

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

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

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

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

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

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

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

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

4.確認頁

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

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

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

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

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

5.結(jié)果頁

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

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

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

回首頁：點擊后返回首頁

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

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

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

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

總結(jié)

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

如何寫詳細設(shè)計文檔

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

·

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

詳細設(shè)計文檔的內(nèi)容包括各個模塊的算法設(shè)計，

接口設(shè)計，

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

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

·

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

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

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

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

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

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

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

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

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

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

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

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

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

需求文檔的編寫內(nèi)容包括很多的，但是需要根據(jù)該軟件的規(guī)模和具體要求進行編寫。 一份比較完整的詳細需求分析應(yīng)該包括：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. 總體方案設(shè)計4.1. 系統(tǒng)總體結(jié)構(gòu) 4.1.1. 系統(tǒng)組成、邏輯結(jié)構(gòu) 4.1.2. 應(yīng)用系統(tǒng)結(jié)構(gòu) 4.1.3. 支撐系統(tǒng)結(jié)構(gòu) 4.1.4. 系統(tǒng)集成 4.1.5. 系統(tǒng)工作流程

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

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

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

16. 術(shù)語

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

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

產(chǎn)品需求文檔應(yīng)該包含哪些內(nèi)容

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

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

梳理下PRD的功能：

傳達出產(chǎn)品需求；

管理記錄產(chǎn)品迭代過程；

各部門共享產(chǎn)品信息，以促進溝通；

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

結(jié)構(gòu)清晰

語言簡潔易懂

實時共享

具體我們該如何制作？

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

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

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

多級導(dǎo)航結(jié)構(gòu)展示PRD信息

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

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

1、產(chǎn)品概述

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

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

「版本說明」展示上線產(chǎn)品各版本的核心功能；

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

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

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

2、流程圖

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

「功能結(jié)構(gòu)圖」 展示產(chǎn)品的功能模塊，一般展開用戶可見的最小單元。

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

「流程圖」記錄著用戶使用產(chǎn)品的路徑，也是一種產(chǎn)品線路圖，展示著產(chǎn)品的所有頁面及對應(yīng)關(guān)系，有助于產(chǎn)品理解。

（墨刀“PRD模版A”中的“結(jié)構(gòu)圖”模塊，by 小龍）

3、功能詳情和原型

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

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

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

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

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

4、全局說明

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

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

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

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

5、非功能性需求

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

性能需求

系統(tǒng)需求

運營需求

安全需求

統(tǒng)計需求

財務(wù)需求

……

這部分就要自己按需要調(diào)整。

總結(jié)

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

把PRD當(dāng)作一個小產(chǎn)品去打磨一下，不是浪費時間，一個好的PRD文檔可以繼用很久。

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

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

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

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

希望采納！謝謝！

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

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