發表者

討論內容

冷日
(冷日)

發表時間：2008/3/18 5:58

Webmaster

註冊日: 2008/2/19
來自:
發表數: 15771

[轉貼]爪哇教室 >> 需求工程有那麼重要嗎？ (趙曉楓)

爪哇教室 >> 需求工程有那麼重要嗎？ (趙曉楓)

趙曉楓　Facade.zhao@msa.hinet.net

■ 引言
==============================
『根據Core J2EE Patterns 2nd Edition一書所提到Session Facade Pattern這是解決……』某個IT研討會台上的Speaker正滔滔不絕談論軟體設計模式方面的議題，身為Audience的筆者，聽到『Facade』總會以為Speaker叫筆者起來回答問題，為了避免這種提心吊膽的事情再度發生，筆者決定將自己詩意般的名字公諸於世【與薔薇之戀一劇沒什麼關係，筆者不喜歡葵】，而筆者當初會取『Facade』這個筆名，就是希望本身的生活步調不希望給外界打擾【我想取筆名的作者，一部分的理由應該都是這個】，或是藉此以緩衝一些沒有意義的爭辯與干擾，從上面讀者應該可以發現，『緩衝一些不必要的爭辯與干擾』是筆者的需求，而取筆名為『Facade』為筆者解決問題的方式，而軟體開發對於需求方面也有一定的作法。

■ 夢魘不斷延續
==============================
Maria：『喂！請問是Phil？我是人力資源部的Maria，我有一個是你之前幫我們做的員工系統的問題，有一名員工想要改她的名字為Sparkle Starlight，我們無法讓這個系統接受這個變更，你能幫忙一下嗎？』

Phil：『她是不是嫁人了，所以要改成Starlight？』

Maria：『不，她還沒嫁人，只是想改她的名字而已，那就是問題的關鍵，這套系統看起來，只有在婚姻狀態變更時，才能改她的名字』

Phil：『嗯，那就沒錯了，我從未想過某人會變更他的姓名，而且我也不記得你有告訴我這個系統需求有這個可能性，那就是為什麼你想要變更姓名，必須在婚姻狀態有變更才能變動』

Maria：『我是假設你已經知道如果員工走正常程序就能在任何時間變更他的名字』

Maria：『我們必須在這個星期五之前將這個問題修正，不然Sparkle將無法拿到她的薪資，你能不能將這個系統的Bug修正』

Phil：『這不是Bug！我從未知道你需要這個功能，我最近忙著測試一套系統的效能，我記得也有一些需求變更關於這討員工系統，在這個月底我會盡可能的這些問題修正，但這禮拜我做不到，不好意思，下次將這些問題早一點告知，並將它寫下來』

Maria：『那我該怎麼跟Sparkle說？如果她沒拿到薪資，她會罵人的』

Phil：『嘿！Maria這不是我的錯，如果你能再這個問題發生的第一時間告訴我，這個事情就不會發生，你不必把責任歸咎於我不了解你的需求』

抓狂的Maria：『這就是我為什麼會討厭電腦系統，當你解決完時，馬上跟我聯絡，可以嗎？』

此文是取自Software Requirements國外一書之中，但這種場景，對話是否曾出現在您的週遭。

如果您是客戶或主管，是否常常認為好的軟體外包商或是好的系統工程師難找，錢花了那麼多，做出來的東西常常不是自己要的。

如果您是系統工程師，是否常常感嘆客戶或主管在談需求時，總是說的模模糊糊，範圍似乎很大，不知該如何下手。

夢魘持續不斷，不去解決它也許十年後問題還是普遍存在，這個業障源於需求，而在軟體開發週期中，需求工程(Requirement Engineering)就是解決這方面的問題。

■ 需求工程
==============================
從CMMI角度來看Requirement Engineering，可用需求管理(Requirement Management)、需求發展(Requirement Development)兩個流程領域來架構出，筆者列出這兩個流程領域SG及SP。

流程領域(Process Area)	需求管理(Requirement Management)
SG1	管理需求
SP1.1	了解需求
SP1.2	取得需求承諾
SP1.3	管理需求變更
SP1.4	維護需求的雙向追溯性
SP1.5	界定專案工作與需求間的差異

表：需求管理的SG及SP

流程領域(Process Area)	需求發展(Requirement Development)
SG1	發展客戶需求
SP1.1	蒐集關鍵人員需求
SP1.2	誘導需求
SP1.3	發展客戶需求
SG2	發展產品需求
SP2.1	建立產品與產品元件的需求
SP2.2	配置產品元件的需求
SP2.3	界定介面需求
SG3	分析與確認需求
SP3.1	建立操作概念及劇本
SP3.2	建立必要功能的定義
SP3.3	分析需求
SP3.4	分析需求以取得平衡
SP3.5	使用綜合的方法驗證需求

表：需求發展的SG及SP
其實從上面可以得知需求管理這個流程領域是軟體專案上與客戶建立及維護對於需求的協議，而需求發展流程領域可以進一步將流程領域活動切割成誘導(Elicitation)，分析(Analysis)，規格(Specification)，驗證(Validation)，【如果讀者對CMMI有興趣的話，可到http://www.sei.cmu.edu/cmmi/translations/trad-chinese/models/下載相關資料，資策會翻的很讚！】如果還不清楚，筆者嘗試用下圖來解說

圖：需求管理與需求發展的關係圖
圈圈和方塊代表活動或流程，箭號方向代表有資料流動的方向，虛線是代表需求發展與需求管理區域的分界，首先先看需求發展這個區域，客戶、市場、公司的管理高層與專案的需求工程師或相關人員透過開會，分析，寫文件，溝通活動將需求確認下來，建立基準，而需求管理這個區域，在了解需求之後，必須維護(Maintain)與客戶，市場，管理高層之間協議，所以一旦有需求變更，比須執行需求變更流程。

■ 需求工程該如何做？
==============================
筆者在此推薦Karl E. Wiegers所寫的一本Software Requirements 2ndEdition，Karl E.Wiegers是一位軟體流程改進的顧問，作者及演說家，他曾經以Creating a Software Engineering Culture(Dorset House , 1996)及Software Requirements 1st Edition (Microsoft Press,1999)兩本書獲得Software Development雜誌所頒予的Productivity Award，除此之外，他也喜歡研究軍事歷史，化學，烹調，還有與他老婆Chris Zambito一起啜飲美酒，在Software Requirements這本書中提供了許多在開發週期中有用How to管理需求方面的技術，這些技術包含所有使用者、開發者與管理部門的溝通技巧，另外也加入作者在實際參與Requirement Engineering輔導的有趣案例。

圖：Karl E. Wiegers玉照

本書是由 Sun 的競爭商出版，所以筆者去天瓏書局站了三天，才把它看完。:-)
PS：看了Karl E. Wiegers的照片，筆者也想留個鬍子！

回覆

主題一覽的下方

討論串

前一個主題 | 下一個主題 | 頁首 |

| |

發表新主題

軟工藝術 : [轉貼]爪哇教室 >> 需求工程有那麼重要嗎？ (趙曉楓)