中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

我們接下來文章內容都是基于以上原則與前提，接下來正文開始~

二、需求文檔用啥寫

我們以終為始，先看需求文檔的呈現方式。目前主要有以下2類：

1. Axure一體化需求文檔

使用Axure將全部需求文檔，最終通過Axure打包提供出去。好處是方便查看，看原型的基礎上又能看文檔說明。但有一種不是很“嚴肅”的感覺。

2. Word版

通過Word進行需求描述，并統一提供。容易留存，也比較正規，在閱讀上以文字為主。

具體選擇那種方式，可以先看公司要求。

像我之前有公司要求，必須用word，就算是有大量原型的，也只能把頁面原型畫好，然后再復制到word里，在word寫需求內容。

如果沒有要求，具體采用的方式可以看不同的需求類型：

如果只涉及到畫原型的，可以使用Axure。

如果只有偏后端需求的，邏輯相關的需求，比如說是接口需求、算法需求，并不涉及到前端需求的，我們可以直接使用word寫。

如果是做的大項目，同時有功能需求，又有接口需求、算法需求的，我建議都放在一起，比如說都用Axure寫需求。

我之前做新項目的時候，同時提供了功能需求的axure文檔+word版的接口需求，后來用例評審的時候，測試說不知道word版接口需求，之后我就統一寫在axure里了。

三、需求文檔包含哪些內容

需求有大有小，同樣的需求文檔也有大有小，小到直接一句話描述，大到上百個原型頁面，好幾萬個字。

一句話的需求我們在這就不說了，我們說下正常的需求文檔。

不論是使用Axure還是word，也不論需求大小是什么，PRD文檔中一般需要包含以下內容：

1. 文檔修改記錄

需求文檔在需求評審、研發、測試過程中一定會改的。

比如說加個限制，補充個遺漏的邏輯等等，不過我們一定要記錄下修改內容，并及時更新需求文檔、及時同步項目成員。

一般通過表格展示出以下內容：

• 修改內容：說清楚修改的哪個模塊，哪個頁面、哪個功能點。當然也可以分成修改模塊、修改頁面多個列。
• 修改原因：就是為啥要修改，比如說邏輯缺失需要補充等等。
• 修改人：誰改的。
• 修改日期：修改時間。

在使用Axure時，我們可以在文檔修改記錄中加上文本鏈接跳轉，項目成員點擊文字可直接進入到對應頁面查看。

對于word，也是同樣的，加個文檔修改記錄。

對于文檔修改記錄，不僅在PRD文檔中可以用到，在寫其它文檔時都可以加上，比如操作手冊。

2. 項目背景 or 需求背景

背景同樣也是有大有小，對于新項目，則需要介紹下整個項目的大背景。對于每個需求，我們同樣也可以簡單說下需求背景。

參考格式如下：

當前的現狀是什么，有哪些問題/痛點，這些問題導致了什么結果，為了解決這個問題，我們需要采取什么動作，達到什么目的，能夠獲取哪些收益，產生什么價值。

3. 名詞解釋

如果有專業名詞，一定要寫上。

在不同行業、不同公司、不同團隊中都有專門的名詞，項目成員是不明白一些名詞的，這個時候一定要說明。

比如說抗菌藥物DDD值，絕對的專業名詞，不說一般沒人知道。

另外在說名詞解釋的時候，盡量加上示例說明方便大家快速理解。

4. 流程圖

當涉及跨角色、跨系統、跨模塊、多判斷邏輯時，我們一定要畫出來，讓各方更快地了解產品流程。

流程圖同樣有大有?。?/p>

包括整體產品業務流程圖、單個模塊的流程圖、單個功能的流程圖。

1）整體流程圖

為了將這個產品的功能業務串起來，可以不用畫的太詳細，畫出大的概覽圖，從大而全的角度將這個項目表達出來。

一般是在0-1的新項目中畫，日常迭代的需求中不需要。

2）單個模塊功能的流程圖

當一個功能模塊功能很多時，為了將模塊內的功能串起來，說清楚單獨模塊的流程，這個就要畫的細致一點。

當涉及到新的模塊時一定要畫。

3）單個功能的流程圖

對于復雜的單個功能，涉及到的處理邏輯比較多時，我們也需要畫出單獨的流程圖進行說明。

流程圖的類型有很多種，像業務流程圖、頁面流程圖、泳道圖、uml里的時序圖、用例圖等等。

我們可以基于不同流程圖的特性去選擇不同的類型，比如有多角色時，我們可以使用泳道圖。

對于UML，像用例圖、序列圖，在畫的時候有一定的門檻，同樣的一定會有團隊成員看不懂。我是從來沒畫過，所以大家可以自行選擇學習與繪制。

對于頁面流程圖，是表達出頁面之間的跳轉邏輯，像移動端的頁面，我們可以直接平鋪出每個頁面，展示出頁面間的跳轉邏輯。

對于PC端產品，頁面尺寸較大，我們可以通過頁面名稱展示出頁面流程。

流程圖的能夠達到業務清楚，表明重點，項目成員能夠快速理解的目的就行。

5. 需求說明

對需求的詳細說明，這一點肯定是必須的，我們下邊單獨說。

以上內容是我認為在寫需求文檔時，需要包含的內容，下邊的內容我們則可以自行選擇~

1）產品架構圖

在0-1產品搭建的時候進行展示，將整個產品抽象化，通過數據層、服務層、應用層、展現層等抽象層面表現出產品的整體架構。

來自Processon

產品架構圖是非常大的層面，當你沒有獨立負責一條業務線的時候，很難有這種大的架構概念。

當你需要規劃一條產品線的時候，可以畫出來產品架構圖，讓之后的產品方向再這個大的框架下去走。

我也是在最近這2年，獨立負責產品線的時候才開始繪制的，主要是和領導們匯報使用的。

具體怎么畫，大家可以在平臺上搜一下，有很多。

2）功能架構圖 or 信息架構圖

對于功能架構圖，就是寫清楚產品功能的層級架構，簡單說就是一級菜單、二級菜單是什么，每個菜單里有哪些功能，展示出功能的層級關系。

我一次都沒有畫過。

對于功能架構的展示，我一般在畫原型的時候規劃出來，然后直接畫原型。

當然也可以通過思維導圖的方式畫出來，但是吧，畫出來也沒人看。

還有一個信息架構圖，這個我也沒畫過。

我有很長的一段時候都沒整明白功能架構圖與信息架構圖有啥區別~

現在我的理解是：

• 功能架構圖是展示出功能層級關系，體現出菜單-功能的層級邏輯。
• 信息架構圖是展示出每個功能頁面內的展示字段內容，主要用于研發設計表結構與表字段。

對于功能架構圖和信息架構圖，一般是在產品0-1的時候畫，而且涉及到的內容比較多，多的內容一定沒人去看。

到底要不要畫是一方面，大家一定要知道功能結構圖和信息架構圖是個什么東西，具體畫不畫大家自行選擇。

四、畫原型寫文檔

需求類型里有一個功能需求，這個就是每個產品避免不了的，所以我們單獨說下畫原型+寫文檔~

1. 首先根據要做的需求范圍進行分類

當有多個需求類型時，按類型進行分類，使用Axure時可以通過建立文件夾。

使用word則可以加個一級標題。

目的是將需求有層級的依次展示出來。

然后在不同的文件夾下，在進行分級。

比如「功能需求說明」文件夾下有多個功能模塊，則按照模塊/菜單名稱建立子文件夾，然后再在每個模塊下建立對應頁面；

當同一個頁面內有多個tab頁/子頁面時：

對于PC端，我一般是分頁面說明；APP的頁面尺寸小，我們可以在一個Axure頁面內統一說明。

然后再對每個頁面單獨畫原型，寫文檔。

2. 需求文檔的表現方式

當采用Axure寫需求文檔的時候，常見的布局是：左圖右文。

左邊展示原型圖，右邊展示需求說明。

對于word版，常為：原型頁面展示，單獨寫文檔說明。

3. 提取公共邏輯，放入全局說明

在畫原型、寫文檔的時候，一定會有相同的功能邏輯、相同的需求邏輯。

例如說后臺系統，會有一堆的列表，列表就涉及到分頁數量、默認排序等。

我們可以直接統一使用全局說明。

將相同的功能邏輯、需求內容當在一個單獨的全局說明里，在全局說明里進行單獨說明。

當在某個頁面中需要說明的功能點已經在「全局說明」里存在時，可以加個說明：請見全局說明。

同時對文字添加文字跳轉鏈接，閱讀者點擊可直接跳轉到對應的全局說明頁面。

3. 功能點序號標注

先畫出原型圖，在原型中標注「序號」，然后在右側按照相同的序號進行功能需求描述。

• 標注順序：一般按照從左到右，從上到下的順序。
• 標注哪些點：需要進行功能說明的功能點，但是并不意味著每一個點都要進行標注。

我一般按照從大到小，按照模塊化的方式。

以下方的表單頁面為例：

當原型畫出后，在頁面上標個序號[1]，對頁面進行下簡介，一般說明頁面是什么，使用角色是誰。

然后繼續標注「返回」，對「返回」進行說明。

因為點擊返回時，沒有添加其它判斷邏輯（如是否二次確認），所以直接描述交互邏輯即可。

然后接著對下方的「患者信息」進行標注。

我們可以看到「患者信息」里有很多字段，我不建議對每個字段進行說明。

我們直接對「患者信息」整個模塊進行標注，然后對每個字段進行說明。

由于只是表單輸入，我們需要說明是否必填、采用什么組件、是能輸入文字、還是數字輸入框，數字范圍限制、數字小數點限制（如最多2位小數）、輸入小數點超過如何處理（是直接限制輸入，還是能四舍五入）、字符長度限制、當字符輸入超長如何處理。

如果是采用選擇框，選擇框里的值是寫死的，還是從哪里取值。

……

這就是對需求的描述，我們需要盡可能的寫全，就是盡可能的把考慮到的限制加上，你寫的越全，在評審的時候，才會少挨懟。之后的需求變更才會少。

（現在看其實上邊的需求描述還是不全，比如漏了小數點位數說明，文本輸入框內能不能輸入表情emoji符號等等）

當頁面內出現彈窗時，我們需要對彈窗里的內容進行說明，單獨對彈窗里功能點進行標注，然后再下方繼續對需求進行說明。

對于彈窗里的內容，我一般從「1」開始重新編號。不把序號順序和其他頁面夾雜在一起。當調整一個功能點后，需要重新編號，增加了多余的工作量。

4. 需求詳細書寫

對需求的詳細描述，是最核心的內容，我們可以按照下方的格式來寫：

• 標題：功能點名稱。
• 角色權限：如當前登錄用戶角色為管理員時，則顯示此按鈕。
• 規則邏輯：主要有校驗邏輯、前置條件、觸發時機等，當涉及到的校驗邏輯太多時，可以采用分行分段、添加序號、使用表格等方式，將每個邏輯有條理的全部說明清楚。

比如：確定按鈕。

當角色為「管理員」時，展示出確認按鈕；

1. 當XX未填寫時，按鈕顯示為禁用狀態，點擊時出現toast提示：請填寫XXX。
2. 當XXX、XXX全部填寫后，按鈕置為可點擊狀態，點擊后跳轉至XXX頁面。

極值說明：如輸入框輸入字符的長度，數字輸入的范圍值。

交互說明：如點擊調整至XXX頁面。

在寫需求時，根據不同的需求內容，盡可能的將全部內容寫清楚。

這個時候一定會有一個問題：寫不全。

我們可以明確一點，沒有產品經理把所有情況都考慮到，喬布斯、張小龍也考慮不了那么全。

我們需要做的是盡可能的考慮全，盡可能是個很虛的詞，受行業經驗、項目經驗等影響，不同級別的產品經理的需求文檔寫的水平很顯而易見，當然你考慮的越全面，產品能力可以說就越強。

我們可以在需求評審前，先和研發提前碰下，避免有大的遺漏。

也可以借助「需求自查表」來輔助，自查出遺漏的說明。

5. 其它

1）文字描述言簡意賅，避免口語化，別使用模棱兩可的文字。需求文檔里的內容必須明確，別寫「盡量」「盡快」。

2）添加示例：被誤解是表達者的宿命，文字說明都會有一定的片面理解，對于比較復雜的內容，我們可以添加示例說明：

同時在原型上，盡量使用貼合實際場景的內容。比如說時間別寫出：13:88:99。

3）為了便于閱讀，可以采用多分段，多分行，加序號的方式。

4）使用標點符號，將內容說清楚，如：點擊「確認」按鈕，跳轉至【XXX頁面】。

關于標點符號，大家可以看這個文章：https://zhuanlan.zhihu.com/p/359255980

5）結合axure的特性，添加文字鏈接，便于閱讀者快速跳轉查看，不用自己找。

添加「返回」按鈕，比如閱讀者跳轉到【全局說明頁面】，看完后，想在回到來源頁繼續看需求，我們可以在【全局說明頁面】中添加個「返回來源頁」按鈕，加個返回上一頁的交互，直接能返回。

6）對于變量值，使用特殊符號標記下

對于會變化的值，我一般使用用兩個百分號，如下方的‘科室名稱’，會根據不同的選擇展示不同的名稱，所以我就通過‘%科室名稱%’進行表示，然后單獨說明，并舉例說明。

7）重要內容進行標記

可以通過加粗、換個顏色等方式進行提醒，當內容較多的時候，大家很容易忽略掉，所以很有必要進行加粗加大標色提醒。

8）涉及到邏輯時，可以使用公式進行說明

如：當A+B≥100時，則XXXX。

9）寫完后自己再過一遍

就像上學做題后，自己zai再驗算一遍，在寫文檔的時候，自己肯定會有抽風的時候，不知道哪個地方就給寫錯了。

10、對外提供時，對于Axure，可以打包出html提供。

如果是word版本，可以提供出pdf版。

以上是對功能需求的說明，對于接口需求、性能需求、埋點需求等非功能性需求，當涉及到的時候，一定要寫上，不然就是需求遺漏了。

我之前一直以為產品經理只需要寫功能需求就夠了。

有一次讓我寫接口需求，我就很郁悶，這明明是技術的活，干嘛產品寫。后來，我明白了一件事，產品經理不往前站，之后就會是一堆坑。

除了接口需求，還是像研發數據庫建表時，這些我也建議產品經理去介入，因為表里有哪些字段，字段最大長度是多少，需要建哪些字段等等，都是和業務有關系的。

舉個示例，藥品的「規格」這個字段，研發把最大長度設置成250個字符，但是在實際業務上，「規格」會有2000個字的情況。

研發絕對是不理解的，所以最清楚這個情況的是產品，就需要提醒研發關注下。避免上線后，字數超長導致保存錯誤。

對于性能需求怎么寫，大家可以看這篇：《5000字詳解性能需求》。

對于接口需求、埋點需求等大家可以在平臺上搜一下，接口需求可以看：http://www.aharts.cn/pmd/2297401.html

總結

寫出好的需求文檔受很多方面的影響，從前期的需求分析，當確定業務流程，然后再到畫原型，最終把PRD寫出來，這里邊涉及到的內容非常非常多。

這篇文章是給大家提供的概述，大家可以在日常中總結積累，多和項目成員溝通，每一次需求評審就是一次淬煉，挨個一次懟后就總結，下次別再犯。

另外，當你把一篇完美的需求文檔交付后，一定會有研發、測試不看的，只會問，就不看文檔。我一般是“微笑服務”，把文檔內容截個圖發過去。