需求文檔(PRD文檔)
個人分類：?人人都是產(chǎn)品經(jīng)理
產(chǎn)品設(shè)計是一個由抽象的概念到具體形象化的處理過程，通過文字或圖像等方式將我們規(guī)劃的產(chǎn)品需求展現(xiàn)出來。它將產(chǎn)品的某種目的或需求轉(zhuǎn)換為一個具體的物理或工具的過程，把一種計劃、規(guī)劃設(shè)想、問題解決的方法，通過具體的操作，以理想的形式表達(dá)出來。
由于產(chǎn)品設(shè)計階段要全面確定整個產(chǎn)品策略、外觀、結(jié)構(gòu)、功能，從而確定整個產(chǎn)品系統(tǒng)的布局，因而，產(chǎn)品設(shè)計的意義重大，具有“牽一發(fā)而動全局”的重要意義。如果一個產(chǎn)品的設(shè)計缺乏具體形象的表述，那么研發(fā)時就將耗費(fèi)大量資源和勞動力來調(diào)整需求。相反，好的產(chǎn)品設(shè)計，不僅表現(xiàn)在功能上的優(yōu)越性，而且便于執(zhí)行時理解，從而使產(chǎn)品的研發(fā)效率得以增強(qiáng)。
產(chǎn)品設(shè)計的最終表述的形式被稱為產(chǎn)品需求文檔，業(yè)界常常稱呼為PRD文檔，這是英文Product Requirement Document的縮寫。產(chǎn)品需求文檔是將產(chǎn)品規(guī)劃和設(shè)計的需求具體形象化表述出來的一種展現(xiàn)形式，主要用于產(chǎn)品界面設(shè)計和研發(fā)使用。
PRD文檔是基于BRD、MRD的延續(xù)文檔，主要是一份給執(zhí)行層面的工作人員閱讀的文檔，這部分人群絕大多數(shù)是設(shè)計與技術(shù)人員。在這類人群中，設(shè)計師更多依賴于產(chǎn)品原型進(jìn)行交互或視覺的設(shè)計，因此看這份文檔的人主要是技術(shù)人員。相對于技術(shù)人員，他們不太關(guān)注產(chǎn)品的商業(yè)需求和市場愿景，因為在進(jìn)行產(chǎn)品討論立項時，產(chǎn)品的定義就已經(jīng)向參與設(shè)計和研發(fā)的人員宣講過，因此技術(shù)人員更多的是關(guān)注界面、功能、交互、元素等等內(nèi)容，因此產(chǎn)品需求文檔是一份詳細(xì)的產(chǎn)品功能需求說明文檔，是產(chǎn)品文檔中最底層和最細(xì)致的文檔。
因為閱讀人類的因素，所以產(chǎn)品需求文檔是一份沒有閑話，直入主題的功能說明文檔。并且產(chǎn)品需求文檔是沒有標(biāo)準(zhǔn)規(guī)范的，也沒有統(tǒng)一的模板，每個公司都不一樣和每個人也不一樣，這個取決于個人習(xí)慣和團(tuán)隊要求。雖然產(chǎn)品需求文檔沒有明確的規(guī)范，但是目的都是一樣的，必須能夠明確產(chǎn)品的功能需求，便執(zhí)行人員理解任務(wù)要求。
產(chǎn)品需求文檔是產(chǎn)品經(jīng)過規(guī)劃和設(shè)計之后的最終執(zhí)行文檔，因此這份文檔的質(zhì)量好壞直接影響到執(zhí)行部門是否能夠明確產(chǎn)品的功能和性能。
在寫產(chǎn)品需求文檔之前，我們需要先羅列出產(chǎn)品功能的信息內(nèi)容，這一步是將想法逐漸清晰的第一步，也是幫助我們接下來設(shè)計功能的輔助信息，同時也可以輔助服務(wù)端技術(shù)人員創(chuàng)建數(shù)據(jù)庫。因為這是第一步，所以我們不需要羅列的很詳細(xì)，在之后的步驟里，我們會逐步改進(jìn)和完善信息內(nèi)容。
羅列信息內(nèi)容的方式有很多種，文本形式、思維導(dǎo)圖形式等等都可以，最主要的是能夠清晰易懂，我最常用的方法就是使用思維導(dǎo)圖軟件(MindManager)羅列成結(jié)構(gòu)圖，因此我稱這一步為“信息結(jié)構(gòu)圖”。
上圖是一張以Blog系統(tǒng)為示例的信息結(jié)構(gòu)圖。信息結(jié)構(gòu)圖是一種接近數(shù)據(jù)庫結(jié)構(gòu)的圖表，在羅列信息結(jié)構(gòu)時，更多的是考慮信息數(shù)據(jù)，但是他并不是真正意義的數(shù)據(jù)庫結(jié)構(gòu)。信息結(jié)構(gòu)圖是提供給產(chǎn)品經(jīng)理自己梳理信息內(nèi)容的結(jié)構(gòu)圖，也是方便產(chǎn)品經(jīng)理和服務(wù)端技術(shù)人員溝通數(shù)據(jù)結(jié)構(gòu)的參考圖，技術(shù)人員會根據(jù)這張圖表的內(nèi)容再結(jié)合產(chǎn)品原型或需求文檔，然后規(guī)劃和設(shè)計出真正意義上的數(shù)據(jù)庫結(jié)構(gòu)。
信息結(jié)構(gòu)圖中關(guān)于友情鏈接功能的信息數(shù)據(jù)只有“名稱”和“鏈接”兩個內(nèi)容，但是在實(shí)際功能需求中，友情鏈接還有兩個功能，分別是“顯示或隱藏”和“是否新窗口打開”，這兩個功能會在產(chǎn)品原型和需求文檔中詳細(xì)描述，但是在信息結(jié)構(gòu)中是沒有體現(xiàn)的，因為從產(chǎn)品層面上來說，這兩個只是功能，并不是信息內(nèi)容。但是在真正數(shù)據(jù)庫中，友情鏈接的這兩個功能分別也是有字段參數(shù)的，程序在讀取該參數(shù)后便知道友情鏈接的屬性，然后處理友情鏈接是顯示還是隱藏，是新窗口打開還是本窗口打開。通過友情鏈接這個例子，我們就知道了在實(shí)際中數(shù)據(jù)結(jié)構(gòu)和信息結(jié)構(gòu)是不一樣的，信息結(jié)構(gòu)只是產(chǎn)品層面的數(shù)據(jù)內(nèi)容。
無論是什么樣的產(chǎn)品類型，無論從哪里入手，我們第一步都是先要羅列信息結(jié)構(gòu)，因為信息結(jié)構(gòu)圖不僅是輔助技術(shù)人員創(chuàng)建數(shù)據(jù)庫的圖表，也是輔助產(chǎn)品人員進(jìn)行產(chǎn)品功能規(guī)劃的參考，只有對信息或數(shù)據(jù)的結(jié)構(gòu)了解了，我們才能更好的設(shè)計產(chǎn)品。
信息結(jié)構(gòu)圖是我們將概念想法形成結(jié)構(gòu)化的第一步，也是我們接下來幾步工作的輔助文檔，同時在接下來的幾步工作中，我們還會不斷的完善信息的結(jié)構(gòu)。
2.2、梳理需求（產(chǎn)品結(jié)構(gòu)圖）
當(dāng)我們對產(chǎn)品的信息結(jié)構(gòu)了解后，我們就需要規(guī)整腦海中的產(chǎn)品需求，讓想法更加結(jié)構(gòu)化，因此這一步就要梳理產(chǎn)品的需求。在設(shè)計產(chǎn)品原型之前，我們首先要羅列出產(chǎn)品的功能結(jié)構(gòu)，包括頻道、頁面、模塊及元素。這一步依然使用思維導(dǎo)圖軟件，像繪制樓盤鳥瞰圖一樣將產(chǎn)品的結(jié)構(gòu)繪制成結(jié)構(gòu)圖，因此我稱這一步為“產(chǎn)品結(jié)構(gòu)圖”。
產(chǎn)品結(jié)構(gòu)圖是一種將產(chǎn)品原型以結(jié)構(gòu)化的方式展現(xiàn)的圖表，結(jié)構(gòu)內(nèi)容也如同產(chǎn)品原型一樣，從頻道到頁面，再細(xì)化頁面功能模塊和元素。所以產(chǎn)品結(jié)構(gòu)圖是產(chǎn)品經(jīng)理在設(shè)計原型之前的一種思路梳理的方式，并不是給其他工作人員查看的文檔，通過類似鳥瞰式的結(jié)構(gòu)圖可以讓產(chǎn)品經(jīng)理對產(chǎn)品結(jié)構(gòu)一目了然，也方便思考。
如上圖示例，“活動大全”的產(chǎn)品結(jié)構(gòu)依次是：產(chǎn)品 -> 頻道 -> 頁面 -> 頁面元素 -> 操作 -> 元素。我們換一個角度觀看示例，產(chǎn)品結(jié)構(gòu)圖實(shí)際上就是一種結(jié)構(gòu)化的產(chǎn)品原型。這樣做的目的就是梳理產(chǎn)品結(jié)構(gòu)邏輯，讓我們清楚的知道產(chǎn)品有幾個頻道，頻道下面有沒有子頻道或者有多少個頁面，這些頁面里又有哪些功能模塊，這些功能模塊里又有哪些元素。
上圖以我們第一步的“信息結(jié)構(gòu)圖”為基礎(chǔ)繪制的“產(chǎn)品結(jié)構(gòu)圖”，有了這份結(jié)構(gòu)導(dǎo)圖，我們可以對產(chǎn)品進(jìn)行鳥瞰式考慮和完善，當(dāng)有問題時，修改起來也比原型和文檔方便很多。比如在后續(xù)規(guī)劃中，我們發(fā)現(xiàn)文章的圖片等附件上傳后，管理不太方便，這時就可以在結(jié)構(gòu)圖中增加一個“附件管理”頻道。如果我們使用產(chǎn)品結(jié)構(gòu)圖的方式，那么附件管理的功能增加和修改就會比原型工具更加便捷和效率。
產(chǎn)品結(jié)構(gòu)圖的方法同樣適用于移動互聯(lián)網(wǎng)產(chǎn)品的設(shè)計，并且比起Web產(chǎn)品更加容易梳理產(chǎn)品結(jié)構(gòu)。
產(chǎn)品結(jié)構(gòu)圖是一種讓產(chǎn)品經(jīng)理通過思維導(dǎo)圖的方式梳理思路的方法，通過這種方法可以明確產(chǎn)品有多少個頻道、有多少個頁面、頁面有多少個功能模塊、功能模塊有多少個元素，逐步的將腦海里的想法明確梳理成結(jié)構(gòu)。雖然這種方法能夠明確產(chǎn)品的結(jié)構(gòu)，但是這樣的思維導(dǎo)圖也就只有產(chǎn)品經(jīng)理自己能夠看懂，因為對于設(shè)計和技術(shù)人員這是一個抽象的表述方式，如果沒有詳細(xì)的講解，是很難理解的。
產(chǎn)品結(jié)構(gòu)圖是將產(chǎn)品原型具體化的一種方式，只是羅列了產(chǎn)品的頻道頁面和功能，但是沒有詳細(xì)的進(jìn)行推演，關(guān)于細(xì)化方面是否符合產(chǎn)品邏輯，是否符合用戶體驗，這些都是沒有深思過的，因此我們接下來就要進(jìn)行原型設(shè)計，開始具體的考慮可行性。
當(dāng)我們逐漸清晰了產(chǎn)品的需求后，并梳理了產(chǎn)品的各個頻道及頁面，那么這一步就要開始驗證這些想法的具體界面表現(xiàn)和方案的可行性了。
原型設(shè)計是幫助我們更細(xì)致的思考，并做各項需求的評估，同時也是將自己腦海里的想法進(jìn)行輸出的一種方式。通過原型設(shè)計后，我們就可以進(jìn)行產(chǎn)品宣講了，相比較于抽象的文字描述，原型則更加直觀的展現(xiàn)產(chǎn)品的需求，設(shè)計和技術(shù)人員或者老板也能夠更加直觀的了解到產(chǎn)品意圖。
原型設(shè)計是將結(jié)構(gòu)化的需求進(jìn)行框架化，因此原型也被稱為線框圖，具體的表現(xiàn)手法有很多種，相關(guān)的輔助軟件也有很多，例如：Axure RP、Balsamiq Mockups、UIDesigner等等。
當(dāng)?shù)搅嗽驮O(shè)計這一步時，已經(jīng)不僅僅是構(gòu)思了，我們需要更加深入的了解每個頁面上元素和這些元素的屬性。例如按鈕元素，我們就需要考慮這個按鈕的功能，并且這個功能操作后帶給后端和前端的反饋。例如注冊會員按鈕，用戶操作后，第一步邏輯是驗證用戶輸入的信息是否合法，不合法則給出前端反饋；合法則和后端通信驗證是否已經(jīng)存在同樣信息，已經(jīng)存在則給出前端反饋，不存在則進(jìn)入下一步，注冊成功；注冊成功后的反饋是跳轉(zhuǎn)頁面，還是彈出層提示用戶完善資料，這些都是需要更詳情的考慮。當(dāng)然這些更細(xì)致的思考是留在需求文檔撰寫時的，而此時我們需要做的就是把這些元素通過原型表現(xiàn)出來。
原型設(shè)計的表現(xiàn)手法主要有三種：手繪原型、灰模原型、交互原型。從工作效率的角度考慮，我非常建議先通過手繪的形式快速在草紙上繪制出產(chǎn)品的原型，推演和討論方案的可行性。當(dāng)方案的可行性被驗證之后，我們再根據(jù)個人習(xí)慣或團(tuán)隊要求，通過軟件工具進(jìn)行更深入的設(shè)計。
① 手繪原型
因為原型也被稱為線框圖，因此手繪是最簡單直接的方法，也是最快速的表現(xiàn)產(chǎn)品輪廓的手法。
手繪原型在初期驗證想法時非常高效，也方便討論和重構(gòu)，同時也適合敏捷開發(fā)時快速出原型。
② 灰模原型
灰模原型是由圖形設(shè)計軟件制作而成，最常用的軟件是Photoshop和Fireworks，相對手繪原型，灰模更加清晰和整潔，也適用于正式場合的PPT形式宣講。
灰模原型也可以稱之為平面原型，所以如果不會使用圖形軟件也可以使用Axure RP設(shè)計，相比交互原型，灰模原型只是缺少交互效果，僅僅是將產(chǎn)品需求以線框結(jié)構(gòu)的方式展示出來，讓產(chǎn)品需求更加規(guī)整的直觀展現(xiàn)。
③ 交互原型
交互原型是使用原型設(shè)計軟件完成的原型，常用軟件是Axure RP，通常情況交互原型的設(shè)計要早于產(chǎn)品需求文檔，是產(chǎn)品經(jīng)理想法推演的重要一步。通過Axure RP之類的交互原型軟件制作出來的產(chǎn)品原型，在功能需求和交互需求的表現(xiàn)上，幾乎和正式產(chǎn)品是一致的，所以有時交互原型也被稱為產(chǎn)品Demo版。
通常情況下交互原型是產(chǎn)品經(jīng)理與交互設(shè)計師共同討論確定，然后由交互設(shè)計師制作，但是絕大多數(shù)的公司是沒有交互設(shè)計師這個職位的，因此這類工作最終是由產(chǎn)品經(jīng)理來負(fù)責(zé)的。
—
以上三種方法并不是漸進(jìn)的流程，而是三種原型設(shè)計的方法，具體取決于你的產(chǎn)品需求和團(tuán)隊要求。
對于產(chǎn)品經(jīng)理來說，原型設(shè)計是為了幫助我們細(xì)致的考慮方案，并論證方案的可行性，同時也是為了產(chǎn)品宣講時讓聽眾能夠清晰直觀的了解產(chǎn)品，避免抽象的語言描述導(dǎo)致聽眾理解困難和理解偏差。產(chǎn)品原型也是為了確保產(chǎn)品在執(zhí)行過程中，是按產(chǎn)品經(jīng)理最初設(shè)想的需求和期望完成的，因此產(chǎn)品經(jīng)理的原型是沒有很高的要求的，只要對方能夠聽懂看懂就可以了，所以使用手繪原型是最高效率的方法。
用例(Use Case)是一種描述產(chǎn)品需求的方法，使用用例的方法來描述產(chǎn)品需求的過程就是用例模型，用例模型是由用例圖和每一個用例的詳細(xì)描述文檔所組成的。在技術(shù)和產(chǎn)品的工作領(lǐng)域里都有用例模型的技能知識。技術(shù)人員的用例主要是為了方便在多名技術(shù)人員協(xié)同工作，或者技術(shù)人員任務(wù)交接時，讓參與者更好的理解代碼的邏輯結(jié)構(gòu)。產(chǎn)品人員的用例主要是為了方便技術(shù)研發(fā)和功能測試時，讓參與者更好的理解功能的邏輯。
用例起源和發(fā)展于軟件時代的產(chǎn)品研發(fā)，后來被綜合到UML規(guī)范之中，成為一種標(biāo)準(zhǔn)化的需求表述體系。雖然用例在軟件研發(fā)和技術(shù)工作中應(yīng)用的非常廣泛，但是在互聯(lián)網(wǎng)產(chǎn)品規(guī)劃和設(shè)計中，并不經(jīng)常使用，互聯(lián)網(wǎng)產(chǎn)品的需求表達(dá)為了敏捷效率，通常采用原型加產(chǎn)品需求文檔。
UML是英文Unified Modeling Language的縮寫，中文稱為統(tǒng)一建模語言或標(biāo)準(zhǔn)建模語言，是用例模型的建模語言，常用工具是Microsoft Office Visio。產(chǎn)品用例是一種通過用戶的使用場景來獲取需求的方式，每個用例提供了一個或多個場景，該場景說明了產(chǎn)品是如何和最終用戶或其它產(chǎn)品互動，也就是誰可以用產(chǎn)品做什么，從而獲得一個明確的業(yè)務(wù)目標(biāo)。
① 用例圖
用例圖并不是畫成了圖形的用例。用例圖包含一組用例，每一個用例用橢圓表示，放置在矩形框中；矩形框表示整個系統(tǒng)。矩形框外畫如圖所示的小人，表示參與者。參與者不一定是人，可以是其它產(chǎn)品、軟件或硬件等等。某一參與者與某一用例用線連起來，表示該參與者和該用例有交互。
許多人通過UML認(rèn)識了用例，UML定義為展現(xiàn)用例的圖形符號。UML并不是為描述用例定義書寫格式的標(biāo)準(zhǔn)，因此許多人誤認(rèn)為這些圖形符號就是用例本身；然而，圖形符號只能給出最簡單的一個或一組用例的概要。UML是用例圖形符號最流行的標(biāo)準(zhǔn)，但是除了UML標(biāo)準(zhǔn)，用例也有其它的可選擇的標(biāo)準(zhǔn)。
② 用例描述文檔
用例圖只是在總體上大致描述了產(chǎn)品所能提供的各種服務(wù)，讓我們對于產(chǎn)品的功能有一個總體的認(rèn)識。除此之外，我們還需要描述每一個用例的詳細(xì)信息，這些信息應(yīng)該包含以下內(nèi)容：
用例名稱：本用例的名稱或者編號
行為角色：參與或操作(執(zhí)行)該用例的角色
簡要說明：簡要的描述一下本用例的需求(作用和目的)
前置條件：參與或操作(執(zhí)行)本用例的前提條件，或者所處的狀態(tài)
后置條件：執(zhí)行完畢后的結(jié)果或者狀態(tài)
用例描述文檔基本上是用文本方式來表述的，為了更加清晰地描述用例，也可以選擇使用狀態(tài)圖、流程圖或序列圖來輔助說明。只要有助于表達(dá)的簡潔明了，就可以在用例中任意粘貼用戶界面和流程的圖形化顯示方式，或是其它圖形。如流程圖有助于描述復(fù)雜的決策流程，狀態(tài)轉(zhuǎn)移圖有助于描述與狀態(tài)相關(guān)的系統(tǒng)行為，序列圖適合于描述基于時間順序的消息傳遞。
在互聯(lián)網(wǎng)產(chǎn)品和設(shè)計中，用例的使用越來越少，通常有了產(chǎn)品原型再加上功能流程圖和功能說明文檔就能夠?qū)a(chǎn)品需求詳細(xì)的表述清楚，所以也沒有必須撰寫用例了。但是在大公司里，往往會追求產(chǎn)品流程的規(guī)范性，要求撰寫用例，不過在敏捷開發(fā)的時候也會采用其它更有效率的方式，不一定非要撰寫用例。
前面幾步我們將產(chǎn)品需求逐漸細(xì)化并且通過原型的方式將產(chǎn)品需求形象化的展現(xiàn)了出來，但是在產(chǎn)品功能的邏輯細(xì)節(jié)方面，原型就非常不直觀了，所以用例是一個非常重要的描述需求過程的文檔。
但是由于用例文檔以文字為主，并且格式復(fù)雜，不適用于高效率的產(chǎn)品需求表述，所以展現(xiàn)邏輯流程的“功能流程圖”是一個簡潔直觀的可替代用例文檔的方式。
（請點(diǎn)擊查看大圖）
如上圖所示，功能流程圖是一種使用圖形的方式表示算法邏輯的圖表，因為千言萬語不如一張圖，通過流程圖將“優(yōu)惠券”功能模塊的邏輯和需求非常形象直觀、一目了然的展現(xiàn)了出來。
流程圖的展現(xiàn)方式也不會產(chǎn)生“歧義性”，便于理解，邏輯出錯時也非常容易發(fā)現(xiàn)，并且可以直接轉(zhuǎn)化為程序需求描述文檔。
前面的幾個步驟是為了幫助我們梳理需求、驗證可行性和明確細(xì)節(jié)，到了這一步的時候我們已經(jīng)非常清晰的了解產(chǎn)品需求，此時撰寫產(chǎn)品需求文檔可以大大減少和避免了撰寫文檔時容易忽略的細(xì)節(jié)黑洞。
產(chǎn)品需求文檔是將產(chǎn)品規(guī)劃和設(shè)計的需求具體形象化表述出來的一種展現(xiàn)形式，主要用于產(chǎn)品界面設(shè)計和研發(fā)使用。因為每個人的習(xí)慣和團(tuán)隊要求都是不一樣的，所以產(chǎn)品需求文檔沒有統(tǒng)一的行業(yè)規(guī)范標(biāo)準(zhǔn)，無論以什么樣的格式撰寫產(chǎn)品需求文檔，最終的目的都是讓執(zhí)行人員能夠理解產(chǎn)品需求，根據(jù)需求完成產(chǎn)品。
產(chǎn)品需求文檔的表現(xiàn)形式有很多種，常見的有Word、圖片和交互原型這三種形式，文檔內(nèi)容通常包含信息結(jié)構(gòu)圖、界面線框圖、功能流程圖、功能說明文檔。雖然產(chǎn)品需求文檔沒有標(biāo)準(zhǔn)的規(guī)范，但是有兩項是必不可少的，那就是文件標(biāo)識和修改記錄。文檔在撰寫過程中，我們可以自行不斷的修改完善，但是如果正式發(fā)布或交給團(tuán)隊其他成員后，一旦有了修改，為了文檔的同步，我們就需要標(biāo)注出文檔的修改內(nèi)容，備注修改記錄，這樣可以方便大家查看和了解改動的內(nèi)容。關(guān)于文件標(biāo)識和修改記錄，格式都大同小異。
① Word
這是傳統(tǒng)意義上的產(chǎn)品需求文檔，主要有四個部分組成(具體根據(jù)產(chǎn)品要求進(jìn)行劃分)，分別是：結(jié)構(gòu)圖、全局說明、頻道功能、效果圖。
因為產(chǎn)品需求文檔的閱讀者主要是偏向于技術(shù)人員，因此文檔的目的性非常明確，就是要描述產(chǎn)品的功能需求，所有產(chǎn)品需求文檔沒有關(guān)于市場方面的描述。為了保證需求的執(zhí)行效率，建議大家盡量減少不必要的文字，在能夠讓閱讀者看懂并且了解產(chǎn)品意圖的情況下，文字越少越好。這主要是因為絕大多數(shù)人是沒有足夠耐心認(rèn)真看完產(chǎn)品需求文檔的，因此我們要盡量減化文檔內(nèi)容。
①-1、結(jié)構(gòu)圖：
①-1.1、信息結(jié)構(gòu)圖：主要是輔助服務(wù)端技術(shù)人員創(chuàng)建或調(diào)整數(shù)據(jù)結(jié)構(gòu)的參考文件
①-1.2、產(chǎn)品結(jié)構(gòu)圖：主要是輔助設(shè)計和技術(shù)開發(fā)人員了解產(chǎn)品的全局結(jié)構(gòu)。
①-2、全局說明：
主要講解產(chǎn)品的全局性功能的說明，例如網(wǎng)站產(chǎn)品的頁面編碼、用戶角色，移動產(chǎn)品的緩存機(jī)制、下載機(jī)制，這類全局性功能的說明。這里我舉一個移動產(chǎn)品的“狀態(tài)維持與恢復(fù)”的例子。示例如下：
狀態(tài)的維持與恢復(fù)
當(dāng)用戶退出產(chǎn)品時（誤操作、Home鍵、鎖屏、自動關(guān)機(jī)），產(chǎn)品需要維持用戶操作前的狀態(tài)，當(dāng)用戶返回產(chǎn)品時仍可以恢復(fù)到之前狀態(tài)，并繼續(xù)使用。
維持狀態(tài)包括流程操作、信息瀏覽、文本輸入、文件下載。
鎖屏狀態(tài)時，如果用戶在產(chǎn)品中有下載任務(wù)時，仍然保持下載。
①-3、頻道功能：
以頻道為單位，頁面為子項，分別描述產(chǎn)品的頻道、頁面及頁面模塊元素的功能需求。示例如下：
1、頻道名：頻道介紹及需求說明
2、頁面1：頁面介紹及需求說明
2.1、頁面模塊1：模塊功能需求說明
2.1.1、頁面模塊1-元素1：功能說明
2.1.2、頁面模塊1-元素2：功能說明
2.2、頁面模塊2：模塊功能需求說明
在撰寫功能需求時，我們需要考慮用戶的流程，例如一個“完成”按鈕，我們需要描述他完成后，系統(tǒng)要不要給出反饋提示(反饋提示是什么樣的形式反饋，內(nèi)容顯示成什么，有沒有內(nèi)容需要調(diào)取數(shù)據(jù)庫)，或者要不要跳轉(zhuǎn)頁面(跳轉(zhuǎn)到哪個頁面，這個頁面是其他頻道頁面，還是這個功能的子頁面，如果是子頁面就需要再描述這個子頁面的模塊及元素內(nèi)容)。
①-4、效果圖：
效果圖是由設(shè)計師完成的產(chǎn)品圖，和實(shí)際開發(fā)完成的產(chǎn)品保真度一致。
這個示例是一個移動產(chǎn)品(iPad)需求文檔，其中部分隱私內(nèi)容已過濾隱藏，并且只保留了首頁和地圖找房頻道的需求說明。由于工作環(huán)境沒有交互設(shè)計師，所以Word文檔中包含了部分交互說明。
② 圖片
圖片形式的產(chǎn)品需求文檔是基于效果圖的說明文件，將傳統(tǒng)Word形式的功能需求說明標(biāo)注在效果圖上，這種方式經(jīng)常使用在移動互聯(lián)網(wǎng)領(lǐng)域，實(shí)際上是圖文形式的交互需求文件，只是在此基礎(chǔ)上更深入的描述出功能需求。
對于圖片形式的產(chǎn)品需求文檔，我們只需要另外再描述一下全局說明，其他頻道頁面的需求直接以圖片形式展示，這種方式相對于Word文檔的純文字更加生動易讀并且直觀，因此有一些產(chǎn)品經(jīng)理非常喜歡用這種方式代替Word形式的產(chǎn)品需求文檔。
③ 交互原型
這里指的交互原型就是前面篇章講到的原型設(shè)計，使用Axure PR之類的交互原型設(shè)計軟件制作出來的產(chǎn)品原型非常真實(shí)和直觀，并且原型軟件還支持元素標(biāo)注和導(dǎo)出Word文檔，因此很多產(chǎn)品經(jīng)理都喜歡使用Axure PR來代替Word完成產(chǎn)品需求文檔。
當(dāng)我們通過Axure PR制作出產(chǎn)品原型后，實(shí)際上他已經(jīng)是很完善的產(chǎn)品Demo了，因此我們只需要加上元素的標(biāo)注，在標(biāo)注中說明功能需求，這樣導(dǎo)出的HTML文件相比Word文檔更直觀易懂，是非常高效的產(chǎn)品需求說明方式。
無論你采用哪種方式撰寫需求文檔，最終的目的都是為了方便團(tuán)隊成員理解產(chǎn)品的意圖，因此哪種方法能夠避免細(xì)節(jié)黑洞，高效完成產(chǎn)品的設(shè)計和研發(fā)，那么這種方法就是最有效的方法
