軟件過程的需求管理

軟件過程管理-Ch.4軟件過程的需求管理2021/3/111軟件過程的需求管理開發(fā)軟件系統(tǒng)最為困難的部分就是準確說明開發(fā)什么。——弗雷德里克·布魯克斯2021/3/112理解1.什么是需求2.了解客戶、最終用戶、間接用戶3.需求工程基本概念4.需求開發(fā)的主要困難與對策5.如何開展需求調查6.如何進行需求分析7.什么是好的需求規(guī)格說明書8.如何定義產品需求9.需求管理：確認、跟蹤、變更控制人們并不清楚應該做什么，卻一直忙碌不停地開發(fā)。2021/3/1131.什么是需求1.1需求的基本概念

寬泛地講，需求來源于用戶的一些“需要”，這些“需要”被分析、確認后形成完整的文檔，該文檔詳細地說明了產品“必須或應當”做什么。所以如果只有一些零碎的對話、資料或郵件，你就以為自己已經掌握了需求，那是自欺欺人。1.2需求的重要性FrederickBrooks在他1987年經典文章“NoSilverBullet”中闡述了需求的重要性：開發(fā)軟件系統(tǒng)最困難的部分就是準確說明開發(fā)什么。最困難的概念性工作是編寫出詳細的需求，包括所有面向用戶、面向機器和其它軟件系統(tǒng)的接口。此工作一旦做錯，將會給系統(tǒng)帶來極大的損害，并且以后對它修改也極為困難。

需求是產品的根源，需求工作的優(yōu)劣對產品影響最大。就像一條河流，如果源頭被污染了，那么整條河流也就被污染了。

國內軟件業(yè)的痼疾：人們并不清楚究竟該做什么，但卻一直忙碌不停地開發(fā)。

2021/3/1142.了解客戶、最終用戶、間接用戶2.1基本概念“用戶”（user）是一種泛稱，它可細分為“客戶”（customer）、“最終用戶”（theenduser）和“間接用戶”（或稱為關系人）。掏錢買軟件的用戶稱為客戶，而真正操作軟件的用戶叫最終用戶?？蛻襞c最終用戶可能是同一個人也可能不是同一個人。2.2客戶是掏錢買軟件的人，所以他是“上帝”

某飯店經理在解釋“先有雞還是先有蛋”這個哲學問題時，精辟地闡述了客戶的地位：如果顧客先點雞，那么就先有雞；如果顧客先點蛋，那么就先有蛋。“現(xiàn)代營銷學之父”菲利普?科特勒所著的《市場營銷導論》是這樣描述客戶的：客戶永遠是本公司的座上客?？蛻舨⒉灰蕾囄覀儯覀儏s依賴客戶。客戶不是我們工作的障礙，而是我們工作的目標。我們并不因為服務于他而對他有恩，他卻因為給予我們服務于他的機會而有恩于我們?？蛻舨皇俏覀円c之爭辯和斗智的人。從未有人曾在與客戶的爭辯中獲勝?？蛻羰前阉挠麕Ыo我們的人，因此我們的工作就是滿足這些欲望，從而使客戶和我們共同獲益。與客戶打交道的主要目的是：一是獲取需求，二是簽合同。不要把錢仍到水里。2021/3/1152.了解客戶、最終用戶、間接用戶2.3即使最終用戶不是上帝，也算是“上帝”的“親戚”，同樣怠慢不得。如果項目規(guī)模比較大，那么開發(fā)方與最終用戶的來往就比較多。如從最終用戶那里獲取詳細的需求，請最終用戶試驗軟件，對最終用戶進行培訓等等。公司新員工上產品培訓課，有位小領導匆匆趕來作指示：“隔壁班正在給電信局的員工們進行培訓，他們都是上帝派來的，大家要注意形象。由于休息室空間有限，請大家自覺讓位。午休時他們可以躺著睡，我們只能坐在位置上打個盹兒…….?！?.4重視“間接用戶”，千萬別“大意失荊州”

間接用戶既不掏錢買該軟件產品，也不使用該軟件，但是它可能對軟件產品有很大的影響。例如，財務軟件開發(fā)商在把“財務軟件”賣給客戶之前，這個“財務軟件”必須得到國家財政部的批準。否則即使該軟件的功能是完美的，但卻被政府認為是非法的。所以國家財政部就是所有財務軟件的間接用戶，它不僅不付錢給財務軟件開發(fā)商，反而要收取鑒定費、手續(xù)費等。同理，市面上流通的信息安全軟件、殺病毒軟件必須得到國家公安部的批準，否則軟件開發(fā)商被逮住后戴上“非法經營”的帽子就慘了。

2021/3/1163.需求工程基本概念3.1什么是需求工程把所有與需求直接相關的活動通稱為需求工程。需求工程中的活動可分為兩大類，一類屬于需求開發(fā)，另一類屬于需求管理。需求工程的結構圖

2021/3/117軟件需求工程所有與需求直接相關的活動統(tǒng)稱為需求工程，需求工程分為了兩個部分：需求開發(fā)和需求管理。其中，需求開發(fā)又分為了需求獲取、需求分析、需求定義和需求驗證4個部分，而需求管理則包含了變更控制、版本控制、需求跟蹤和需求狀態(tài)跟蹤軟件需求包括三個不同的層次：業(yè)務需求、用戶需求和功能需求（也包括非功能需求）。2021/3/118軟件需求工程業(yè)務需求（businessrequirement）反映了組織機構或客戶對系統(tǒng)、產品的概括的目標要求，它在項目視圖與范圍文檔中予以說明。主要的目的是對企業(yè)目前的業(yè)務流程進行評估，得出一個業(yè)務前景。業(yè)務需求的確定對后面的用戶需求和功能需求起到了限制作用。用戶需求(userrequirement)文檔描述了用戶使用系統(tǒng)而完成的任務的集合，用戶需求在用戶案例（usercase）文檔或方案腳本中予以說明。收集和分析用戶需求是不容易的，因為很多需求是隱形的，很難獲取，更難保證需求完整，而需求又是易變的，這就要求用戶和開發(fā)人員進行充分地交流。功能需求(functionalrequirement)定義了開發(fā)人員必須實現(xiàn)的軟件功能，它源于用戶需求。功能需求是軟件需求說明書中最重要的部分之一，它在開發(fā)、測試、質量保證、項目管理以及相關項目功能中都起了重要的作用。非功能需求描述了系統(tǒng)展現(xiàn)給用戶的行為和執(zhí)行的操作等，包括要遵從的業(yè)務規(guī)則、人機接口、安全性和可靠性等要求。2021/3/1193.需求工程基本概念3.4需求工程的一些感悟不論是合同項目還是自主研發(fā)的產品，都必須開展需求開發(fā)和需求管理活動。開發(fā)者對待需求工程的態(tài)度可分“被動型”、“主動型”和“領先型”三種，只有后兩種才有可能開發(fā)出成功的產品?！氨粍有汀笔侵搁_發(fā)者被動地對待需求工程中的各項活動，能少干則少干，能偷懶則偷懶。他們認為需求是用戶的事情而不是自己的事情。開發(fā)過程中經常發(fā)生需求變更，導致產品迷失方向，不是半途而廢就是陷入半死不活的狀態(tài)?！爸鲃有汀笔侵搁_發(fā)者積極地開展需求工程中的各項活動。他們把獲取準確的需求當作自己的職責，會想盡一切辦法克服需求開發(fā)和需求管理過程中的困難，而不是找借口推卸責任。俗話說“良好的開端是成功的一半”，“主動型”需求工程是開發(fā)成功產品的必備條件?！邦I先型”是需求工程的最高境界。開發(fā)者發(fā)掘了連用戶自己都沒有意識到的需求，導致用戶跟著新產品跑而不是新產品圍著用戶轉，這叫引導消費。需求工程做到這個份上，才能使產品立于不敗之地，長盛不衰。4.需求開發(fā)的主要困難與對策4.1知識技能問題

應用域的知識是無邊無際的，任何人都不可能是“萬事通”。俗話說“隔行如隔山”，需求分析員可能是某一領域的專家，但當他接手陌生的業(yè)務時，他可能是個“無知”者。一個企業(yè)要謀求發(fā)展，不能總在做老的業(yè)務。人一生中會有許多充滿挫折的“第一次”，不可以逃避。當需求分析員缺乏應用域知識時，他該怎么辦？首先他要有勇氣做事，否則連實踐的機會都沒有。其次他應當趕緊補習應用域知識，不論是通過自學還是培訓的方式，否則他很難與用戶交流。如果可能的話，開發(fā)方最好請既懂軟件又懂應用域知識的行家來幫忙。4.2態(tài)度問題

相當多的開發(fā)人員習慣于被動地對待需求開發(fā)。每當遇到麻煩、挫折時，他們會發(fā)牢騷，找出一堆用戶的毛病。很多開發(fā)人員錯誤地以為：需求是用戶的事情，不是我們的事情。我們?yōu)橛脩糸_發(fā)軟件，難道用戶不該告訴我們應當開發(fā)什么嗎？如果用戶說不清楚需求，或者經常變更需求，這類問題是用戶產生的，應當由他們自己負責。

用戶說不清楚需求或者需求發(fā)生變更，這些都是常見的問題，并不是絕癥，是人們可以設法解決的?？杀氖情_發(fā)人員把這些問題當成了借口，不愿主動攻克問題，導致需求問題擴散到整個軟件開發(fā)過程，產生太多的后患。軟件企業(yè)的領導應當給具有錯誤觀念的開發(fā)人員們洗腦：需求分析員的天職就是在有限的時間內獲取準確而細致的用戶需求，如果做不到就是失職，不要找借口。

4.需求開發(fā)的主要困難與對策4.3合作關系如果需求分析員不能與用戶建立良好的合作關系，那么他們在需求開發(fā)過程中會很疲憊。倘若用戶不能很好地配合需求分析員，那并不表示他是個壞蛋。因為用戶有他自己的想法：我回答了你們的問題，講了該講的。我們付錢給你們，難道還要我伺候你們不成？我還要干自己的事情，別打擾我了。你們自己想辦法把活干好吧

……。

對于一些競標項目，在合同未簽訂之前的需求開發(fā)工作尤為困難。用戶未必會買你的產品，他不會投入很多精力來協(xié)助你搞需求開發(fā)。需求分析員不是銷售人員，他們不可能象銷售人員那樣通過某些手段籠絡住用戶就能成功。出色的需求分析員不僅要有過硬的專業(yè)知識，還要具備較強的交流、溝通能力。開發(fā)方與用戶的合作關系對需求開發(fā)而言是至關重要的。對于重大的、復雜的項目，我們不能完全期望雙方能夠自發(fā)地建立起良好地合作關系，這樣風險太大。開發(fā)方和用戶方在開展需求開發(fā)之前，雙方協(xié)商并撰寫“用戶在需求工程中的權利與義務”，即以協(xié)議的方式確定合作關系?！昂迷挕焙汀俺笤挕倍颊f在前頭，這樣能減少今后的摩擦。如果條件允許的話，開發(fā)方最好為用戶舉辦關于需求工程的培訓，這樣的培訓將使用戶明白需求的重要性以及忽視需求的危害性，從而促使他們積極友善地參加需求工程中的各項活動。4.需求開發(fā)的主要困難與對策用戶在需求工程中的“權利”1.有權要求開發(fā)方派遣資質合格的需求分析員和相關人員。2.有權要求開發(fā)方采用用戶熟悉的語言來描述需求，即開發(fā)方必須提供用戶看得懂得需求文檔。3.有權審查需求文檔，并對有爭議的需求作出決策。如果認為需求文檔不能準確地反映用戶真實的意愿，可以拒絕在需求文檔上簽字。4.如果用戶想要變更需求，有權要求開發(fā)方對該變更將產生的影響作出真實可信的評估，以便用戶決定是否變更需求。用戶在需求工程中的“義務”1.以積極友善的態(tài)度與開發(fā)方人員交流、協(xié)作，盡可能地為開發(fā)方人員提供工作和生活上的便利。2.樂意接受需求分析員的采訪，在不泄漏機密的前提下盡可能地回答需求分析員的問題。3.在不泄漏機密的前提下，盡可能地向需求分析員提供與需求相關的材料。4.與需求分析員共同評審需求文檔，確保需求文檔準確地反映用戶真實的意愿。4.需求開發(fā)的主要困難與對策4.4用戶說不清楚需求用戶說不清楚需求是普遍現(xiàn)象，這是讓開發(fā)人員頭痛的大問題。有些用戶真的不知道需求是什么，或者對需求只有朦朧的感覺，他當然說不清楚需求。例如開發(fā)方的營銷人員水平比較高，他能夠在用戶不清楚自己要什么的情況下引導用戶“消費”。例如前些年全國各地的很多政府機構大搞網絡建設。這些機構的領導和辦公人員大多數(shù)不清楚網絡干什么用，就讓開發(fā)人員替他們設想需求吧，反正是花公家的錢。有些用戶雖然心里明白想要什么，但卻說不清楚需求。

比如說買鞋子。我們非常了解自已的腳，但很難用語言說清楚腳的大小和形狀。通常拿鞋子去試，試穿時感覺到舒服才會買鞋。需求分析員絕不能以用戶說不清楚需求為借口而草率地對待需求開發(fā)工作，否則會連累整個開發(fā)團隊的。無論是什么原因導致用戶說不清楚需求，需求分析員必須設法搞清楚用戶真正的需求，這是需求分析員的職責，也是職業(yè)的挑戰(zhàn)。

4.需求開發(fā)的主要困難與對策4.5雙方誤解需求人們在交流的時候，經常會發(fā)生“問非所求，答非所問”的事情。有時用戶會把開發(fā)人員的建議或答復給想歪了：有一個軟件開發(fā)人員滔滔不絕地向用戶講解在“信息高速公路上做廣告”的種種好處，用戶聽得津津有味。最后，心動的用戶對軟件開發(fā)人員說：“好得很，就讓我們馬上行動起來吧。請您決定廣告牌的尺寸和放在哪條高速公路上，我立即派人去做?！倍脩舯磉_的需求，不同的開發(fā)人員可能有不同的理解。如果需求分析員誤解了需求，那會導致后續(xù)的不少開發(fā)人員將錯就錯、白干活。就像作文寫跑題了，寫得再好也白搭。這類錯誤連高智商的外星人都不能避免：有個外星人間諜潛伏到地球刺探情報，它給上司寫了一份報告：“主宰地球的是車。它們喝汽油，靠四個輪子滾動前進。嗓門極大，在夜里雙眼能射出強光?！腥さ氖?，車里住著一種叫作‘人’的寄生蟲，這些寄生蟲完全控制了車?！辈徽撌菑碗s的項目還是簡單的項目，需求分析員和用戶都有可能誤解需求。所以需求確認工作（屬于需求管理）必不可少。

4.需求開發(fā)的主要困難與對策4.6開發(fā)人員寫不好需求文檔需求調查工作不充分，獲取的需求信息太少或者太亂，以至于寫不成需求文檔。古時候，一書生在考試前補習“寫文章”，成天愁眉苦臉。其夫人甚為不解，問：“相公，你寫文章比我生小孩還難嗎？”書生長嘆一聲：“娘子你哪里知道我的難處??！你生小孩時肚子里有東西，可我寫文章時肚子里沒東西啊?！彼砸雽懗龊玫男枨笪臋n，前提條件是把需求調查工作做好。

開發(fā)人員寫作能力比較差，雖然在調查過程中已經獲得了不少需求信息，卻寫不出好的需求文檔來。可以毫不夸張地說，國內90％以上的軟件開發(fā)人員，他們的寫作能力遠不及開發(fā)能力。提高開發(fā)人員寫作能力的根本辦法就是讓他們多練習寫文檔，熟能生巧。另外，企業(yè)應當提供合適的文檔模板以及比較好的示例文檔，盡可能地降低寫作難度。

4.需求開發(fā)的主要困難與對策4.7用戶經常變更需求需求變更通常會對項目的進度、人力資源、經費產生很大的影響，這是開發(fā)商非常畏懼的問題。如果在項目開發(fā)的初始階段，開發(fā)人員和用戶沒有搞清楚需求或者搞錯了需求，到了項目開發(fā)后期才將需求糾正過來，導致產品的部分內容需要重新開發(fā)。毫無疑問，這種需求變更將使項目付出額外的代價。這種損失是由于雙方工作失誤造成的，雙方應當好好反省，認真學習需求開發(fā)和管理的方法，避免再犯相似的錯誤。如果由于市場變化而導致產品需求發(fā)生變更，開發(fā)商大可不必為此煩惱，應當高興才對。倘若市場靜如死水，那么開發(fā)商吃了“上一頓”就沒有“下一頓”。正因為市場在變化，才會產生更多商機，聰明的開發(fā)商才會有活干，有錢賺。

其實需求變更并不可怕，可怕的是需求變更失去控制，導致項目混亂。所以需求變更控制是需求工程的重要活動。

需求開發(fā)需求開發(fā)的目的是通過調查與分析，獲取用戶需求并定義產品需求。獲取數(shù)據(jù)分析、處理目標系統(tǒng)模型需求獲取系統(tǒng)分析員從數(shù)據(jù)流和數(shù)據(jù)結構出發(fā)，找出系統(tǒng)各元素之間的聯(lián)系、接口特征及設計限制、能否滿足功能需求2021/3/1118需求獲取概述需求獲取是通過各種途徑獲取用戶的需求信息（原始材料），產生《用戶需求說明書》。

2021/3/1119需求獲取的方法需求研討會頭腦風暴用例模型訪談角色扮演原型法2021/3/1120基于用例的需求獲取執(zhí)行者的識別誰使用系統(tǒng)的主要功能？誰將提供、使用和刪除信息？誰負責維護、管理并保持系統(tǒng)正常運行？誰會對某一特定需求感興趣？系統(tǒng)的外部資源是什么？系統(tǒng)需要和哪些外部系統(tǒng)交互？用例的識別某個執(zhí)行者要求系統(tǒng)為其提供什么功能？該執(zhí)行者需要做哪些工作？執(zhí)行者需要閱讀、創(chuàng)建、銷毀、更新或存儲系統(tǒng)中哪些（類）信息？系統(tǒng)中的事件一定要告之執(zhí)行者嗎？執(zhí)行者需要告訴系統(tǒng)一些什么嗎？那些系統(tǒng)內部的事件從功能的角度代表什么？由于新功能的識別，執(zhí)行者的日常工作被簡化或效率提高了嗎？系統(tǒng)需要什么樣的輸入輸出？輸入在哪里？輸出去往哪里？該系統(tǒng)的當前情況存在哪些問題？2021/3/1121課堂案例：學生學籍處理業(yè)務學生學籍處理業(yè)務每學期開學時，各學辦進行注冊管理，注冊信息記錄在在校生信息卡中。學生轉專業(yè)由本人向所在系提出申請，教務處審批。在本系內轉專業(yè)，由學生所在系考核同意，報教務處審批；在學校范圍內轉專業(yè)（跨系），由學生所在系推薦，擬轉入系考核同意，報教務處審批。轉專業(yè)手續(xù)應在每學年開學前辦理。2021/3/1122課堂案例：學生學籍處理業(yè)務2021/3/1123需求定義需求定義指的是解釋涉眾需求,并根據(jù)需求規(guī)模整理成對要構建系統(tǒng)的明確的說明。前景文檔是用一般的語言定義系統(tǒng)特征的文檔軟件需求規(guī)格說明書是用更專業(yè)的術語定義系統(tǒng)特征的文檔。

2021/3/1124軟件需求規(guī)格說明書0.文檔介紹0.1文檔目的0.2文檔范圍0.3讀者對象0.4參考文檔0.5術語與縮寫解釋1.產品介紹提示：(1)說明產品是什么，什么用途；(2)介紹產品的開發(fā)背景。2.產品面向的用戶群體提示：(1)描述本產品面向的用戶(客戶、最終用戶)的特征；(2)說明本產品將給他們帶來什么好處？特們選擇本產品的可能性有多大？3.產品應當遵循的標準或規(guī)范提示：闡述本產品應當遵循什么標準、規(guī)范或業(yè)務規(guī)則。2021/3/11254.產品的功能需求……FunctionC.1FeatureC……FunctionB.1FeatureB……FunctionA.1FeatureA描述功能名稱、標識符功能類別5.產品的非功能需求質量需求軟硬件需求用戶界面需求描述需求名稱、標識符需求類別6.其他需求軟件需求規(guī)格說明書2021/3/1126需求確認為什么需要需求評審？在哪個階段發(fā)現(xiàn)成本率需求1設計3-6編碼10功能測試15-40驗收測試30-70發(fā)布之后40-1000修訂一個缺陷的相關成本2021/3/1127需求確認如何進行需求評審？（1）分層次評審目標性評審功能性評審操作性評審（2）分階段評審2021/3/11282需求評審面臨的困難需求評審的一個通病是“虎頭蛇尾”。需求評審的確乏味，也比較費腦子。剛開始評審時，大家都比較認真，越到后頭越馬虎。

需求評審涉及的人員可能比較多，有些時候讓這么多人聚在一起花費比較長的時間開會并不容易（例如有些人可能出差在外，有些人可能事務纏身）。沒有必要把所有事情擠在一塊做，需求開發(fā)是循序漸進的過程，需求評審也可以分段進行。這樣每次評審的時間比較短，參加評審的人員也少一些，組織會議就比較容易。開評審會議時經常會“跑題”，導致評審效率很低。有時話匣子一打開后關不上，大家越扯越遠，結果評審會議變成了聊天會議。主持人應當控制話題，避免大家討論與主題無關的東西。

開評審會議時經常會發(fā)生爭議。適當?shù)臓幾h有利于澄清問題，比什么東西都一致贊成要好。然而當爭議變?yōu)闋幊硶r就壞事了，爭吵不僅對評審工作沒有好處，而且會無意中傷害同事們的感情。人們在很多時候分不清楚自己究竟是“堅持真理”還是“固執(zhí)己見”。毫不妥協(xié)或者輕易妥協(xié)都不是好辦法。我們應當養(yǎng)成良好的習慣：不要一棍子打死異己的觀點，嘗試著讓自己站在他人的立場思考問題，這樣你會找到比較滿意的答案。

需求確認如何保證需求規(guī)格說明書的質量？正確性完備性易理解性一致性可行性健壯性易修改性易測試性和可修改性易追溯性兼容性2021/3/1130.什么是好的需求規(guī)格說明書.1正確

需求規(guī)格說明書應當正確地反映用戶的真實意圖，“正確”是《產品需求規(guī)格說明書》最重要的屬性。如果“不正確”僅僅是由于錯別字造成的，那么多檢查幾遍文檔就能解決問題。真正的困難是開發(fā)者和用戶自己都不明白用戶究竟“想要什么”和“不要什么”。為確保需求是正確的，開發(fā)方和用戶必須對《需求規(guī)格說明書》進行確認。.2清楚

清楚的需求讓人易讀易懂。清楚的反義詞是“難讀”、“難理解”。你可以采用反問的方式來判斷需求文檔是否清楚：文檔的結構、段落是否亂七八糟？上下文是否不連貫？文檔的語句是否含糊其詞、羅里羅嗦？看了半天是否還不明白需求究竟是什么？.3無二義性

“無二義性”是指每個需求只有唯一的含義。如果一個人說的話，不同的人可能有不同的理解，那么這句話就有二義性。如果需求存在二義性，將會導致人們誤解需求而開發(fā)出偏離需求的產品。為了使需求無二義性，人們在寫《產品需求規(guī)格說明書》時措詞應當準確，切勿模棱兩可。什么是好的需求規(guī)格說明書.4一致

“一致”（Consistent）是指《產品需求規(guī)格說明書》中各個需求之間不會發(fā)生矛盾。矛盾常常潛伏在需求文檔的上下文中。.5必要

《產品需求規(guī)格說明書》中的各項需求對用戶而言應當都是必要的?？梢园选氨匾北扔鳛椤把┲兴吞俊??！氨匾蓖耙徊?，要么是“畫蛇添足”要么是“錦上添花”?！爱嬌咛碜恪憋@然是壞事，會導致開發(fā)人員多干一些吃力不討好的工作。所以要盡量剔除需求規(guī)格說明書中“畫蛇添足”的那些需求?！板\上添花”是好事，可能會讓用戶獲得比期望更多的喜悅，但是眼前用戶不會為此多付錢。開發(fā)者應當集中精力先完成必要的需求，如果條件允許則再做“錦上添花”的需求。為了避免主次顛倒，應當在《產品需求規(guī)格說明書》中將那些“錦上添花”的需求設置為較低的優(yōu)先級。.6完備“完備”（Complete）是指《產品需求規(guī)格說明書》中沒有遺漏一些必要的需求。人們往往傾向于關注系統(tǒng)的特色功能，而忽視了其它一些不起眼的但卻是必需的功能。不完備的《產品需求規(guī)格說明書》將導致產生功能不完整的軟件，用戶在使用該軟件時可能無法完成預期的任務。.什么是好的需求規(guī)格說明書7可實現(xiàn)

《產品需求規(guī)格說明書》中的各項需求對開發(fā)方而言應當都是可實現(xiàn)的（Attainable）。“可實現(xiàn)”意味著在技術上是可行的，并且滿足時間、費用、質量等約束。營銷人員和用戶談生意時，為了能拿到“單子”，他們往往對用戶提出的需求“來者不拒”。吹牛皮雖然不犯法，但是《產品需求規(guī)格說明書》可是白紙黑字啊。經過雙方確認的《產品需求規(guī)格說明書》相當于商業(yè)合同，如果開發(fā)方不能夠實現(xiàn)《產品需求規(guī)格說明書》中的內容，那就是違約，可能會被罰款的。對于合同項目，如果開發(fā)方不能確信某些需求是否可實現(xiàn)，則應事先與用戶協(xié)商，達成一致的處理意見，避免將來發(fā)生商業(yè)糾紛。.8可驗證

《產品需求規(guī)格說明書》中的各項需求對用戶方而言應當都是可驗證的（Verifiable）。如果需求是不可驗證的，那么用戶就無法驗收軟件，可能會發(fā)生商業(yè)糾紛。例如，摩天大樓的一項需求是“抗十二級臺風”，這個需求看起來堂而皇之，但是如何驗證呢？當摩天大樓完工后驗收時，用戶又不是巫師，他怎能造個十二級臺風來試驗？如果雙方都認可“采用計算機模擬十二級臺風”等效于實際測試，那么這項需求就是“可驗證”的。.什么是好的需求規(guī)格說明書.9確定優(yōu)先級為什么要確定需求的“優(yōu)先級”？理論上講，軟件的所有需求都應當被實現(xiàn)。但是在現(xiàn)實之中，項目存在“進度、費用、人力資源”等限制。在項目剛開始的時候，開發(fā)方和客戶比較樂觀，什么都要做，可是做著做著，人們常常會面臨“進度延誤、費用超支、人員不足”等問題，這時就亂套了。人們想出了“取舍”辦法：先做優(yōu)先級高的需求，后做（甚至放棄）優(yōu)先級低的需求，這樣可以將風險降到最低。需求的優(yōu)先級其實就是需求“輕重緩急”的分級表述，例如劃分為“高、中、低”三級。一般地，由用戶和開發(fā)方共同確定需求的優(yōu)先級。10闡述“做什么”而不是“怎么做”《產品需求規(guī)格說明書》的重點是闡述“做什么”，而不是闡述“怎么做”?！霸趺醋觥笔窍到y(tǒng)設計和實現(xiàn)階段的事情。國內的很多軟件公司里，開發(fā)人員常常身兼數(shù)職，可能把需求開發(fā)、系統(tǒng)設計、編程等工作從頭做到尾。所以他們在調查、分析、定義需求時，自然會想到“怎么做”，這并沒有什么過錯。如果在調查、定義需求時想好了“怎么做”，當然應該寫下來，否則豈不浪費！關鍵是不要將“怎么做”寫到需求規(guī)格說明書里面，記錄在其它文檔里就行了。良好的需求規(guī)格說明的例子-1例子：“產品應在不少于每60秒的正常周期內提供狀態(tài)信息”分析：這個需求是不完整的：狀態(tài)信息是什么，如何顯示給用戶。這個需求有幾處含糊。我們在談論產品的哪部分？狀態(tài)信息間隔真的假定為不少于60秒？，甚者每10年顯示一條新的狀態(tài)信息也可以？也許它的意圖是消息間隔不應超過60秒，那么1毫秒是不是太短？“每”這個詞導致了不確定性。問題的后果，就是需求的不可證實。彌補缺陷，重寫需求的一種方法：n后臺任務管理器因以誤差上下不超過10秒的60秒間隔，在用戶界面的指定位置顯示狀態(tài)信息；n如果后臺進程處理正常，那么應該顯示任務已完成的百分數(shù)/比；n任務完成時，應顯示相關的信息；n后臺任務出錯應該顯示錯誤信息；為了測試和追蹤，將需求分解多個子需求。使在構造和測試時，被易于分別執(zhí)行。良好的需求規(guī)格說明的例子-2例子：“產品應瞬間在文本中的顯示和隱藏不可打印字符間切換”

計算機在瞬間不能做任何事，所以這個需求不切實可行。它的不完整性表現(xiàn)在沒有聲明觸發(fā)狀態(tài)切換的條件。軟件要在某些條件下更改自己？或者用戶為了模仿更改要做一些什么動作？而且，在文檔中改變顯示的范圍是多大：選中的文本？整個的文檔，或其他的？這也是個模糊的問題。不可打印字符和隱藏字符一樣嗎？或者是一些屬性標志或一些控制字符？問題的后果，就是需求的不可證實。像這樣編寫需求也許更好一些：用戶能夠在一個由特定觸發(fā)條件激活處于編輯的文檔中在顯示和隱藏所有HTML標記間切換?，F(xiàn)在就很清楚，不可打印字符是HTML標記。由于沒有定義觸發(fā)條件，需求對設計沒有約束力。只有設計人員選定了觸發(fā)條件后，你才能編寫測試驗證觸發(fā)的正確操作。良好的需求規(guī)格說明的例子-3例子：“HTML分析器可以產生HTML標記錯誤報告，幫助HTML入門者快速解決錯誤”。單詞“快速”使其模糊，沒有加進錯誤報告的定義也是不完整的。我不知道，你怎么驗證這個需求。找一個自稱為HTML的入門者，看看能不能根據(jù)錯誤報告快速解決錯誤？試試這個：“HTML分析器可以產生一個錯誤報告，錯誤報告包含有在被分析文件中出錯的HTML文本和行號以及錯誤的描述。如果沒有錯誤，就不會產生錯誤報告”?，F(xiàn)在我們知道了，什么會被加到出錯報告中，但是出錯報告是個什么樣子，則留由設計人員決定。我們還指定了一個例外：如果沒有發(fā)現(xiàn)錯誤，不產生錯誤報告。需求跟蹤1.需求的標識<需求類型><需求#>需求類型可以是：F=功能需求，D=數(shù)據(jù)需求，B=行為需求，I=接口需求；O=輸出需求。

例：需求標識為F03的需求表示編號為3的功能需求。2021/3/1138需求跟蹤2.需求的屬性創(chuàng)建需求的時間需求的版本號創(chuàng)建需求的作者負責認可該需求的人員需求狀態(tài)需求的原因或根據(jù)（或信息的出處）需求涉及的子系統(tǒng)需求涉及的產品版本號……2021/3/1139需求跟蹤3.需求狀態(tài)

已建議——該需求已被有權提出需求的人建議

已批準——該需求已被分析，估計了其對項目余下部分的影響（包括成本和對項目其余部分的干擾），已有一個確定的產品版本號或編號，軟件開發(fā)團隊已同意實現(xiàn)該項需求

已實現(xiàn)——使用所選擇的方法已驗證了實現(xiàn)的需求，例如測試和檢測，審查該需求跟蹤與測試用例相符。該需求現(xiàn)在被認為完成

已刪除——計劃的需求已被刪除，并包含一個原因說明和作出刪除決定的人員2021/3/11404.3.2需求狀態(tài)的變化在需求獲取、分析、處理、驗證階段，我們已經得到了獲得用戶和項目組達成共識的需求，并且，已經建立了需求數(shù)據(jù)庫，建立了需求基線。從需求實現(xiàn)階段來看，需求在這個階段，仍然受各種因素的影響，產生不可預料的變化。狀態(tài)定義被建議根據(jù)需求來源，責任、相關人提出了需求。被拒絕在一系列需求開發(fā)過程后，該需求沒有被認可。被批準在需求（特別是變更需求）被分析，評估了合理、可行、成本、影響等要素，被確認可接受，被標注了新的版本號、給出了新的標號等需求屬性、被加入到需求基線庫中，進入實現(xiàn)過程。被實現(xiàn)已實現(xiàn)設計、編碼、單元測試。被驗證根據(jù)驗收標準，已經通過集成以上的測試，被驗證實現(xiàn)了需求的要求，被放置進配置基線庫。表明需求已經被實現(xiàn)。被丟棄被批準的需求已從基線庫中被丟棄。記錄下丟棄的原因和決定責任人。被交付通過用戶的驗收測試，需求以交付物的形式，向用戶提交。2021/3/1141需求實現(xiàn)過程——需求狀態(tài)變化在需求狀態(tài)的變化中，軟件項目經理第一位需要關注的是那些被拒絕、被丟棄的需求。因為如果不是通過有管理的處理過程，這些需求有可能是應該被接受、并被實現(xiàn)的需求，而成為系統(tǒng)的疏忽而遺漏？項目經理也應該關注被交付的需求，因為作為項目經理，他的主要責任是項目階段的里程碑控制。項目階段里程碑是應交付成果，交付成果最主要的內容，就是需求的實現(xiàn)。（其他的交付物還有：文檔、培訓、服務等）。2021/3/11424.3.3需求狀態(tài)變化的追蹤如果我們能夠做到軟件需求的定義，那么，通過跟蹤定義了的需求，我們就能夠知道需求在實現(xiàn)過程中的具體實現(xiàn)細節(jié)與目標的距離。在可追蹤的需求實現(xiàn)過程中，項目經理才能夠有把握地說，需求被正確地實現(xiàn)了。2021/3/1143需求跟蹤正向跟蹤：以用戶需求為切入點，檢查《用戶需求說明書》或《需求規(guī)格說明書》中的每個需求是否都能在后繼工作產品中找到對應點。逆向跟蹤：檢查設計文檔、代碼、測試用例等工作產品是否都能在《需求規(guī)格說明書》中找到出處。正向跟蹤和逆向跟蹤合稱為“雙向跟蹤”。2021/3/1144需求跟蹤

正向跟蹤和逆向跟蹤合稱為“雙向跟蹤”。不論采用何種跟蹤方式，都要建立與維護需求跟蹤矩陣（即表格）。需求跟蹤矩陣保存了需求與后繼工作成果的對應關系。

2021/3/1145需求發(fā)生變更的起因主要有：隨著項目的進展，人們（包括開發(fā)方和客戶方）對需求的了解越來越深入。原先的需求文檔可能存在這樣那樣的錯誤或不足，因此要變更需求。市場發(fā)生了變化，原先的需求文檔可能跟不上當前的市場需求，因此要變更需求。提出需求變更的動機是好的，目的是希望產品更加符合用戶的需求。對項目開發(fā)小組而言，變更需求意味著要調整資源、重新分配任務、修改前期工作成果等，開發(fā)小組要為此付出較重的代價。如果每次需求變更請求都被采納的話，這個項目也許永遠不能按時完成。需求變更控制的目的：如果需求變更帶來的好處大于壞處，那么允許變更，但必須按照已定義的變更規(guī)程執(zhí)行，以免變更失去控制。如果需求變更帶來的壞處大于好處，那么拒絕變更。需求變更控制過程中最難辦的事情是莫過于“拒絕客戶提出的需求變更請求”。通常情況下開發(fā)方是不敢得罪客戶的，但是無原則地退讓將使開發(fā)小組陷入困境。解決這個問題最好的辦法是事先建立“游戲規(guī)則”：開發(fā)方與客戶方達成“事不過三”的約定（符合中國人的習慣），即允許客戶變更三次需求；如果客戶第四此變更需求，開發(fā)方有權拒絕，除非客戶愿意補償開發(fā)方的損失。如果事先沒有“游戲規(guī)則”的話，開發(fā)方需要一些社交技巧來減緩矛盾。例如建議在開發(fā)該產品新版本時修改需求。需求變更控制4.4.1需求變更管理的重要性需求變更的原因多種多樣，但管理變更，應確立以下原則：（1）認識到變更是不可避免的，為變更指定計劃；（2）確定需求基線；（3）建立控制變更的唯一渠道（4）使用變更控制系統(tǒng)來控制變更過程；（5）分層次地管理變更。2021/3/11474.4.2需求變更控制活動6大需求變更控制活動

（1）確定需求變更控制過程：確定需求變更的選擇、分析、決策、記錄的過程，所有需求的變更，都要在選擇、分析、決策、記錄環(huán)節(jié)上，受到機制和責任的保證。（2）建立需求變更控制委員會：組織公司、項目組內部和用戶利益和風險承擔人員，成立需求變更控制委員會，由他們來決定要變更哪些需求，是否在項目范圍之內（包括：項目范圍和合同范圍。因為有時，在項目范圍，但不在合同范圍，需要項目進行二期合同開發(fā)），評估變更的波及，最后決定變更是可以接受，還是放棄。對變更的需求設置優(yōu)先級、制定版本規(guī)定等。

2021/3/1148需求變更——6大需求變更控制活動（3）進行需求變更影響分析：波及分析有利于對需求變更要求，進行更深入、精確的理解，幫助變更控制委員會做出科學的決策。波及分析還可以幫助項目組對現(xiàn)有系統(tǒng)做出合理的、有前瞻性的調整，使面對日后新的需求變更，有充足的技術準備。波及分析完全依賴于需求的跟蹤能力。沒有需求形式化記錄、沒有需求跟蹤鏈，就沒有波及分析的可能。如果有，也是主觀的、非定量的。由此對項目計劃、成本、質量控制的影響分析，其可信度是有疑問的。系統(tǒng)分析師和架構師應評估變更對系統(tǒng)技術實現(xiàn)的影響。項目經理應根據(jù)新需求，明確相關任務，評估新的工作量和相應的要求變化。新需求不但導致分析、編碼、測試的工作量增加，項目管理有關的各環(huán)節(jié)（需求管理、計劃管理、成本管理、配置管理、質量管理等）都會有所變化。在需求變更評估分析中，也要做需求穩(wěn)定性評估。頻繁地需求變更，應該超出了需求變化的范圍。項目經理要考慮項目組織管理方面，是不是發(fā)生了什么問題。

2021/3/1149需求變更——6大需求變更控制活動（4）跟蹤所有受需求變更影響的工作產品：當確定某一需求發(fā)生變更時，根據(jù)需求跟蹤矩陣，找到與變更需求有關的各層、各環(huán)節(jié)需求項。例如：涉及需求項的設計模型、代碼模塊、測試用例等。這些部分全部必須做相應的修改。依據(jù)需求跟蹤矩陣，可以完整地追蹤到需求變更所影響到的所有地方，可以不會發(fā)生遺漏，而產生系統(tǒng)BUG，或產品缺陷。甚至包括對軟件產品本身以外的影響，如：因需求變更，版本控制沒有相應的記錄、產品使用手冊沒有做相應修改等。因為需求變更，需求狀態(tài)記錄應相應地發(fā)生變化。每一條記錄，反映了需求的現(xiàn)實情況。

（5）調整需求基線：需求變化以后，需求變更控制委員會要決定是否調整需求基線。新需求是反映為基線的調整，還是版本的變化?；€是產品的標準，基線變化可以作為產品標準的變化，也可以理解為將發(fā)行一個新版本的產品。2021/3/1150需求變更——6大需求變更控制活動但是，版本并不一定就是新產品。因為，當產品面對不同地區(qū)、不同用戶群的時候，也可以確定不同的版本。因此，需求變更控制委員會要做的工作，是對新需求，決定是全面升版，還是局部更改。是基線變化，還是個別版本變化。有時，這是一個比較難于做出的決定，他依賴于對新需求的分析，評估它對市場、用戶和產品本身的影響。

（6）維護需求變更記錄和文檔：決定變更基線或提升版本以后，就要做好記錄，修改相應的文檔。變更記錄要記錄變更原因、變更內容、變更影響、變更實現(xiàn)過程、其他相應變更等。變更記錄越完整，對于追溯，甚至以后可能發(fā)生的回退，就越有幫助。有一些版本控制工具，可以幫助項目經理來做到記錄相應的信息。2021/3/11514.4.3需求變更波及分析變更波及分析的意義對于項目組來說，一個新的需求提出來以后，這個需求如果接受，可能對系統(tǒng)造成多大的影響？系統(tǒng)結構上的、數(shù)據(jù)結構上的、涉及的模塊、版本上的變更影響有多大？需求波動在技術上有潛伏性，在工程上，也表現(xiàn)為不可預知性。工作量不可預知、成本不可預知。項目經理往往受市場人員的壓力，對用戶宣稱“免費維護”，但在項目組內部，對于需求變更的成本，甚至可能是“巨大”的。這種不理智的“反差”，正好說明了我們軟件項目管理的水平，是處在原始和粗放的狀態(tài)。需求波及分析是軟件項目管理的需求管理比較重要的組成部分，在需求變更決策前，通過波及分析，可以達到精確理解需求、評估系統(tǒng)對需求變更要求的接納程度、變更的代價、變更對系統(tǒng)總體架構、甚至產品發(fā)展的影響等。這樣的分析，對需求變更委員會做出變更批準還是放棄的決策，具有重要的意義。一旦變更控制委員會批準需求變更的要求，就能比較清晰地知道相應變更的內容、工作范圍、需要的時間等。需求變更波及分析也是保證項目組在需求變更以后，可以做到“在計劃、成本、質量（不是降低質量標準為代價）范圍的變更”。2021/3/1152需求變更——變更波及的內部分析系統(tǒng)元素波及分析包括：（1）

所有涉及到的輸入界面有關部分；（2）

所有涉及到的報表等輸出界面有關部分；（3）

所有涉及到的外部接口部分；（4）

所有涉及到的內部接口部分；（5）

所有涉及到的數(shù)據(jù)庫表結構；（6）

所有涉及到的系統(tǒng)數(shù)據(jù)定義；（7）

所有涉及到的公用模塊定義、公用子程序庫、控件庫；（8）

所有涉及到的系統(tǒng)常量、宏定義；（9）

所有涉及到的已經實現(xiàn)的代碼；（10）

所有涉