需求是什麼，如何來做好需求，在cmmi
模型裡都給予了說明。模型將需求分為兩個部分，乙個是二級的需求管理，另乙個是**的需求開發；之後又看了rup
對需求的描述，它沒有明確對需求管理與開發進行劃分，它的工作流包括了以下幾個部分：問題分析，理解涉眾需要，定義系統，管理專案規模，改進系統定義，管理需求變更。
相對來說，cmmi
從巨集觀上來講需求，定義兩個過程域相關的活動及各個活動的工作產品，指出了在需求工程裡所要關注的東西，但感覺起來，多少有些學院派的氣質。而rup
更多則是考慮實際，從cmmi
中裁剪得出自己的流程，多少有些現實的氣息。這兩者就像理想與現實一樣，理想給了行動的路線與方針，而現實給了行動的依據。不過反過來說，比喻有點不恰當，因為現實不可裁剪，而rup
也有可以裁剪的地方。總的來說，兩者都給出如何解決需求問題的方法與步驟。
在實際的專案中，要想把需求固定下來不是一件容易的事。真正做好需求的，往往意味著成功。從問題收集，分析，到最後的評審通過，經歷了乙個漸近明晰的過程。開發客戶需求、開發使用者需求、分析確認需求，這是需求開發過程域所要求的。每一活動都與其它活動相關，這一點倒是有點rup
的味道。在需求管理過程域裡，既要取得對需求的理解與承諾，還要維護需求的變更。但在實際的專案中沒有太多的界限劃分。乙個朋友這樣說，cmmi
是對所有專案工程的框架進行描述，它給出了這一步應做什麼，下一步應做什麼，不僅僅適用於it
專案，還有其它工程專案。而rup
則是細化了模型的要求，以另一方式表達了乙個專案所應進行的過程。兩者都可以根據實際專案的情況進行裁剪。
最近在研究requisitepro
的過程中，感到它是乙個非常適合於rup
模式的開發，在需求不穩定的情況下對需求進行維護，從最初的需求到最終的**實現、測試用例都可進行追蹤，方便標識變更的需求。
在生命週期模型中，工程活動一直隨著專案的進行。對於瀑布模型，需求基線的確認意味著需求開發的結束，接下來說是對需求進行管理，保證下乙個活動的進行。而對於迭代模型，如何來保證需求的有效性，也即是目前大多數專案的情況，就只能採用動態維護的手段了。可以使用工具或其它方式，對評審通過的需求打上基線，作為下一步設計的基礎。設計人員最煩的是什麼，就是在設計過程中得到需求的變更。因此，在專案開始的時候，就要首先確定專案的範圍，確定專案的範圍並等於確定了需求的範圍，但至少加上了一些需求的約束，減小需求變更的範圍。現實中的大多數專案後期出現的變更基本上都超出最初的專案範圍，把這類變更也算在需求變更的範圍內，個人覺得不是太合適，超出專案範圍的變更，就不應再屬於專案內某一活動的變更。
動態地維護需求變更，對於需求管理人員來說就是在設計之前將需求確定下來。目前廣泛採用的方法是基於用例的需求獲取方法。對於用例，它只告訴了涉眾所需要的東西，並不是指專案的功能點。以前對用例的認識是，只要開發出了乙個用例，就好比找到了專案的乙個功能點，在看了
之後，感覺只使用了用例的很小一部分功能。現在要讓我做出更深層次的解釋，尚拿不出，只能通過不斷的學習加深理解。
對教育的一點看法
百年大計，教育為本。這句話是誰說的，我就不說了，但是，什麼樣的教育是好的教育，什麼樣的人才是真正祖國需要的人才，什麼樣的教育模式才是真正好的教育模式，我作為乙個讀書讀了十多年的人，已經有了自己的看法，我想能看到我這篇博文的，都曾經有過乙個身份，那就是 學生 不論學歷是碩士 博士，還是本科專科，還是小...
對架構的一點看法
隨便想到點什麼就隨便寫寫，但是在實踐過程中，以下幾點真的很重要 關於架構 1.所有脫離業務的架構設計都是耍流氓 2.架構設計就是解決問題 權衡利弊的過程 3.權衡是架構逃避不掉的問題。可擴充套件性 業務方需求 效能 現狀 改變代價等的權衡 4.架構一定要有全域性觀 關於能力 1.相比於用過某個軟體某...
對C 中new的一點看法
在 c語言中，動態獲取記憶體空間一般是通過執行時庫的 malloc 或calloc 相應的釋放函式為 free 除此以外，還可以直接使用 win32 的api globalalloc localalloc 在c 中，增加了乙個新的記憶體分配操作符 new，使用者可以根據自己的需要實現動態記憶體申請，...