先前從IBM Rhapsody文件中提到的6種系統分析方法，我認為需要相輔相成才行。因為實做系統的時候，除了要符合產品需求，還需要考慮到軟體的reuse，並且也要知道哪些team的專業與分工以及未來類似系統的快速開發。因此無法用這6種中的其中一種來完全描述系統的面貌。

最後一個簡單的系統分析，就是將系統大略分解，並且將每一部份分派給不同負責人。而負責人之間並沒有共用之處(也許有共用但忽略)。我覺得這個方法只適合用在單晶片的系統上...

系統分析可以從元件開始，所謂元件可看作是執行的時候，需要用到的library、執行檔。這個方法主要是定義出容易使用的元件，在元件層可以達到有效率的reuse。但這需要架構在已具備reuse的邏輯設計層之上。否則會造成雖然元件共用，但是程式卻要重寫。

系統分析可以從領域著手。ROPES："A doman is a subject area with a common vocabulary"。一個系統可以被分解成不同領域的團隊來實做。像是driver的團隊、影像壓縮的團隊或是設計硬體的團隊。這有助於技術傳承、技術密集。

系統分析可以從邏輯架構與實體架構著手。邏輯架構指的是設計階段所考慮到的元素，比如該實做出什麼樣的class、行為、狀態。實體架構指的是執行時期會有哪些運作的子系統、物件。這種方式通常是為了分派工作給不同領域、子系統、元件的team時使用。

系統分析可以從frame work開始，android就是用這種方式去設計。google設計出android，並不專注於某種特定功能。相對於use case，這種方式較能設計出能夠re use的系統。

系統分析可從use case開始，向中醫一樣的"望聞問切"來找尋可能的use case。可以利用activity diagram、state chart來幫助你，但別掉進細節的漩渦，因為重點只是找出use case，而非說明細節。

正要去看藍人組喔！！聽說很好看。

有一些RD會覺得自己已經把系統設計出來，而且實做出雛形了。就認為自己的責任已經完成，不想要繼續後面的除錯。又有一些RD認為他不需要去理會生產的問題。但我覺得這些經歷都是需要去學習的，而不是排斥。

很多人都不知道什麼叫做critical section就開始寫多工的程式。有的人甚至知道critical section，卻只會用flag+sleep的方式來做。這樣不求甚解的解法會招致系統的不穩定與效能低落。