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

一個需求的形成，期間會經歷一個嚴謹的流程，好的產品需求，能幫助我們準確地反映出用戶的需要和想法，能幫助我們做出正確的產品。本文將從項目啟動開始，一步一步給大家帶來創建需求的科學流程。

無論是互聯網產品、軟件產品、硬件產品或服務，需求就是它們要做的事或要成為的樣子。不論你發現還是沒發現，寫下來或沒寫下來，需求都是存在的。

一個需求的形成，期間會經歷一個嚴謹的流程，好的產品需求，能幫助我們準確地反映出用戶的需要和想法，能幫助我們做出正確的產品。本文將從項目啟動開始，一步一步給大家帶來創建需求的科學流程。

一、確定業務范圍

在本階段，通常會通過一場項目啟動會開啟我們的項目，在項目啟動會上我們會大致了解到產品要實現的目標、產品的大體利益相關者。在項目啟動會上，我們可能會從項目經理那里得到一部分的項目相關資料，當然，大部分的資料還是需要我們自己去挖掘。

在會議上，務必要明確項目的目標，通過一段簡短的、定量的陳述，說明產品要做的事，以及產品所帶來的業務好處。這個目標是很有用處的，它能解釋為什么我們的業務需要這個項目，也能說明期望實現的業務收益。它為項目提供了理由，同時也是需求發現過程關注的焦點。

這里有三個關鍵詞：

范圍、利益相關者和目標

范圍是受產品影響的業務領域的部分。因為它確定了真實組織機構的一部分，所以范圍會指出一些利益相關者，他們對項目的成功有影響。利益相關者反過來又決定了產品的目標，即產品使用后期望獲得的業務上的完善或改進。

這樣就構成了項目前期很重要的：“范圍—利益相關者—目標”的三位一體關系鏈。

1.1 范圍，是產品實現的邊界

這里的范圍指的是產品的工作范圍，也就是產品要去改變或改進的那部分工作。只要它涉及一些處理內容和數據，我們就稱之為“工作”，而我們必須知道它的范圍。

任何一部分工作，都必須至少和另一部分工作有聯系。如果沒有聯系，工作將沒有作用，它不會有任何輸出。同理，這項工作內的模塊都至少和另一個模塊有聯系。了解了這一點，我們就可以分離出相應的模塊，即在產品的工作之內的模塊。

要完成工作模塊的分離，我們要知道一個簡單的事實，即所有的模塊都是由數據驅動的。我們剛才提到，模塊與其他模塊有聯系，這種聯系就是數據流。也就是說，每一個模塊都會產生某種數據，然后將數據傳遞給其他的模塊。后續的模塊收到進入的數據流，觸發執行它要做的處理，并生成不同的數據輸出，這些輸出再次傳遞給其他模塊。因此這些數據流就是模塊之間的聯系。

通過確定這些數據聯系，就能確定工作的邊界。我們可以通過畫一條線來代表工作邊界，區分類似的、耦合的模塊，創造了一個區域，最終包含了所有構成工作的范圍。

1.2 利益相關者，是需求的來源

利益相關者包括全部對產品的結果有影響的人。產品的核心用戶是最明顯的利益相關者，但是還有其他利益相關者。比如，對于一款企業內部的2B類產品，客服部門、業務部門、銷售部門、售后部門等等，都會是產品的利益相關者。每個項目都可能有幾十種利益相關者。我們要考慮到全部利益相關者，這可能意味著與很多人交談，他們都可能是需求的來源。

在和利益相關者交談時，要向他們解釋，為什么他們是利益相關者以及為什么需要就產品需求向他們咨詢 。一種友好的做法是通知他們將需要他們多少時間，以及他們應該以何種方式參與。關于利益相關者的最大問題就是，如果沒有找齊所有的利益相關者，或者在需求收集過程中把某些利益相關者排除在外，將遺漏一些需求。

1.3 產品目標，是最高層次的需求

產品要解決的問題，就是產品的目標。項目的目標應該不僅僅是解決問題，還要提供業務上的好處，這里的好處指的是，產品的核心用戶以及利益相關者可以從產品中得到的好處 。

一般的團隊在明確了產品的目標后，就著手去實施了。但是，這里欠缺很重要的一點，就是度量產品目標。度量產品目標可以回答以下問題：

• 這是一個合理的產品目標嗎？比如，企業CRM系統，為了實現企業管理、跟進客戶關系，開發該系統花費的成本，是否值得？我們可以收集一些數據，比如市面上的CRM系統，在采購半年后，所創造的客戶數據大概在多少，我們自己研發一套CRM系統，在半年內要達到這個數據量所涉及的成本是多少，二者是否平衡等。
• 產品目標是否可行？在項目啟動會上，相關的利益相關者可以對此進行評估。比如，經驗豐富的技術負責人可以大體評估出產品目標的可行性。
• 產品目標是否可達到？同樣，項目啟動會上可以大體評估出產品目標能否達到。

通過以上問題，我們可以總結出關于產品度量的標準：比如，在半年內，通過CRM系統，將公司有效客戶數量增加至20000。

綜上，我們可以得到一個描述產品目標的模板：

• 目標：產品要做什么的業務描述。
• 好處：產品能提供怎樣的業務好處。
• 度量：對產品目標進行度量的數據描述。
• 合理性：綜合考慮全部因素，產品是否有可能實現業務好處。
• 可行性：考慮到在啟動會議上得到的信息，產品能達到度量標準。
• 可達成性：組織機構是否具備構建該產品的技能。

二、拆解業務用例

在明確了項目的目標之后，接下來要做的就是得到產品中全部的業務用例。（用例，用來描述系統與用戶之間的交互）

2.1 業務事件與業務用例

產品的用戶在使用產品過程中涉及到的工作或業務，統稱為業務事件。

比如，用戶在網上買書時，挑選好了需要的書籍，這時可能會有兩種情況：

1. 決定做些別的事情，先放棄此次交易；
2. 決定買下這本書。

此時，決定要買這本書就是一個業務事件。當然，只是決定想要這本書還不夠，用戶必須告訴系統想要買書。 用戶點擊了購買按鈕，提供了手機號、收貨地址等信息。此時，用戶的操作觸發了系統，系統會完成下單，并且快遞這本書到用戶手中。

從這里我們可以順帶引出業務用例的概念：

在這個例子中，用戶決定買書和完成買書的操作就是業務事件。總是有一些數據源自業務事件（觸發數據流），這會調用預先計劃的對該事件的響應。這種響應就是業務用例。

（當業務事件發生時，系統通過發起一個業務用例進行響應）

2.2 發現業務事件

業務事件其實就是發生的一些事情，這些事情讓系統以某種方式做出反應。在業務事件發生時，在系統工作中至少會顯示一條數據流。

進入或離開系統的每個信息流都會是一個業務事件的結果，外部通信的存在沒有其他的理由?？匆幌旅總€信息流，就可以確定引發它的事件。在某些情況下，可能有多個信息流跟隨同一事件。

例如，在物流服務系統中，當物流倉庫提示一輛已經被調度出庫的卡車出現了故障，或者是由于其他原因需要停止服務，系統此時要做出響應。因為一輛卡車已停止服務，必須重新安排其他的卡車來彌補，由此導致的輸出信息流可能是“修改卡車調度計劃”。

業務事件通常由事件名稱和輸入輸出數據流組成，業務事件的模板如下：

例如：物流公司派出卡車服務的業務事件

在挖掘業務事件時，有一個需要注意的要點，就是要看到整個業務過程?。比如，上述物流公司提供物流服務的例子，如果只是站在用戶側，看到的業務事件有可能是“收件人收到發貨并登記信息”，可是站在整個業務鏈側，業務事件就是“物流公司派送貨物”。

2.3 拆解業務用例

上面已經說到，針對每個業務事件，有一個預先計劃的對它的響應，被稱為業務用例。業務用例包含一些業務處理的過程，一些被存取的數據，產生的一些輸出，發送的一些消息，或是這些事情的組合。換言之，業務用例就是一個功能的單元。這種單元是編寫功能需求和非功能需求的基礎。

業務用例 = 業務處理過程 + 存取的數據 + 輸出信息

通過找到的業務事件，按照上述公式，可以得到具體的業務用例，通常多個業務用例單元會組成一個完整的功能描述。

研究業務用例，就是要考慮系統要做哪些事以及預期的結果。在拆解并理解了業務用例的全部工作之后，也就確定了對業務用例貢獻最大的產品范圍。

三、進行業務調研

在得到了項目啟動階段的輸出信息，即系統的范圍、項目的目標、系統的業務事件與用例。啟動階段也確定了項目涉及的利益相關者和潛在用戶。我們接下來就需要進行工作調研，取得對系統的深入理解。工作調研，可以幫助我們有效地深入了解項目業務的本質。

3.1 建模

建模作為工作調研的一種方式，最好是在需要理解中到大型工作領域，又沒有文檔時進行。如果當前的利益相關者很難描述整體工作，也可以采用這種方法。

我們可以利用模型幫助理解系統的工作。要限制在當前系統模型中所展示細節的數量。理想的模型包含足夠讓你理解工作的信息。也就是說，模型要展示當前情況的主要部分。這樣的模型允許利益相關者驗證它是否足夠好地代表了他們工作的實際情況，讓我們可以有進一步問問題的基礎。

常見的建模方式包括業務流程圖、思維導圖、UML時序圖等，不限于形式，只要能幫助更好地梳理業務事件和業務用例就好。

3.2 現場調研

現場調研對于開發企業內部的B端產品很有用?，F場調研的基本假定是用戶正在完成工作，作為產品經理，必須理解他們的工作。

現場調研是一種觀察實際工作的很好的方法，有點像以前的“學徒工”。在這種情況下，產品經理是徒弟，各利益相關者是師父。產品經理與利益相關者一起坐在他們工作的場所，通過觀察，問問題，或者通過在利益相關者指導下完成一些工作來進行學習。

如果用戶正在他工作的地方做他的事情，他就能提供連續不斷的解說，并提供在其他情況下會遺漏的細節。所以，如果你想得到工作的準確解釋，就要去工作現場，坐在用戶身邊，在工作發生時獲得連續不斷的解說。

現場調研可以與建模結合起來。在觀察工作和用戶的解釋時，可以勾勒出每項任務的模型，以及它們與其他任務的聯系。在建模時，將它反饋給用戶以求得確認。然后我們會利這種反饋，對所有不確定的地方提出問題。

3.3 利益相關者訪談

利益相關者訪談是最常用的需求收集方法。幾乎每一個項目都離不開利益相關者訪談。在訪談過程中，利益相關者不應該是完全被動的。相反，應該盡量讓他們參與建模（業務事件響應、用例、場景等）的過程中來。這樣我們就和利益相關者之間建立起了一個反饋環，也意味著可以迭代式地測試你聽到的東西的準確性。在利益相關者訪談中，有如下需要注意的要點：

• 確定好訪談的背景。這樣可以有效避免利益相關者和你談一些無關的問題。
• 限制訪談的時間。國外有研究表明，超過1小時的訪談，會使訪談逐漸失去焦點。
• 使用業務用例作為訪談的核心。準備好業務用例，挨個討論業務用例，這樣也會增強訪談的方向性。
• 問問題、聽取回答、然后反饋理解。
• 畫出草圖、模型，鼓勵利益相關者改正它。及時畫出一些能表明談話內容的原型草圖、流程圖或用例圖，可以有效幫助我們理解每一個處理過程。
• 了解利益相關者的術語。在訪談中，難免會遇到利益相關者在實際工作中的術語，及時請教他們，理解其含義。
• 記錄筆記，寫下所了解到的一切。

總結下來，在利益相關者訪談中，做到兩點即可：正確提問，聆聽回答。

3.4 快速繪制低保真原型圖

原型和草圖可以有效地提取需求，基本思路是用草圖勾畫產品，然后進行逆向工程，從草圖導出需求。這種方式適用于：產品的利益相關者對這種產品或建議的技術沒有經驗 ；利益相關者很難說出他們的需求；產品經理很難理解需求是什么。

此時，原型為利益相關者提供了一些真實的東西，或者至少是具有真實的外觀。原型讓利益相關者感到產品足夠真實，從而提出用其他方法可能遺漏的需求。當利益相關者看到原型所展示的功能時，他們會想到一些其他需求。用這種方式，通過原型來展示產品雛形，并讓利益相關者身臨其境的去瀏覽或使用，就可以捕捉到一些需求，如果不是這樣，這些需求可能要到產品開發完真正使用時才能發現。

3.5 錄像或照相

錄像或照相是記錄某些時刻的一種方式，以便稍后能對它們進行研究。

錄像或照相可以用于研究業務。例如，團隊研討會和頭腦風暴，可以對過程錄像。訪談和現場觀察也可以錄像。利用這種方式，錄像的作用先是記錄進展過程，然后是確認。

錄像或照相可以結合利益相關者訪談一起使用。利益相關者有自己完成任務的方式。他們用自己的方法對使用的信息分類整理，用自己的方法來解決問題。他們發現這些方法非常適合他們的情況。因此，通過錄像來捕捉利益相關者工作的情形，就記錄了他們完成工作的方法、方式。

當然，錄像或照相的使用可以更加結構化。例如，選擇一個業務用例，讓利益相關者走一遍他們遇到的典型場景的流程，并通過錄像進行記錄。在利益相關者工作的同時，他們會描述特殊的情況、他們用到的輔助信息、異常情況等。記筆記時通常會喪失的信息都能被記錄下來，以備將來進行剖析。

3.6 總結

在工作調研的時候，要適當結合上述方式的多種，目的是能讓我們深入理解系統業務的本質，能達到這個目的的方法都是好方法。

四、完善業務用例

這里的完善業務用例，指的就是為業務用例加上場景，因為場景將樹立業務用例的故事。

在這里通過舉一個乘客登機的過程的例子，來說明如何為用例加入場景。首先，我們來草擬一個乘客登機的場景：

1. 得到乘客的機票或電子客票記錄編號。
2. 確定乘客、航班、目的地是否正確。
3. 檢查護照有效并屬于這名乘客。
4. 記下乘客的編號。
5. 為乘客分配一個座位。
6. 安檢行李。
7. 打印登機牌和行李標簽，并遞給乘客。
8. 祝乘客“旅途愉快”。

4.1 為場景取了一個有意義的名稱

業務用例名稱：為航班的乘客檢票

4.2 為業務用例加入啟動機制

啟動機制：乘客的機票、電子客票記錄編號，或者身份和航班信息

在用場景對系統建模時，應該一直詢問自己是否能改進工作。例如，除了讓乘客在值機柜臺前面等，是否能在乘客到達之前就開始？例如，他能在家檢票，或在來機場的路上，或在排隊時？所有這些選擇在技術上都是可行的，可能帶來一些業務上的好處。

4.3 加前置條件

現在加入一些前置條件，業務用例觸發時必須滿足這些條件。前置條件表明了工作初始的狀態。通常這意味著有一些業務事件必須已經發生，這個業務事件才有意義：

前置條件：乘客必須已預訂航班

4.4 加入影響利益相關者

還可以考慮為場景加入影響利益相關者。這些利益相關者對這個業務用例的結果有影響。也就是說，他們會受到工作完成方式和工作產生的數據的影響：

影響利益相關者：檢票員、市場部門、行李部門、航班預訂機構、航班乘客名單系統、安全部門、目的地國的移民局

4.5 主要的利益相關者

主要的利益相關者是完成這個業務用例工作的人或系統。通常，一個主要的利益相關者觸發業務用例，然后一個或多個其他的主動利益相關者參與這項工作：

主動利益相關者：乘客（觸發者）、檢票員

4.6?總結

現在，通過以上的分析，我們可以得到一個具備場景的業務用例描述模板：

業務事件：乘客決定檢票。

業務用例名稱和編號：為航班的乘客檢票，0101。

啟動機制：乘客的機票、電子客票、記錄編號，或者身份和航班信息。

前置條件：乘客必須已預訂航班。

影響的利益相關者：檢票員、市場部門、行李部門、航班預訂機構、航班乘客名單系統、工作流、安全部門、目的地國的移民局。

主要利益相關者：乘客（觸發者）、檢票員。

（1）查出乘客的預訂信息。

（2）確保乘客身份正確，并確定預定信息。

（3）檢查護照有效并屬于這名乘客。

（4）記下經常飛行的乘客的編號。

（5）分配一個座位。

（6）詢問安全問題并得到正確回答。

（7）檢入行李。

（8）打印登機牌和行李標簽并遞給乘客。

（9）祝乘客旅途愉快。

成果：記錄下乘客已檢入這次航班，行李分配到這次航班，分配一個座位，乘客拿到登機牌和行李票根。

五、設計解決方案

經歷了前面的四個步驟，我們已經明確了產品的全部業務事件、業務用例，現在就要著手設計產品的解決方案了。設計產品解決方案有很多文章進行討論，這里只做一些簡單的總結。

5.1 再次明確產品的范圍

前面說過，業務用例是工作對外界服務請求的響應。所以最好的響應就是以最少的時間、原材料或工作量成本（從企業的視角），提供最有價值的服務（從用戶的視角）。因此我們打造的產品應該對最好的業務用例做出貢獻，即讓產品更便宜、更快、更方便，并且能達到我們的項目要實現的其他目標。

5.2 設計產品的用戶體驗

用戶體驗設計的理論就不在這里詳述了，體驗設計的目的是得到一種使用體驗，令人滿意且令人激動，同時符合用戶的文化和期望。這樣的設計更專注于用戶對產品的感覺，而不是為產品增加功能。

簡單來說，如果你提供了令人滿意的體驗，用戶很享受并愿意重復，那么這些用戶就很愿意接受你的產品，并且不要求改變。

5.3 考慮成本、收益和風險

我們有責任得到最有價值的產品，即對擁有者最有價值。這意味著解決方案的成本必須與它給擁有者帶來的收益相稱?；?0元錢開發的產品只帶來1元錢的收益是沒意義的。

風險必須與收益和成本相符。這里的風險包括潛在問題變成真正問題的可能性，以及問題成真所帶來的負面的影響。例如，假定我們建議的解決方案會使用近場通信（NFC）技術。之前從未用過這種技術，沒有內部的專家：風險在于也許不能成功地實現NFC。現在還要加上一項風險：即使這種技術成功地實施，業務客戶也可能拒絕使用。

應該將這些風險加起來，與收益進行比較。對于這個級別的風險，我們可能需要一些實質性的收益，才值得去做新產品。如果收益不大，那就應該考慮不同的解決方案。相反，如果收益巨大，那風險就值得承擔。

那如何評價可選的產品邊界？這就是要和利益相關者一起花時間的地方，判斷哪一種解決方式提供了成本、收益和風險的最佳組合。

六、編寫產品需求說明

6.1 功能需求

功能需求指明了產品必須做的事情，即產品為了滿足它存在的根本理由而必須執行一些動作。同時，功能需求是產品為了支持工作而必須做的事情。它們的表述應該盡可能獨立于實現需求的技術。比如，登錄功能、購物車功能、收藏功能、支付功能等。

在編寫功能需求時，要為需求加上理由，說明需求為什么存在。在大多數情況下，這是需求的關鍵部分。接著以物流公司那個為例，需求描述：對于卡車的調度，產品應該記錄開始和結束的時間。需求理由：卡車在24小時內最多被安排20小時，以便進行維護和清理。這條理由非常重要，如果該需求沒有實現，物流公司就會遇到麻煩，車輛的保養就會不及時。由此可以看到，一條好的需求理由也能決定需求的優先級。

6.2 非功能需求

非功能需求描述了產品必須具備的品質。這些需求讓產品有吸引力、易于使用、快速、可靠，或安全。用非功能需求來指定響應時間，或計算時達到的精度。如果產品必須具有某種特的外觀，或者必須在特定的環境下使用，或者必須遵守適用于業務法律，我們就要編寫非功能需求。

把功能需求看成是使產品工作的需求，把非功能需求看成是為工作增加某些特征的需求。

非功能需求是需求規格說明的重要組成部分。如果產品滿足了它所要求的功能需求，非功能屬性，如可用性、方便性、打動人心，是否得到滿足可能造成產品被接受、深受喜歡或無人使用。用戶對產品的看法和感覺大部分來自于非功能需求。

非功能性需求包括如下內容：

1.觀感需求

觀感需求描述了對產品外觀期望的精神實質、情緒或風格。比如：產品應該顯得保守、產品應該吸引人、產品應該表現出權威性、產品應該吸引年紀較大的人、產品應該顯示出藝術水準、產品應該看起來顯得很昂貴，等。 要注意，觀感需求描述了外觀的意圖，不是界面的設計。

2.易用性和人性化需求

易用性和人性化需求使產品符合用戶的能力和期望。易用性需求包括：用戶的接受率或采用率；因為引入該產品而導致的生產效率的提高或錯誤率的降低；在產品使用的國家被不說該國語言的人使用；個性化和國際化，讓用戶改成本地拼寫方式及其他選項；對殘障人士的可用性；被沒有計算機使用經驗的人使用；在黑暗的時候可以使用（夜間模式）。

禮貌是易用性中一個常常被忽略的方面。在過去的網站，通常是要求創建賬戶，填寫所有個人信息，然后輸入密碼。在這之后，用戶得到一條消息：“密碼應該是8個字母或數字，包括一個大寫字母和一個數字，請重新輸入密碼?！蓖瑫r，前面為了創建賬戶而輸入的所有個人信息都被清除，要求用戶再來一次。我們不能容忍這樣的行為，這對用戶的這種行為表明缺少禮貌需求。

此案例的非功能性需求應該這樣寫：

• 描述：產品應該避免要求用戶重復已輸入的數據
• 理由：為了建立用戶對產品的信心

易用性需求源自兩個方面，一方面是用戶期望產品達到的易用性水平，另一方面是預期用戶具有怎樣的經驗。自然，用戶的特征不同導致他們的期望不同。作為產品經理，我們必須發現這些特征，并確定怎樣的易用性水平將給用戶帶來舒適有用的體驗。

3.執行需求

如果產品需要在給定的時間，或以特定的精確度來執行某些任務，或者產品需要有一定容量，就要寫下執行需求。?比如：產品應該支持2000個并發用戶、產品支持最多好友數量是5000個等。

執行需求主要來自于操作環境。每種環境都有自己的情況和條件。人、機器、設備、環境條件等都會對產品有要求。產品響應這些情況的方式（它應該多快、多健壯、多大、多頻繁），就是相應的執行需求。

4.操作和環境需求

操作需求規定了如果要在產品的環境中正確操作，產品必須做的事。在某些情況下，操作環境創造了一些特殊的情況，會影響產品構建的方式。比如：產品應該能在不同的照明條件下使用；產品應該節省電池用電等。

為了發現操作需求，要查看產品邊界并考慮每一個相鄰的系統和利益相關者。如果需要，要與每個利益相關者或系統的代表進行訪談，發現與該產品相關的工作方式所導致的需求。

5.可維護性和支持需求

可維護性和支持需求描述的是預期的改變，以及完成改變允許的時間，也包括對產品的支持的規定。在需求階段，通常不知道產品在它的生命周期里所需的確切維護工作量，而且也不會總是知道它所需的維護類型。然而，產品在構建時總可以在一定程度上預見維護的類型。?比如：產品應該能夠移植到Android和iOS上。

要讓研發知道，希望在將來某個時候，產品能移植到另一個平臺上，讓產品有適應新設備的能力。

6.安全需求

安全需求涉及到三個方面：

• 可得性?？傻眯允强梢栽L問數據，產品保存數據的方式讓用戶能得到數據，同時能理解數據。在安全方面，可得性需求規定了產品必須做什么，來確保數據只能由授權的用戶訪問。在編寫這類需求時，要在規定允許的訪問，即誰有授權，在哪些情況下授權是有效的，每個授權的用戶可以訪問哪些數據和功能。
• 私密性。私密性表示產品尊重用戶的隱私，產品必須滿足一些需求來確保用戶數據的私密性。例如：產品的數據不支持打印、產品的數據做加密處理等。
• 完整性。完整性是指產品所保存的數據與相鄰系統發送給產品的數據完全保持一致。必須考慮防止數據沖突的需求，如果發生了最壞的情況，就要及時恢復丟失的數據。比如：我們的產品如果投入運行，將保存用戶組織機構的重要數據，完整性需求就是要保護些數據。

7.文化需求

文化需求規定了一些特殊因素，它們可能導致產品不被接受，原因是習慣、宗教、語言、禁忌、偏見，或幾乎是人類行為的任何方面。如果試圖把產品賣到另一個國家，特別是文化和語言與我們自己的有很大不同的國家，就帶來了對文化需求的不同要求。比如：產品不應該顯示與主流宗教有關的宗教符號和文字；產品不應該使用可能激怒任何人的術語和圖標；產品提供的語言選擇順序應該符合所在的地區等。

8.法律需求

我們并不想攤上法律訴訟，我們必須注意到那些適用于自己產品的法律，為產品寫下符合這些法律的需求。即使我們的產品是在組織機構內部使用，也要注意到有一些適用于工作場所的法律可能會有關系。

公司里要是有法律顧問就太好了，可以隨時請教他。我們可以考慮如下問題：

• 考慮用戶的法律需求和權利。例如，是否有一些對殘障人士的法律是適用的？
• 相鄰系統對保存的數據是否擁有隱私權？是否需要留下交易的證據？是否不能暴露產品擁有的關于某些系統的信息？
• 是否存在與該產品相關的法律？例如，數據保護、隱私法律、擔保、消費者保護、消費者信用、知情權等法律是否適用？

6.3 為需求增加驗收標準

如果產品有一項需求，要執行某個功能或具備某種屬性，那么測試時必須保證產品確實執行了該項功能，或具備了該項期望的屬性。為了進行這樣的測試，需求必須有一個測試基準，這樣測試者才能比較提交的產品和最初的需求。測試基準就是驗收標準，即需求的量化，它說明了產品必須達到的標準。

1.非功能性需求的驗收標準

非功能需求是產品必須具備的品質，諸如易用性、觀感、執行特點等。

因此，驗收標準是對這些品質進行量化。?比如：

a.描述：產品應該很酷。

驗收標準：40%的目標受眾在商店看到展示的產品，會拿起它，至少玩5秒鐘，并向同伴展示

b.描述：產品應該使用戶感覺到友好。

我們可以測量“喜歡”：如果用戶喜歡該產品，他們就會使用它。我們可以測量他們多快開始使用它，使用的時間和頻率，或過了多少時間大家開始說該產品是好的，用戶之間互相建議使用它。所有這些驗收標準量化了用戶的期望，即職員喜歡并使用該產品。

驗收標準：在引入該產品的 3 個月之內，60%的用戶應該用它來完成規定的工作；在這些用戶之中，應該有75%以上的用戶對產品表示贊許

c.描述：產品應該直觀。

為了測量“直觀”，必須考慮“直觀”是針對什么用戶而言的，比如，讓用戶可以易于學習。

驗收標準：在經過一天的培訓后，10個用戶中應該有9個能夠成功地完成任務

d.描述：響應應該足夠快，以避免打斷用戶的思路。

驗收標準：在95%的情況下，響應時間將不超過0.5秒，在其他情況下不超過2秒。

2.功能性需求的驗收標準

功能需求是產品必須做的某件事情，即產品必須完成的動作。驗收標準指明了如何得知
產品已經成功地完成了該動作。對功能需求來說，不存在測量的尺度：動作要么完成，要么沒完成。例如：

• 描述：產品首頁應該記錄漲跌數據
• 理由：用戶需要實時了解交易品的漲跌數據信息
• 驗收標準：首頁記錄下來的交易品漲跌數據要與國際交易中心的數據一致

3.總結

驗收標準既不是測試，也不是對測試的設計，而是測試提交的產品時必須采用的測試基準。它是構建測試用例的輸入信息，測試者通過測試用例來確保產品的每項需求都符合它的驗收標準。

6.4 產品需求模板

綜上所述，我們可以得到一個描述需求的模板：

6.5 總結

編寫需求規格說明不是一項獨立的工作，而是與需求過程的其他部分一起完成的。無論何時，如果產品經理或其他利益相關者有所發現，就寫下需求或部分需求。并非所有需求都是同時完成的。

正確地編寫需求是很重要的。一組好的需求能得到數倍的回報：構建工作更精確，維護成本更低，完成的產品更準確地反映用戶的需要和想法。

七、排列需求優先級

排列優先級讓我們能選擇哪些需求在產品的哪些版本中實現。確定優先級很復雜，因為它們涉及不同的因素，而這些因素彼此之間常常產生沖突。

要排列需求的優先級，可以將它們分成邏輯上的小組。這些小組分別作為一個單元來排列優先級。一個小組可能是一個業務用例、一個組件、一項功能，或其他需求分組，只要能夠作為一個單元來排列優先級，而不用單獨處理就行。

影響需求優先級的因素包括：

• 實現的成本
• 對用戶的價值
• 實現產品所需的時間
• 技術實現的容易程度
• 業務或組織機構實現的容易程度
• 對業務的好處如何
• 遵守法律的要求

不是所有因素都適用于每個項目，而且每個因素對每個項目的相對重要性也不一樣。在一個項目中，對不同的利益相關者來說，這些因素的相對重要性也不同。由于這些復雜性，我們需要對優先級達成一致意見，以提供決策。

八、總結

產品需求從不是拍拍腦袋就想出來的，它也是需要一個縝密、完整的過程。希望本文總結的需求流程能給你帶來一些啟發。

#專欄作家#

流年，人人都是產品經理專欄作家。互聯網產品設計師，4年互聯網產品設計經驗。擅長用戶體驗設計，喜歡鉆研需求功能背后的技術實現方式；在成為綜合型產品設計師的道路上不斷努力前進！

本文原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自 Unsplash ，基于 CC0 協議