小程序開發需求文檔怎麽寫（小程序開發工作內(nèi)容）

本篇文章(zhāng)給大家談談小程序開發需求文檔怎麽寫，以及小程序開發工作內(nèi)容對應的(de)知識點，希望對各位有(yǒu)所幫助，不要忘了收藏本站喔。

本文目錄一(yī)覽：

• 1、美團小程序功能設計（需求文檔）
• 2、幫客戶做(zuò)了一(yī)個小程序，客戶需要一(yī)份開發文檔，文檔裏需要寫什麽內(nèi)容
• 3、PRD：「FITLIFE」小程序産品需求文檔（用戶端）

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

         墨刀連接： 

一(yī).需求背景

二.需求目的(de)及明細

三.業務流程

    3.1業務流程

    3.2頁面流程

四.功能詳細設計

    4.1交互設計

    4.2原型

五.考核指标

六.總結

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

使用投票(piào)聚餐一(yī)定是針對的(de)一(yī)個小群體，這個小群體一(yī)定是有(yǒu)一(yī)定關系的(de)，如(rú);同事，朋(péng)友，同學(xué)，家人等，基于上述理(lǐ)論對用戶-場景-需求分析：

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

創建流程 ：

編輯流程 ：

1.我(wǒ)的(de)

在我(wǒ)的(de)頁面中新增入口圖标，點擊後可(kě)進入投票(piào)聚餐

2.新增投票(piào)頁

頁面分為(wèi)新增投票(piào)模塊以及曆史投票(piào)模塊，曆史投票(piào)模塊以時間順序排列

創建投票(piào)：創建投票(piào)後進入選擇餐廳頁面

編輯：點擊編輯後，重新編輯此次記錄，進入确認頁面，可(kě)重新發起投票(piào)

3.選擇餐廳頁

選擇餐廳頁面分為(wèi)3個模塊，頂部的(de)搜索模塊，排序模塊以及商(shāng)家展示模塊。

排序模塊分為(wèi)4種篩選模式：

按照美食種類分類，其中默認為(wèi)全部美食，用戶點擊後出現下拉菜單，用戶可(kě)選擇美食分類（如(rú)：食品保健，特色菜，福建菜等）

按照地(dì)理(lǐ)位置進行(xíng)排序，分類模塊按城市(shì)區域地(dì)理(lǐ)性标志劃分，默認選擇為(wèi)附近

為(wèi)用戶篩選的(de)常用關鍵字排序，分為(wèi)：智能排序，離(lí)我(wǒ)最近，好評優先，銷量最高(gāo)，默認為(wèi)智能排序

按照餐廳服務以及用餐人數為(wèi)用戶進行(xíng)篩選，默認狀态為(wèi)關閉

确認添加：點擊确認添加後，進入确認頁

添加商(shāng)戶：點擊加号添加商(shāng)戶，再此點擊取消添加商(shāng)戶

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

已添加商(shāng)戶:點擊後進入展開已添加商(shāng)戶，可(kě)以對已添加商(shāng)戶進行(xíng)删除

4.确認頁

确認頁分為(wèi)主題元素，商(shāng)戶展示模塊

主題默認為(wèi)系統填寫，用戶點擊後可(kě)進行(xíng)修改

生成投票(piào)分享好友：點擊後進入好友頁

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

删除商(shāng)家：點擊後删除商(shāng)家

5.結果頁

模塊分為(wèi)主題模塊，商(shāng)戶展示模塊以及出現在商(shāng)戶暫時模塊下面的(de)統計模塊

投票(piào)：點擊投票(piào)按鈕投票(piào)，再次點擊取消投票(piào)；用戶若已選擇商(shāng)戶，在點擊其他商(shāng)戶的(de)投票(piào)按鈕将自(zì)動取消已選的(de)上加商(shāng)戶。

随機(jī)功能：場景為(wèi)當出現平票(piào)時為(wèi)用戶随機(jī)一(yī)家商(shāng)戶，沒有(yǒu)操作權限，任何人都可(kě)以操作，但點擊一(yī)次後默認10分鍾後才能再次點擊，随機(jī)結果将一(yī)直展現，直到下次随機(jī)出現新的(de)結果

回首頁：點擊後返回首頁

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

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

2.對投票(piào)聚餐的(de)入口，新增投票(piào)以及生成投票(piào)分享好友進行(xíng)埋點，統計訪問人數，分别計算轉化率。是考核功能的(de)轉換率，用戶流入入口的(de)數據，是判斷這個需求是真需求還是僞需求的(de)根本。

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

總結

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

幫客戶做(zuò)了一(yī)個小程序，客戶需要一(yī)份開發文檔，文檔裏需要寫什麽內(nèi)容

分三段，一(yī)，開發用途或小程序目标需求（可(kě)以多寫點，怎麽寫漂亮(liàng)就怎麽寫）二，編寫過程，就是編程用了什麽，（簡單點，專業的(de)沒人看的(de)懂），三總結性的(de)，小程序上線測試，得到的(de)一(yī)些數據。

PRD：「FITLIFE」小程序産品需求文檔（用戶端）

筆(bǐ)者通過産品概況、産品結構、業務流程圖、全局說明、功能性需求、非功能性需求分析等模塊，系統輸出這一(yī)份關于“FITLIFE”小程序用戶端的(de)産品需求文檔。

Hi~最近在對自(zì)己參與過的(de)項目進行(xíng)總結，希望可(kě)以和(hé)大家分享學(xué)習交流。輸出內(nèi)容是檢視(shì)自(zì)己的(de)方式，所以我(wǒ)就來吸取經驗了。

通過研讀各位優秀作者的(de)精品，我(wǒ)學(xué)習到了不少知識。此次，以實際工作中遇到的(de)情況作為(wèi)案例，我(wǒ)将從0至1的(de)産品中抽取重點模塊進行(xíng)分享。

為(wèi)了閱讀體驗，我(wǒ)将盡量簡化常規化的(de)環節，本次采用AXURE梳理(lǐ)PRD——利用AXURE動态面闆和(hé)內(nèi)聯框架，制作文檔導航，提高(gāo)浏覽人員的(de)閱讀效率。

一(yī)、概述

1. 産品介紹

2. 文檔修訂記錄

将重點模塊添加對應的(de)跳轉鏈接，方便浏覽人員迅速定位內(nèi)容。

版本号規則：小數點後為(wèi)當前版本的(de)小更新，小數點前為(wèi)大版本更新。

修訂屬性：新增、修改、删除

二、産品結構

1. 信息結構圖

2. 功能結構圖

由于完整結構圖展開占很大的(de)篇幅并且看不清楚，為(wèi)了閱讀體驗，對結構圖部分收縮。完整版結構圖可(kě)在AXURE中查看。

三、業務流程圖

建議将流程圖統一(yī)整理(lǐ)至表格中，做(zuò)成鏈接跳轉形式，實現快速查閱。為(wèi)了順暢的(de)需求閱讀體驗，将各自(zì)的(de)流程圖放在之後的(de)需求描述部分中展示。

四、全局說明

1. 名詞術語說明

2. 權限彈窗

3. 時間距離(lí)規範

3.1 時間規範

3.2 距離(lí)規範

4. 異常情況

4.1 網絡異常

手機(jī)網絡連接異常，小程序彈窗提示如(rú)下：

4.2 用戶狀态說明

五、功能性需求說明

良好的(de)需求閱讀體驗需要保證閱讀過程是順暢的(de)。

在這部分，首先列出【需求清單】，總覽這次需求涉及的(de)模塊及簡要信息。緊接着，按照【需求模塊】-【流程圖】-【原型頁面流轉】-【原型需求拆解】的(de)叙述邏輯去(qù)完成各個模塊的(de)需求說明。

1. 需求池需求清單

1.1 需求管理(lǐ)池

需求類型：新增需求、需求調整、功能優化、BUG修複、UI優化

系統：涉及到的(de)系統及模塊

需求說明：簡述需求

優先級判斷：重要緊急、重要但不緊急、緊急但不重要、既不緊急也不重要（ps：我(wǒ)們(men)要經常關注重要但不緊急的(de)任務進度，避免重要緊急任務紮堆出現。）

1.2 需求清單

對需求管理(lǐ)池評估篩選後，将需求模塊、對應功能、需求優先級、完成情況統一(yī)整理(lǐ)到表格中。同樣的(de)，這裏将模塊名稱做(zuò)成鏈接格式，快速查閱對應的(de)需求模塊。

優先級規範：p1、p2......數字越小代表優先級越高(gāo)。

2. 新用戶首頁模塊

2.1 新用戶登錄流程圖

2.2 新用戶登錄原型（點擊查看大圖）

2.3 首頁

3. 預約團課模塊

3.1 團課預約流程圖

3.2 團課預約頁面流轉

3.2 課程列表頁

3.3 課程詳情頁

3.4 預約課程頁

4. 預約私教模塊

4.1 私教預約流程圖

4.2 私教預約頁面流轉

4.3 私教列表頁

4.4 私教詳情頁

4.5 私教預約頁

5 購卡模塊

5.1 購卡流程圖

5.2 購卡頁面流程

5.3 購買儲值卡頁面

6. 我(wǒ)的(de)模塊（個人中心）

6.1 個人頁面

6.2 修改資料

6.3 我(wǒ)的(de)卡包

6.4 我(wǒ)的(de)課程包

6.5 我(wǒ)的(de)優惠券

6.6 富文本頁面

六、非功能性需求

非功能性需求，是比較容易忽視(shì)的(de)部分，往往和(hé)性能、安全挂鈎，影響着産品的(de)穩定性與安全性。

以下僅僅是例子(zǐ)，具體方案需要根據業務情況和(hé)産品特性與相關人員深入溝通。

1. 性能需求

響應時間：系統對請求做(zuò)出響應的(de)時間。例如(rú)系統處理(lǐ)一(yī)個HTTP請求需要200ms，這個200ms就是系統的(de)響應時間。

并發用戶數：同時承載正常使用系統功能的(de)用戶數量。

與性能相關的(de)數據指标還有(yǒu)QPS（每秒響應請求數）、TPS（每秒處理(lǐ)的(de)事務數）等。

性能需求這部分僅僅是舉個例子(zǐ)，具體情況和(hé)數據方案，需要和(hé)相關人員深入溝通。

2. 可(kě)用性需求

避免用戶高(gāo)頻點擊無反饋的(de)情況。

為(wèi)用戶提供反饋渠道(dào)。

保持文案與組件的(de)一(yī)緻性。

3. 數據統計需求

産品初期需要一(yī)定基礎的(de)數據提供支持，因此，除了小程序官方數據統計平台，再接入第三方統計平台，統計以下事件的(de)數據及路徑轉化率。

七、思考總結

1. 內(nèi)容細節

流程圖和(hé)頁面流轉圖要整齊統一(yī)，實在太多信息，建議用子(zǐ)流程模塊和(hé)多頁面分述解決。見過很多像“蜘蛛網”一(yī)樣的(de)圖，閱讀體驗比較糟糕。

盡量讓用戶不用點開大圖就能看清內(nèi)容，本篇部分頁面流轉圖和(hé)頁面需求也難免遇到這類問題。

異常邏輯和(hé)toast彈窗等細節需要加強把控，本篇這部分還是有(yǒu)所欠缺。

2. 高(gāo)保真or低(dī)保真？

低(dī)保真線框圖：重點在于功能、結構、流程的(de)梳理(lǐ)，利用簡單的(de)框架和(hé)元素，省時省力；但細節相對高(gāo)保真沒這麽完善，可(kě)能會有(yǒu)一(yī)定的(de)溝通成本。

高(gāo)保真：針對于高(gāo)層領導及投資人等，進行(xíng)産品概念演示，視(shì)覺效果好，細節相對完善；相當于是一(yī)個産品的(de)demo，但修改成本較高(gāo)。

原型交互做(zuò)的(de)很酷炫，證明你對工具非常熟練。但如(rú)果為(wèi)了做(zuò)交互花費了大量的(de)時間，就得考慮時間成本值不值得。如(rú)果能夠用簡單的(de)注釋和(hé)跳轉，清晰表達交互邏輯，會不會省時省力一(yī)些？

具體情況具體分析，比如(rú)，你做(zuò)了很多交互，開發做(zuò)漏了會說：“沒寫清楚啊，我(wǒ)怎麽知道(dào)哪裏可(kě)以點擊呢(ne)？”

因此，我(wǒ)的(de)習慣是做(zuò)簡單的(de)“交互邏輯+交互注釋”，盡量避免複雜且耗時耗力的(de)交互。

當然，重要核心的(de)交互邏輯，繪制出來比文字說明更容易理(lǐ)解。這時候，如(rú)果有(yǒu)現成的(de)組件就套用，如(rú)果沒有(yǒu)，就采用“圖+文字+口述”的(de)方式表達清楚。

3. WORD？AXURE？

需求文檔用什麽工具寫比較好？

這是我(wǒ)見過比較多的(de)産品話題讨論之一(yī)——有(yǒu)用WORD的(de)，有(yǒu)用AXURE的(de)，還有(yǒu)用墨刀、石墨文檔等等......

我(wǒ)曾經請教過兩位分别使用WORD和(hé)AXURE撰寫需求文檔的(de)朋(péng)友，他們(men)是這樣的(de)看法：

WORD選手：

用word寫，形式更規範。

結構大綱清晰，細節到位。

洋洋灑灑幾十頁，滿足感杠杠滴。

AXURE選手：

用AXURE寫，圖+标注+交互，更直觀地(dì)表達産品需求，閱讀更順暢。

預覽方便，支持上傳雲端同步。

WORD寫了也沒人有(yǒu)耐心看，這個世界很浮躁啊。

我(wǒ)的(de)看法：

需求文檔是幫助傳達及溝通需求的(de)工具，講究的(de)是“可(kě)讀性”。所以，在選擇采用什麽方式之前，需要和(hé)團隊溝通達成共識，即什麽樣的(de)方式能給到他們(men)更好的(de)閱讀體驗。

我(wǒ)在實際工作中，采用的(de)是AXURE，整理(lǐ)需求與線框圖後與團隊溝通，實現需求快速流轉更新。但我(wǒ)會選擇再用WORD梳理(lǐ)一(yī)遍，利用文字梳理(lǐ)大綱結構，整理(lǐ)産品邏輯和(hé)需求，能夠發現某些疏漏的(de)環節，完善産品細節。因此，用WORD寫，是一(yī)個良好的(de)查漏補缺的(de)手段，是檢視(shì)自(zì)身邏輯的(de)過程。

最後，由于篇幅關系，本次分享隻展示了部分內(nèi)容，完整預覽請在以下鏈接查閱。

預覽鏈接：

希望自(zì)己能堅持輸出內(nèi)容，定期複盤，與優秀的(de)你們(men)碰撞更棒的(de)想法，共同進步~

關于小程序開發需求文檔怎麽寫和(hé)小程序開發工作內(nèi)容的(de)介紹到此就結束了，不知道(dào)你從中找到你需要的(de)信息了嗎 ？如(rú)果你還想了解更多這方面的(de)信息，記得收藏關注本站。