軟體系統是收集使用者需求建構而成的嗎？
2004/07/06| 閱覽人次：8,476| 7 則留言
軟體公司的 PM(Project Manager)一向重視的是如何在不合理的開發時程下完成專案的開發。許多 PM 也認為他們認同物件導向及如 RUP/XP 的開發流程模式，認為如此他們可以縮短開發的時程。
個人最常與 PM 們討論的一個話題是：軟體應用系統是否係由使用者的需求收集而來所建構而成的？
絕大部分的 PM 的回答是：Yes！
為何問這個問題？個人發現到 PM 一定會先請 SA 訪談客戶的需求，並記錄在 Use Case 敘述內。再由 SD 針對 Use Case 敘述來找出領域物件(Domain Objects)。
在這樣的開發流程下，顯然使用者需求(Use Requirements)是重於軟體結構(Classes)的。所以，Use Case 是目的；Classes 是手段。
有沒有道理？在某種觀點及假設下，可能有道理！
只是，讓我們回想 RUP 所建議的最佳實務作法：”Use Case Driven；Architecture Centric”。
那麼，PM 既然認同 RUP 的開發模式，但是是否有仔細分辨倒底系統開發的方式是 “Use Case Driven” 或者是 “Use Case First” 呢？
有趣的問題，留待各位一起討論！
mort
以”Use Case Driven；Architecture Centric”這句話來分析。
是不是有一些既定的Architectures是良好的設計，是general的
在不同的user requirement下，選擇一個適當的Architectures
以此為基礎開發軟體。
簡而言之 就是在user requirements(變化的)和Architectures(不便的)之間作一個mapping
Kenming Wang
不妨如此說，「使用者需求」是用來”驗證”系統的完整性。
骨架，即系統的內部結構設計，結構設計需考量到許多的構面。您所問的 “如何被建立？”，可能要先反思，擔任結構設計的 “Architect” 應具備那些素養？
軟體產業，目前還屬於非常不成熟的階段期，目前絕大部分的專案，均一味地從需求功能面來建構系統，完全沒有重視系統內部的結構設計。
現今系統是越來越複雜，脆弱的架構是很容易瓦解的。
如何被重視呢？當人們記取諸多教訓之後，自然而然，也就懂得如何從中學習得以成長了。
zobeide wu
“這有一個極大的風險，系統的 “骨架” 沒有被重視到”
是沒錯…
所以你的會建議怎麼樣讓系統骨幹被重視,
以及建立起來… 系統骨幹跟使用者需求又有什麼關係….
Kenming Wang
Hi zobeide:
Use Case 是手段；UI Prototyping 也是手段；甚至 OO、RUP 等都是手段。
若是能達成 “正確而迅速地捕捉使用者需求”，其實，沒有必要強求使用哪一種手段。
有一點您說得很有道理，SA 不只是錄音機，記錄下使用者的需求而已。再則，是否有訪談到真正的 “Domain 專家”，懂得如何與專家溝通，以得到重要的需求線索，這才是重點。
之前寫這一篇文章的主要用意，是提醒軟體設計人員不要以為只是收集使用者的需求(需求均偏向功能性的)，然後再據此就可以完成系統的開發。
因為，這有一個極大的風險，系統的 “骨架” 沒有被重視到，相對地，系統的架構會變得很脆弱：因為建基在使用者的需求上，而需求又是善變的。
zobeide wu
記得早期學OO時, 學得很多技巧是在從User身邊的各種資料, 線索,
蒐集整理出Domain Knowledge.
再收集整理時 OO就已經扮演很重要的角色. 哪時覺得OO很棒
後來上課老師教Use Case, 也覺得蠻好用的,
工作上自己在用, 也還順手.
某個工作後, 用RUP, 用Use Driven, 正式的開發軟體專案,
工作同伴只學過Use Case Driven.
不知道是不是因為不習慣,
總覺得這種 Use Case Driven (Limited) 的Requirement Gathering 所
找出的需求, 品質不好(不是真正的需求,易變動, context information 太少, OOA 很難做, 訪談次數變多,…), 到最後大家還是喜歡用UI prototyping.
品質不好當然有很多原因, SA 對Use Case 不夠熟 (如不了解Goal對Use Case的重要), User不是對Domain不了解就是沒時間認真思考所要的系統.
只是這些都是客觀的現實.
User 不用功的情況下 SA就應該多用功, 不是當書記官一樣紀錄下需求後丟給SD.
早期的OO的書都很強調Domain Expert的重要,現在好像都很少在被強調…
🙁
“在這樣的開發流程下，顯然使用者需求(Use Requirements)是重於軟體結構(Classes)的。” 我有近似的感覺. 我的感覺是這樣收集到的軟體需求不足以供設計好的軟體架構.
Kenming Wang
您已經提到了重點：有前提及其假設環境。
所以相對地，蓋茅草屋、四合院的技術與蓋高樓大廈所使用的技術與人才就會不盡相同。
反映至軟體系統的開發，也是類似的情形。 🙂
BinzyWu
我认为还是要具体情况分析的。比如你是外包，那就不可能不use case first