一本无码人妻在中文字幕免费,亚洲精品成人网站在线,精品国产亚洲av麻豆尤物

搜索

APP

起點課堂會員權益

職業(yè)體系課特權

線下行業(yè)大會特權

個人IP打造特權

30+門專項技能課

1300+專題課程

12場職場軟技能直播

12場求職輔導直播

12場專業(yè)技能直播

會員專屬社群

榮耀標識

發(fā)布

注冊 | 登錄

產(chǎn)品經(jīng)理應該熟悉的軟件需求工程

叔寶

2020-10-21

1 評論 10175 瀏覽 70 收藏

25 分鐘

編輯導讀：產(chǎn)品經(jīng)理每天都在與需求打交道，《軟件需求工程》是產(chǎn)品經(jīng)理的必修課。本文是針對新人產(chǎn)品經(jīng)理的簡介性文章，目的是讓產(chǎn)品經(jīng)理在開始需求分析工作之前，對軟件需求的相關常識有所理解。希望文章對你有幫助。

一、需求工程

需求分析的重要性毋庸置疑。在20世紀80年代，逐步形成了軟件工程的子學科——軟件需求工程。90年代后，需求工程成為軟件界研究的重點之一。從1993年起，每兩年舉辦一次需求工程國際研討會（ISRE）；1994年起，每兩年舉辦一次需求工程國際會議（ICRE）。一些關于需求工程的工作小組相繼成立，使需求工程的研究得到了迅速進展。

1.1 需求的定義

IEEE軟件工程標準詞匯對需求的定義：

用戶解決問題或達到目標所需的條件或能力；
系統(tǒng)或部件要滿足合同、標準、規(guī)范或其他正式規(guī)定文檔所需具有的條件或能力；
反映上述的條件或能力的文檔說明（SRS，軟件需求規(guī)格說明書）。

業(yè)界對需求的通俗解釋：

需求來源于用戶的一些“需要”；
這些“需要”被分析、確認后形成完整的文檔；
該文檔詳細地說明了產(chǎn)品“必須或應當”做什么。

需要說明的是：并沒有一個清晰的、無二義的“需求”術語定義存在。真實的“需求”實際上在人們的腦海中，甚至在腦海深處自己都不知道。

“任何文檔形式的需求（比如：需求規(guī)格說明書）都只是一個模型/一種敘述?！?/p>
——Lawrence 1998

我們需要確保的是所有項目風險承擔者（stakeholders，干系人）在描述需求的文字的理解上務必達成共識。

1.2 需求的三個層次

業(yè)務需求是高層用戶（即客戶）提出的，比較籠統(tǒng)、寬泛，在項目視圖與范圍文檔中說明。
用戶需求是最終用戶（實際使用者）提出的，已經(jīng)比較具體了，在實例文檔或方案腳本中說明。
產(chǎn)品需求是開發(fā)團隊需要的（甲方監(jiān)理也需要），定義了開發(fā)人員要實現(xiàn)的軟件功能，使得用戶能完成他們的業(yè)務，從而滿足業(yè)務需求。

業(yè)務需求和用戶需求都是用通俗語言描述的，即用戶能看懂的語言；產(chǎn)品需求是用技術語言描述的，是開發(fā)人員能看懂的語言。用戶和開發(fā)人員是在用不同的視角觀察需求的，他們看到的內(nèi)容是不一樣的。就軟件而言，這里的產(chǎn)品需求就是軟件需求。

這樣的解釋可能還不容易理解，我來舉個“咖啡店新老板要更換定制咖啡杯”的例子。

業(yè)務需求：

咖啡店老板要訂做一種咖啡杯。

找高層用戶調(diào)查和確認需求是一件痛苦的事，因為他們不關注需求具體內(nèi)容，甚至常常不知道具體需求，他們關注的是“高屋建瓴”的比較務虛的內(nèi)容，例如：咖啡杯要好用、要漂亮之類的。

真正去調(diào)研需求，需要先識別出產(chǎn)品的最終用戶群，選出用戶代表，對用戶代表進行調(diào)研。這里的用戶代表為：消費者，喝咖啡；服務員，端咖啡；洗碗工，洗杯子。針對消費者調(diào)研可以采用問卷調(diào)查的方式來獲取用戶需求；針對服務員和洗碗工可以采用用戶訪談的方式來獲取用戶需求。

用戶需求：

消費者希望“杯子不能燙手”。消費者反饋：原來的杯子手柄很短，杯身隔熱效果很差，拿杯子的時候，手指容易被燙。
服務員希望“杯子在托盤上要穩(wěn)，不容易滑倒”。服務員反饋：原來的杯子瘦且高，杯底很滑，用托盤端盛滿咖啡的杯子時，杯子在托盤上容易打滑或傾倒。
洗碗工希望“杯子要容易清洗”。洗碗工反饋：原來的杯子內(nèi)壁不夠光滑，咖啡漬很難清洗。

這樣的用戶需求似乎很清楚了，但是你得明白這只是針對用戶側，對開發(fā)人員來說還是不清楚，因為這是自然語言描述的內(nèi)容，不是技術語言描述的內(nèi)容，開發(fā)人員無法針對此開展工作。

你還需要把以上內(nèi)容翻譯成為技術語言描述的產(chǎn)品需求：

采用隔熱材料，導熱率λ < 1.22 W/(m.K)，厚度> 5mm。經(jīng)過原型測試，采用了這樣的材料和厚度做成的杯子，加入100℃的熱咖啡時，杯子外壁的溫度大約50℃，輕微觸碰時不會感覺燙手。
杯底的靜摩擦系數(shù) μ > 0.5，滿杯的重心高度 h < 10cm。經(jīng)過原型測試，符合這種要求的杯子在裝滿咖啡時，不容易打滑或傾倒。
杯內(nèi)壁表面粗糙度 Ra < 1.0。經(jīng)過原型測試，符合這樣要求的陶瓷表面不容易附著咖啡液體，很容易清洗。

拿到這樣的產(chǎn)品需求，開發(fā)人員就可以開展工作了：

根據(jù)產(chǎn)品需求1，開發(fā)人員可以從工廠常用的陶瓷材料里選擇符合要求的，然后把杯子設計為略高于指定厚度。
根據(jù)產(chǎn)品需求2，開發(fā)人員可以把咖啡杯的底座設計為條紋或其他形式來加大摩擦系數(shù)，然后把咖啡杯設計為較矮、較寬的外形，以滿足在滿杯時的重心要求。
根據(jù)產(chǎn)品需求3，開發(fā)人員可以對咖啡杯的內(nèi)壁采用某種拋光或鍍釉的工藝來達到表面比較光滑的要求。

這就是需求的三個層次：高層用戶關注業(yè)務目標的實現(xiàn)，最終用戶關注業(yè)務執(zhí)行的效率和使用體驗，開發(fā)人員關注產(chǎn)品需求是否準確和清晰。

產(chǎn)品經(jīng)理就比較慘了，需要從多種角度去描述需求：高層用戶視角的需求，即市場需求文檔MRD；最終用戶視角的需求，即業(yè)務需求文檔BRD；開發(fā)人員視角的需求，即產(chǎn)品需求文檔PRD（或軟件需求文檔SRS）。

“需求”，這是所有人都可以說上幾句的話題。但最專業(yè)的，還是產(chǎn)品經(jīng)理描述的需求，這正是產(chǎn)品經(jīng)理的價值所在。

1.3 需求工程RE

應用已證實有效的技術、方法進行需求分析，確定客戶需求，幫助分析人員理解問題并定義目標系統(tǒng)的所有外部特征的一門學科，即需求工程。需求工程通過合適的工具和記號系統(tǒng)地描述待開發(fā)系統(tǒng)及其行為特征和相關約束，形成需求文檔，并對用戶不斷變化的需求演進給予支持。

通俗地說，需求工程就是把工程方法引入到需求領域，用工程方法開發(fā)清晰的、一致的，沒有沖突、重疊和遺漏的需求，用工程方法來管理需求和控制變更。

1.4 軟件需求工程SRE

軟件工程的子學科，一門分析并記錄軟件需求的學科，它把系統(tǒng)需求分解成一些主要的子系統(tǒng)和任務，把這些子系統(tǒng)或任務分配給軟件，并通過一系列重復的分析、設計、比較研究、原型開發(fā)過程把這些系統(tǒng)需求轉(zhuǎn)換成軟件的需求描述和一些性能參數(shù)。

需求工程是系統(tǒng)工程和軟件工程的分支，分為系統(tǒng)需求工程（針對由軟硬件共同組成的整個系統(tǒng)）和軟件需求工程（專門針對純軟件部分）。我們都知道軟件需求是指用戶對目標軟件系統(tǒng)在功能、行為、性能、設計約束等方面的期望。軟件開發(fā)的最終目的是生產(chǎn)出滿足客戶需求的軟件產(chǎn)品，滿足客戶需求是軟件開發(fā)的本質(zhì)。

1.5 為什么有軟件需求工程

軟件需求是軟件開發(fā)中的關鍵問題，沒有需求就沒有軟件。

開發(fā)軟件系統(tǒng)最困難的部分就是準確說明開發(fā)什么。最困難的概念性工作是編寫出詳細的需求，包括所有面向用戶、面向機器或其他軟件系統(tǒng)的接口，此工作一旦失誤，將會帶來極大的危害，修改也極其困難。

——Frederick P. Brooks，《No Silver Bullet》

備注：Frederick P. Brooks，60年代初只有29歲時就主持了被稱為人類從原子能時代進入信息時代標志的IBM/360系列計算機的開發(fā)工作，取得輝煌成功，名噪一時。他作為硬件和軟件的雙重專家和出色的教育家始終活躍在計算機舞臺上，在計算機技術的諸多領域中都做出了巨大的貢獻，直到69歲才獲得遲來的榮譽——1999年的圖靈獎。

需求是軟件項目成功的核心，良好的需求可以減少開發(fā)后期的返工和整個維護階段的工作，做好需求等于項目成功了一半。

1.6 需求溝通是如此困難

需求是以交流為核心的工作，如果在開發(fā)過程的各個環(huán)節(jié)缺乏交流或交流不恰當，就會導致下圖（如果學計算機，你必定見過此圖）的效果。

客戶如此描述需求：我有三個小孩，我需要一個能三個人用的秋千。它由一繩子吊在我家花園里的樹上。
項目經(jīng)理如此理解：秋千這東西太簡單了，不就是一塊板子，兩邊用繩子吊起來，掛在樹的兩個枝椏上嘛。
分析員如此設計：真是無知的項目經(jīng)理，兩個樹枝掛上秋千哪還能蕩得起來？除非是把樹從中截斷再用支架支起來，這樣就滿足要求了。
程序員如此編碼：哦，兩條繩，一塊板，一棵大樹，接在樹的中段。太簡單了，“啪啪啪（敲擊鍵盤的聲音）”，搞定！
商業(yè)顧問如此詮釋：您的需求我們已經(jīng)完成了，我們通過人體工學和工程力學等多方面研究，實現(xiàn)了本產(chǎn)品。本著為顧客服務出發(fā)，我們的秋千產(chǎn)品在使用時，將給您帶來如同游樂園里的過山車一樣刺激的感受，如同你在地面上坐沙發(fā)一樣的舒適與安全。
資料員如此寫文檔：這么小的工程沒有文檔很正常，只要有需求說明書與合同就可以了。
實施人員如此交付：我們的產(chǎn)品用戶自己都可以完成安裝，只要把繩子系在樹上就可以了。
客戶得到如此結果：花了建過山車的投資，得到個如此產(chǎn)品，也是醉了。
維戶人員如此支持：我們提供不了什么技術支持，但我們態(tài)度很好，我們的隊伍在成長中。
項目完成了，真實的需求也清楚了：客戶需要一個跳圈，給三個小孩養(yǎng)的小狗訓練和玩耍。

很明顯，項目開始時客戶也不知道真實的需求，他表述的只是他理解的需求（小孩曾經(jīng)給他說過，但顯然他并沒有認真聆聽）。項目經(jīng)理沒有認真調(diào)研需求，他甚至根本不知道最終用戶是誰。項目經(jīng)理和分析員之間，分析員和程序員之間，明顯沒有良好的交流和反饋。像漏斗一樣，每個環(huán)節(jié)都在遺失信息；像傳聲筒游戲一樣，每個環(huán)節(jié)都在加入自己想當然的理解。所以，最終的結果必然的天差地別！最重要的是，他們?nèi)币粋€打通各個環(huán)節(jié)的產(chǎn)品經(jīng)理。

對于產(chǎn)品經(jīng)理，有個常識你必須知道：

用戶嘴里說的，不一定是他腦子里想的。他腦子里想的，也不一定就是業(yè)務實際運行的情況。業(yè)務的現(xiàn)狀，不一定是合理的，也許正是客戶需要你幫助改進的。

所以，我們要傾聽用戶，但不能完全按照用戶說的去做。我們要傾聽多方用戶代表，特別是要關注那些互相沖突、需要妥協(xié)的部分。我們不光要聽用戶怎么說的，還要看他怎么做的。我們要聽免費用戶的免費意見，更要聽付費用戶的付費意見。我們要聽用戶的意見，更要聽決定付錢的客戶的意見……等等，自己總結吧，自己總結的才是最適合自己的，我不想展開了。

1.7 軟件需求工程框架

CMMI對軟件需求的描述集中在兩個PA里：需求開發(fā)RD（3級），需求管理REQM（2級）。

需求獲?。簭挠脩臬@取、挖掘需求。
需求分析：提煉用戶需求，分析轉(zhuǎn)化，需求分析的過程重視用戶參與。
需求定義：把分析得到的需求文檔化，編制需求規(guī)格說明書。
需求驗證：確定需求準確、完整，得到實現(xiàn)，對應測試活動。
需求變更控制：對需求的變更進行控制，降低影響。
需求跟蹤：監(jiān)控需求在開發(fā)過程中不走樣、不遺漏。

二、需求開發(fā)

2.1 CMMI關于需求開發(fā)的描述

SG1 干系人的需要、期望、約束與接口得到收集并轉(zhuǎn)化為客戶需求。

– SP1.1 挖掘干系人對產(chǎn)品生命周期所有階段的需要、期望、約束與接口。

– SP1.2 將干系人的需要、期望、約束與接口轉(zhuǎn)換為劃分了優(yōu)先級的客戶需求。

SG2 客戶需求得到提煉與細化，以開發(fā)產(chǎn)品與產(chǎn)品組件需求。

– SP2.1 依據(jù)客戶需求，建立并維護產(chǎn)品與產(chǎn)品組件需求。

– SP2.2 為各產(chǎn)品組件分配需求。

– SP2.3 功能之間（或者是對象或其它邏輯實體之間）的接口進行了識別。

SG3 需求得到分析與確認。

2.2 需求獲取方法

相比“需求獲取”，我個人更喜歡“需求挖掘”這個詞。因為“需求獲取”讓我感覺需求就是樹上的果子、地里的莊稼，只要產(chǎn)品經(jīng)理去采摘就可以了。這樣的描述，未免低估和輕視了得到需求的困難。反之，“需求挖掘”讓我感覺需求是地里的金子等礦藏，需要產(chǎn)品經(jīng)理去彎腰、埋頭挖掘，而且挖掘了也不一定有成果，因為你需要尋找正確的地方挖，否則只能是徒勞。另外，在很多人都挖過的地里，你只有挖得更深才可能挖到礦藏。

常見的需求挖掘方法有：客戶交流、競品分析、市場調(diào)研、問卷調(diào)查、技術引導及其他。

客戶交流是最常用的需求挖掘方法。大多數(shù)情況下，用戶雖然知道自己的需求，但他們并不一定能或者也不想準確表達他們的需求是什么。如果用戶第一次告訴你需求就是這些了，不要輕信，繼續(xù)刨根問底，直到你們都筋疲力盡。

產(chǎn)品經(jīng)理作為一個需求分析者，所謂的聆聽客戶需求，指必須透過客戶所提出的表面需求理解他們的真實需求，避免理解不同會帶來的期望差異。盡量把客戶所持的假設解釋清楚，特別是那些發(fā)生沖突的部分，甚至要逐字逐句去理解，以明確客戶沒有表達清楚但又想加入的特性或特征。

有經(jīng)驗的產(chǎn)品經(jīng)理能深入地理解客戶的業(yè)務（可以提取做大量準備工作），這樣他才能通過詢問客戶一些合適的問題（需要提前設計），從而挖掘出高價值的用戶需求。

2.3 需求分析方法

需求分析方法大致分為兩類：模型法和原型法，都可以從不同角度說明需求，把一些模糊的需求變得清晰，便于理解，減少返工。不管是模型，還是原型，都是用來增強自然語言描述的需求規(guī)格說明，而不是代替。

模型一般分為面向過程的模型和面向?qū)ο蟮哪Ｐ蛢深悺＝⑿枨竽Ｐ偷姆治鲞^程，稱為“需求建?！薄＝５哪康氖前涯：臇|西搞清晰，把復雜的東西搞簡化，而不是把簡單的東西搞復雜（這是商務人員做的事，比如：電信運營商的話費套餐）。

原型法是一種減少軟件項目失敗風險的技術，它可以加快開發(fā)進度，增加用戶滿意度，減少需求錯誤和用戶界面缺陷。

2.4 需求建模

常用的面向過程的需求建模方法（結構化分析）：

功能模型：數(shù)據(jù)流圖DFD
行為模型：流程圖Flow Chart
狀態(tài)模型：狀態(tài)遷移圖STD
數(shù)據(jù)模型：實體關系圖ERD

常見的面向?qū)ο蟮男枨蠼７椒ǎ?/p>

功能模型：用例圖
行為模型：活動圖
狀態(tài)模型：狀態(tài)圖
交互模型：時序圖（也叫“順序圖”）

2.5 原型設計

建立原型的目的是為了解決在產(chǎn)品開發(fā)早期需求不確定的問題，利用這些不確定來判斷系統(tǒng)中那一部分需要建立原型和希望從用戶對原型的評價中獲得什么信息。其優(yōu)點是能減少軟件項目失敗風險，加快開發(fā)進度，增加用戶滿意度，減少需求錯誤，尤其是界面錯誤。其風險是當用戶或項目經(jīng)理看到一個正在運行的原型，會以為產(chǎn)品即將完成。

對于發(fā)現(xiàn)和解決需求中的二義性，原型是一種很好的方法。關于原型，不在這里贅述了，后面會另起一文。

常用的原型設計方法：草圖（手繪圖）、線框圖、交互原型、高保真原型。

原型法不僅是需求分析方法，同時是需求驗證方法。

2.6 需求定義的方法

采用需求文檔模板。
指明需求的來源。
為每項需求建立編號。
設定需求優(yōu)先級。
記錄業(yè)務規(guī)范。
創(chuàng)建需求跟蹤矩陣。
其他方法。

2.7 好需求的標準

清晰：不同的讀者只能從需求文檔中得到唯一的解釋說明，沒有二義。所以表述中不要出現(xiàn)“也許、大概、可能、左右”之類的表述模糊的詞語，比如：響應時間5秒左右，寬度大概10米。
完整：一個不能少，所有功能都要描述。
一致：上下文一致，局部與整體一致。
可行：每一項需求必須在已知系統(tǒng)和環(huán)境的限制范圍內(nèi)可以實現(xiàn)，不能是空中樓閣。
可驗證：每一項需求必須能夠用測試用例或其他方法來驗證是否按定義實現(xiàn)了。
可跟蹤：每一項需求必須能與HLD、LLD、Code、UT、IT、ST等各階段工作產(chǎn)品對應跟蹤。