最近看了「Mastering.the.Requirements.Process.2nd.Edition」，感觸頗深，也花了很多的時間寫了講義，對於SA在系統分析前，PM跟RA(需求分析師)要做的活動，完全清楚明瞭了。
感觸深的是，國內的IT專案，常常都未將『需求』這件事正確看待，我們每每將系統分析與需求分析這兩件事混雜一起而不自知。
看看邵維忠在「面向對象的系統設計」的描述：
用”做什麼”和”怎麼做”來區分分析和設計，是從結構化方法沿襲過來的一種觀點。但即使在結構化方法中這種說法也很勉強......
在”做什麼”和”怎麼做”的問題上為什麼會出現這種矛盾？
究其根源，在於人們對軟件工程中”分析”這個術語的含義有著不同的理解──有時它把需求分析(Requirements Analysis)的簡稱，有時是指系統分析(Systems Analysis)，有時則作為系統分析和需求分析的總稱。
需求分析是軟件工程學中的經典術語之一，名副其實的含義應是對用戶需求進行分析，旨在產生一份明確、規範的需求定義。從這個意義上講”分析是解決做什麼而不是解決怎麼做的問題”實無可挑剔的。
但迄今為止人們所提出的各種分析方法(包括結構化分析和面向對象分析)中，真正屬於需求分析的內容所佔的分量並不太大；更多的內容是給出一種系統建模方法(包括一種表示法和相應的建模過程指導)，告訴分析員如何建立一個能夠滿足(由需求定義所描述的)用戶需求的模型。
分析員大量的工作是對系統的應用領域進行調查和研究，並抽象地表示這個系統。
確切地講，這些工作應該叫做系統分析，而不是需求分析。
它既是對”做什麼”問題的進一步明確，也在相當程度上涉及到”怎麼做”的問題。
忽略分析、需求分析和系統分析這些術語的不同含義，並在討論中將它們隨意替換，是造成上述矛盾的根源。
好啦，回到『需求』這件事上，談到掌握、收集、驗證需求，通常有經驗的RA與經驗不足的RA談出來的可是差了十萬八千里，應該是有個process可依循，才不會讓這樣的落差過大。
所以我們需要【掌握需求過程】，當然就是要看這本「Mastering.the.Requirements.Process.2nd.Edition」，這本是Weinberg也寫序推薦的。
內容包含了：
Chapter 1. What Are Requirements?
Chapter 2. The Requirements Process
Chapter 3. Project Blastoff
Chapter 4. Event-Driven Use Cases
Chapter 5. Trawling for Requirements
Chapter 6. Scenarios and Requirements
Chapter 7. Functional Requirements
Chapter 8. Nonfunctional Requirements
Chapter 9. Fit Criteria
Chapter 10. Writing the Requirements
Chapter 11. The Quality Gateway
Chapter 12. Prototyping the Requirements
Chapter 13. Reusing Requirements
Chapter 14. Reviewing the Specification
Chapter 15. Whither Requirements?
從解釋需求到專案啟動前應準備之工作，馬上讓人收穫不少，中間的幾個章節其實跟 Use Case Modeling有異曲同工之妙，教你如何寫出正確的需求應有的內容。
書中也強調『需求的本質』，唔，有了正確的需求才會有正確的解決方案，要找出正確的需求，怎能不清楚『需求的本質』呢？
裡面也教了很多技巧，書最後的附錄更有清楚的詳細步驟，在每個步驟該考量的想法都有寫。
嗯，不愧擁有Amazon 4顆半星的評價。
不能不提的是Weinberg 的「Exploring Requirements: Quality Before Design」，中譯本是「從需求到設計：如何設計出客戶想要的產品」(簡體中文版翻得比較貼切：「探索需求：設計前的質量」)，這本是1989年的書 了，只是繁中文版今年才出。
這本講的是觀念，也偏向找出『需求的本質』，如同書名，這本書實際是一種探索(Exploring)，比較偏向的是人性面的。
裡面可也有一堆名言咧：
引用馮紐曼的名言：「如果你不了解自己所說的事物，即使你遣詞用字精確，也毫無意義。」
「文件不重要，重要的是建立文件這件事。」
也是非常好的一本書，兩本都強力推薦啦！！
感觸深的是，國內的IT專案，常常都未將『需求』這件事正確看待，我們每每將系統分析與需求分析這兩件事混雜一起而不自知。
看看邵維忠在「面向對象的系統設計」的描述：
用”做什麼”和”怎麼做”來區分分析和設計，是從結構化方法沿襲過來的一種觀點。但即使在結構化方法中這種說法也很勉強......
在”做什麼”和”怎麼做”的問題上為什麼會出現這種矛盾？
究其根源，在於人們對軟件工程中”分析”這個術語的含義有著不同的理解──有時它把需求分析(Requirements Analysis)的簡稱，有時是指系統分析(Systems Analysis)，有時則作為系統分析和需求分析的總稱。
需求分析是軟件工程學中的經典術語之一，名副其實的含義應是對用戶需求進行分析，旨在產生一份明確、規範的需求定義。從這個意義上講”分析是解決做什麼而不是解決怎麼做的問題”實無可挑剔的。
但迄今為止人們所提出的各種分析方法(包括結構化分析和面向對象分析)中，真正屬於需求分析的內容所佔的分量並不太大；更多的內容是給出一種系統建模方法(包括一種表示法和相應的建模過程指導)，告訴分析員如何建立一個能夠滿足(由需求定義所描述的)用戶需求的模型。
分析員大量的工作是對系統的應用領域進行調查和研究，並抽象地表示這個系統。
確切地講，這些工作應該叫做系統分析，而不是需求分析。
它既是對”做什麼”問題的進一步明確，也在相當程度上涉及到”怎麼做”的問題。
忽略分析、需求分析和系統分析這些術語的不同含義，並在討論中將它們隨意替換，是造成上述矛盾的根源。
好啦，回到『需求』這件事上，談到掌握、收集、驗證需求，通常有經驗的RA與經驗不足的RA談出來的可是差了十萬八千里，應該是有個process可依循，才不會讓這樣的落差過大。所以我們需要【掌握需求過程】，當然就是要看這本「Mastering.the.Requirements.Process.2nd.Edition」，這本是Weinberg也寫序推薦的。
內容包含了：
Chapter 1. What Are Requirements?
Chapter 2. The Requirements Process
Chapter 3. Project Blastoff
Chapter 4. Event-Driven Use Cases
Chapter 5. Trawling for Requirements
Chapter 6. Scenarios and Requirements
Chapter 7. Functional Requirements
Chapter 8. Nonfunctional Requirements
Chapter 9. Fit Criteria
Chapter 10. Writing the Requirements
Chapter 11. The Quality Gateway
Chapter 12. Prototyping the Requirements
Chapter 13. Reusing Requirements
Chapter 14. Reviewing the Specification
Chapter 15. Whither Requirements?
從解釋需求到專案啟動前應準備之工作，馬上讓人收穫不少，中間的幾個章節其實跟 Use Case Modeling有異曲同工之妙，教你如何寫出正確的需求應有的內容。
書中也強調『需求的本質』，唔，有了正確的需求才會有正確的解決方案，要找出正確的需求，怎能不清楚『需求的本質』呢？
裡面也教了很多技巧，書最後的附錄更有清楚的詳細步驟，在每個步驟該考量的想法都有寫。
嗯，不愧擁有Amazon 4顆半星的評價。
不能不提的是Weinberg 的「Exploring Requirements: Quality Before Design」，中譯本是「從需求到設計：如何設計出客戶想要的產品」(簡體中文版翻得比較貼切：「探索需求：設計前的質量」)，這本是1989年的書 了，只是繁中文版今年才出。這本講的是觀念，也偏向找出『需求的本質』，如同書名，這本書實際是一種探索(Exploring)，比較偏向的是人性面的。
裡面可也有一堆名言咧：
引用馮紐曼的名言：「如果你不了解自己所說的事物，即使你遣詞用字精確，也毫無意義。」
「文件不重要，重要的是建立文件這件事。」
也是非常好的一本書，兩本都強力推薦啦！！
留言