【正文】 – 可以毫不夸張地說，國內 90％以上的軟件開發(fā)人員，他們的寫作能力遠不及開發(fā)能力。倘若市場靜如死水，那么開發(fā)商吃了 “ 上一頓 ” 就沒有 “ 下一頓 ” 。 ? 其次，需求分析員應當確定需求調查的方式，例如： – 與用戶交談，向用戶提問題。要特別留意的是不要漏掉典型的用戶。 ” 也許這筆生意就泡湯了。 ? 兩者之間可能并不存在一一影射關系，因為軟件開發(fā)商會根據產品發(fā)展戰(zhàn)略、企業(yè)當前狀況適當地調整產品需求，例如用戶需求可能被分配到軟件的數個版本中。后者技術性比較強，寫出來有學術味，故大多數軟件工程書籍都有論述。 – 追究 “ 是什么 ” 和 “ 為什么 ” 的目的是獲得正確、清楚的需求。 – 世上不存在一個包羅萬象的圖 ——它能完整地描述需求 。 – 如果一個產品可以賣給幾類客戶，但是各類客戶都要求產品按照他們的喜好來開發(fā)。為確保需求是正確的，開發(fā)方和用戶必須對《需求規(guī)格說明書》進行確認。矛盾常常潛伏在需求文檔的上下文中。 為了避免主次顛倒 ， 應當在 《 產品需求規(guī)格說明書 》 中將那些 “ 錦上添花 ”的需求設置為較低的優(yōu)先級 。經過雙方確認的《產品需求規(guī)格說明書》相當于商業(yè)合同，如果開發(fā)方不能夠實現《產品需求規(guī)格說明書》中的內容，那就是違約，可能會被罰款的。 – 人們想出了 “ 取舍 ” 辦法：先做優(yōu)先級高的需求，后做（甚至放棄）優(yōu)先級低的需求，這樣可以將風險降到最低。 Page 29 8. 如何定義產品需求 規(guī)程 ? 第一步：細化并分析用戶需求 – 需求分析員首先對《用戶需求說明書》進行細化，對比較復雜的用戶需求進行建模分析，以幫助軟件開發(fā)人員更好地理解需求。需求確認包含兩個重要工作： “ 需求評審 ” 和 “ 需求承諾 ” 。有時話匣子一打開后關不上，大家越扯越遠，結果評審會議變成了聊天會議。 Page 32 9. 需求管理：確認、跟蹤、變更控制 需求 承諾 ? 需求承諾是指開發(fā)方和客戶方的責任人對通過了正式技術評審的《產品需求規(guī)格說明書》作出承諾，該承諾具有商業(yè)合同的效果。 – 逆向跟蹤。 ? 提出需求變更的動機是好的，目的是希望產品更加符合用戶的需求。 ? 如果事先沒有“游戲規(guī)則”的話，開發(fā)方需要一些社交技巧來減緩矛盾。 如果需求變更帶來的壞處大于好處，那么拒絕變更。需求跟蹤矩陣保存了需求與后繼工作成果的對應關系。 – 甲方簽字 乙方簽字 ? 人們在作出承諾之前務必要認真閱讀文檔 ， 一定要明白簽字意味著什么 。然而當爭議變?yōu)闋幊硶r就壞事了， 爭吵不僅對評審工作沒有好處，而且會無意中傷害同事們的感情。 ? 需求評審涉及的人員可能比較多，有些時候讓這么多人聚在一起花費比較長的時間開會并不容易（例如有些人可能出差在外，有些人可能事務纏身）。如果待開發(fā)的產品分為軟件和硬件兩部分的話，則應當撰寫《軟件需求規(guī)格說明書》和《硬件需求規(guī)格說明書》。 “ 怎么做 ” 是系統(tǒng)設計和實現階段的事情 。 ? 例如 ， 摩天大樓的一項需求是 “ 抗十二級臺風 ” ， 這個需求看起來堂而皇之 ， 但是如何驗證呢 ？ 當摩天大樓完工后驗收時 ， 用戶又不是巫師 ， 他怎能造個十二級臺風來試驗 ？ 如果雙方都認可 “ 采用計算機模擬十二級臺風 ” 等效于實際測試 ， 那么這項需求就是 “ 可驗證 ” 的 。 Page 27 7. 什么是好的需求規(guī)格說明書 可實現 ? 《產品需求規(guī)格說明書》中的各項需求對 開發(fā)方 而言應當都是可實現的（ Attainable）。 ? “ 畫蛇添足 ” 顯然是壞事 ， 會導致開發(fā)人員多干一些吃力不討好的工作 。如果一個人說的話，不同的人可能有不同的理解，那么這句話就有二義性。如果產品很復雜，雙方都不太明白需求，此時最好請開發(fā)人員快速構造軟件的原型，雙方看著軟件原型再分析需求。 Page 24 6. 如何進行需求分析 作出決策 ? 當需求從四面八方收集來后，需求的沖突在所難免。 ? 需求建模就是指用圖形符號來表示 、 刻畫需求 。一個人可以 “ 自問自答 ” 地分析需求，幾個人分析需求則稱為“ 研討 ” 。事實上，很多時候用戶說不清楚需求、會說錯需求或者提出一些無法實現的需求。 – 盡可能避免為用戶添麻煩，但也不能怕給用戶添麻煩而降低需求調查的力度。要注意禮節(jié)，盡可能獲得用戶的好感，并為下次打擾他們埋下伏筆。 – 分析已經存在的同類軟件產品，提取需求。 Page 17 5. 如何開展需求調查 準備調查 ? 首先，需求分析員應當起草需求調查問題表，將調查重點鎖定在該問題表內，否則調查工作將變得漫無邊際。 ? 如果在項目開發(fā)的初始階段，開發(fā)人員和用戶沒有搞清楚需求或者搞錯了需求，到了項目開發(fā)后期才將需求糾正過來，導致產品的部分內容需要重新開發(fā)。 – 古時候，一書生在考試前補習 “ 寫文章 ” ，成天愁眉苦臉。就像作文寫跑題了，寫得再好也白搭。 ? 需求分析員絕不能以用戶說不清楚需求為借口而草率地對待需求開發(fā)工作，否則會連累整個開發(fā)團隊的。 ? 有些用戶真的不知道需求是什么 ， 或者對需求只有朦朧的感覺 ， 他當然說不清楚需求。 – 3. 有權審查需求文檔，并對有爭議的需求作出決策。 出色的需求分析員不僅要有過硬的專業(yè)知識 ， 還要具備較強的交流 、 溝通能力。 Page 11 4. 需求開發(fā)的主要困難與對策 合作關系 ? 如果需求分析員不能與用戶建立良好的合作關系，那么他們在需求開發(fā)過程中會很疲憊。如果可能的話，開發(fā)方最好請既懂軟件又懂應用域知識的行家來幫忙。開發(fā)者發(fā)掘了連用戶自己都沒有意識到的需求，導致用戶跟著新產品跑而不是新產品圍著用戶轉，這叫引導消費。 ? 開發(fā)者對待需求工程的態(tài)度可分 “ 被動型 ” 、 “ 主動型 ” 和 “ 領先型 ” 三種，只有后兩種才有可能開發(fā)出成功的產品。常見的需求分析方法有 “ 問答分析法 ” 和 “ 建模分析法 ” 兩類。否則即使該軟件的功能是完美的，但卻被政府認為是非法的。 Page 6 2. 了解客戶、最終用戶、間接用戶 即使最終用戶不是上帝，也算是 “ 上帝 ” 的 “ 親戚 ” ，同樣怠慢不得?？蛻舨⒉灰蕾囄覀?，而我們卻依賴客戶。 ? 國內軟件業(yè)的痼疾：人們并不清楚究竟該做什么，但卻一直忙碌不停地開發(fā)。需求開發(fā)與需求管理 —— 消除軟件開發(fā)百病之源 林 銳 博士 Page 2 目錄 1. 什么是需求 2. 了解客戶、最終用戶、間接用戶 3. 需求工程基本概念 4. 需求開發(fā)的主要困難與對策 5. 如何開展需求調查 6. 如何進行