⑴ 使用「需求實例化」方法，構建「需求體系化」產品--完結篇--
產品特性的分類規劃，新增需求的分析維護，是軟體產品研發的基礎。兩者之間的關系維護，也一直是困擾產品研發團隊的老大難問題。
是否可以藉助需求分析的利器--「需求實例化」方法，來構建「需求體系化」這項產品，解決產品研發的需求全生命周期管理問題？
step 0--建立願景
確定這個「需求體系化」產品譽晌圓要達成的整體效果，它所存在的價值就是助力產品價值交付，為產品價值交付流程的相關干係人提供一種知識服務、工具服務、管理服務。
step 1--確定系統
「 需求體系化 」的外部表現是一個網路空間，向上提供一個產品的 文檔持續交付平台 ，向下依賴產品研發的 DevOps工具鏈 ，這三者構成一個完整的系統，為各類用戶提供他們需要的服務內容。
step 2--尋找用戶
一個產品或者服務，必須以滿足用戶的需要而存在。所以，我們要找到「需求體系化」的產品用戶，分析他們的特徵，以及使用產品的頻度，便於後續產品功能的優先順序評估。
step 3--問詢目的
優先尋找產品使用頻度高，內容貢獻量大的用戶，開始用戶目的探尋。
目的探尋不能僅僅停留在淺層，必須深入慶塌挖掘，找出用戶背後的動機，才能有可能真正實現用戶想要的產品。
在研發流程的諸多角色中，PO、SE、BA均為本系統的重度使用者，他們的目的需要優先分析探尋。
每個角色在產品交付中的位置，決定了他們看待問題的角度，對「需求體系化」產品的要求也都存在差異。印證了一句經典名言：
但是，我們可以找到兩個共識：
產品由一系列必選和可選的特性組成，每個特性包含一個或多個相互獨立的組件/子特性。
特性與組件/子特性之間可以有兩種關系：
①or關系：多個同類組件/子特性可以同時服務於父特性
②xor關系：多個同類組件/子特性只能有一個服務於父特性
需求交付全過程的相關角色，都可以通過全景圖都得自己想要的關注點。
step 4--勾畫場景
下面，我們可以依據前面3步的工作成果，確定典型的產品場景，構建一個「需求體系化」的MVP(最小化可行產品)。謹祥
我們商業模式畫布的方法，分析「需求體系化」MVP的典型場景。
結合客戶細分、價值主張、客戶關系、渠道通路等關鍵要素，可以推導出其它關聯要素，共同確定系統的運作模式。
下面列舉了一個PO和SE交互的典型場景，使用故事板的形式呈現。
step 5--列舉功能
根據上一步的典型場景，可以開始基本功能的梳理和分解。
以上步驟4和5，僅僅完成了MVP中一個典型場景和基本功能輸出，在產品原型得到使用者的實際反饋後，需要重復迭代步驟4和5，輸出完整結果，規劃產品的交付計劃。
--end--
⑵ 一次需求實例化後的思考
最近參與了需求實例化討論，當前處於敏捷開發流程的學習過程，記錄下參與過程中的感受、思考、困惑
在當前項目的研發流程中，需求落團隊開發前，會先經歷一個環節：需求實例化；他的目的和本質是為了消除歧義，市場原始需求中是一些描述性語言，有些原始需求往往是一句話，在需求傳遞過程中存在失真，需求實例化是通過舉例的方式理出實際場景、編寫一定的驗收准則，以實際應用場景，幫助大家理解需求，其實就是把抽象的東西用例子把需求描述得更清楚些；
當前項目需求實例化安排固定鐵三角（規劃SE、開發BA、測試專家）來參與；借著學習的機會參與了需求討論；
1、感受：項目的需求實例化過程利用行業內常用的步驟來進行，有相關的模板；需求實例化5步驟：
定系統邊界：對外提供的軟體介面、服務輸出；
找用戶：提出方（市場SE）、規劃方（PO）、分析方（需求SE）、需求實現方（開發）、需求測試者（測試）、工程運維者（工程）、需求用戶
問目的：各用戶的目的挖掘分析；Want-Need-Win結構
畫場景：不同用戶所使用的場景，包含常規場景和特殊場景
列功能：根據典型場景，拆分功能項
2、思考：針對測試人員為什麼參與、需要注意什麼、輸出是什麼來思考測試人員參與需求實例化過程
Q:哪些測試人員會參與需求實例化？
A：在需求實例化階段，主要由測試專家參與，在測試團隊中屬於技術骨幹，在某一領域內對系統框架、系統特性、特性交配羨互精通；
Q:測試人員參與需求實例化的目的和作用是什麼？是否一定要參與需求實例化？
A：測試人員參與需求實例化，主要從用戶的角度來思考該特性的開通上線、實際應用、後期維護操作的可行性，方便性、可維護性；從用戶的角度來挖掘需求；測試專家參與需求實例化很有必要，在前期分析透，想明白需求要點，在測試過程中就能更准確、更全面
Q:需求實例化過程中測試人員重點關注什麼？
A:測試專家需要關注該需求及波及特性：
1）可測試性，主要有
可呈現：測試結果的輸出可呈現，可以被清楚明確的被觀察，通過觀察可分析出正確合理性
可控制：有各種輸入和明確輸出，可以通過工具進行自動化
可解耦：可以拆分成獨立的模塊來進行測試
可理解：對用戶來說是否清晰可維護，易於理解
2）已有自動化的覆蓋情況
3）需求分析的場景覆培滲拍蓋全面性（這點會影響測試場景的全面性）
Q:需求實例化一般會有多次討論才會定稿，測試人員在什麼時候參與最合適？
A：理想的情況，測試專家是跟隨需求的討論貫穿始終；目前的項目流程這點可持續優化改進，目前需求一次討論、一次定稿（在落團隊澄清需求時一起參與）
3、行動：如果參與需求實例化……
提前收集信息：了解需求，收集需求來源相關信息（需求相關波及文檔、背景細節等）
輸出倒逼輸入：在了解完需求後嘗試測試分析的輸出，帶著問題參與需求討論（理想狀態，對個人和項目流程有一定要求；提前完成需求分析喊扒輸出、預留時間）
參與後靈魂問：
這次的討論有什麼收獲？
這次的討論哪些可以直接應用？
這次的討論後第一步可以做什麼？
這次的討論我需要加強的是哪方面？
⑶ 如何開發手機軟體
1、軟體開發的第一個流程是項目開發目的分析與確定，主要是在軟體開發商將開發項目確定下來之後，需要與需求方進行討論，確定需求方對於軟體開發的需要實現目標及其具體需要的功能等等，並確定是否可達成；
2、接下來就是需求分析，這個步驟也是為軟體開發的正常進行確定具體思路的階段。在確定軟體開發可進行後，必須要對客戶需要實現的軟體功能需求進行具體詳細的分析。同時應當考慮在開發過程中可能出現的變化情況，制定需求變更計劃隨時應對特殊情況的發生，保證軟體開發流程的順暢進行；
3、接下來就是軟體設計。軟體設計要根據上一階段對軟體功能需求分析的結果，來設計軟體系統的框架結構、功能模塊和資料庫等等。它主要分為總體設計和詳細設計兩個部分；
4、接下來就是編程實施步驟。編程也是根據對軟體設計，將軟體設計的各部分需求通計算純耐機程序代碼來實現運行，編程有統一、規范的程序編寫規則，保證軟體程序的易懂性、易維護性；
5、接下來就是軟體測試步驟。也就是在根據設計將客戶軟體需用編程代碼來實現之後，也就是軟體程序完成之後，需要對編寫的程序，形成整體構架、功能進行單元、組裝、系統三階段的測試，以測試程序編寫的正確性，以及對客戶需求功能滿足的充分性，以此來確定軟體是否達到開發要求，同時也是一個發現問題、糾正問題的過程；
6、通過以上核心環節完成了軟體開發，接下來就是在軟體開發達到客戶需斗核求之後，開發者將軟體系統交予客戶，並將軟體安裝程序、資料庫的數據字典、《用戶安裝手冊》、《用戶使用指南》、需求報告、設計報告、測試報告等產物交付給客戶，同時指導客戶進行軟體安裝、以及安裝技巧，提醒客戶注意軟體運行狀況、環境、伺服器及相關中間件的檢測與注意事項，知道客戶軟體的實際操作方法、使用流程等等問題，實現合同規定任務；
7、用戶在接受開發商交付的軟體開發結果，並進行實際操作、測試運行，實現滿意結果之後，對開發出來的軟體進行驗收；
8、定製開發的軟體通常都需要提供售後服務，定期對軟體進行維護，或者根據用戶出現的新需求，進行應用軟體程序的修改，使之不斷滿足客戶實空褲掘際需求。
⑷ 需求實例化輸出主要包括哪些內容
1.需求來源分析，主要輸出內容為需求來源表。一般採用電子表格方式進行整理。內容包括，需求編號、來源、描述、真實訴求等內容。編號主要記錄需求的數量。來源主要記錄誰提出的?客戶，還是市場人員某某。描述，主要是需求描述。真實訴求，主要是客戶背後的訴求需求，通過需求還原客戶的需求的真實性。比如，我自己曾經遇到過個真實的事情。我氏態需要買一瓶水，並不是我口渴，而真實需求是我需要零錢坐公交車。這里主要輸出內容為需求來源表，或叫需求池。
2.需求梳理，輸出內容主要為流程圖，分析模型，用戶圖像，最後形成的功能清殲前源單等內容。悔談獲取到的需求，通過流程圖，分析模型等。分析的需求功能。需要通過商業文檔的方式，說明該功能需求對於產品的價值，公司的利益等進行項目立項申請，申請完成後再做技術評估內容。當然，這個輸出內容是在項目立項的輸出內容（判斷需求是否要做的輸出內容）。實際在梳理需求主要輸出的內容，就是流程圖，分析模型，功能清單等文檔。
3.需求優先順序排期，這個過程的輸出內容主要是根據需求清單，按照緊急程度進行排期開發，比較緊急重要的作為優先排規劃開發。最後根據優先順序情況進行原型規劃，需求文檔編寫進入到下個環節。所以，這塊輸出內容主要是需求優先順序排期表。