需求實踐所面臨的問題
需求分析的核心線索
在 原有的需求分析方法中，我們往往過多的關注how，而沒有關注what，或者關注了what而沒有關注what背後的需求場景和背後的問題why。這都導 致我們沒有進行很好的需求挖掘。需求分為業務需求，使用者需求和軟體需求三個層面。而我們在平時的需求分析中往往很容易直接跳到了軟體需求階段，而忽視了業 務需求和業務建模。
需求定義輸出業務需求；需求捕獲輸出使用者需求；需求分析輸出軟體需求。需求分析的本質動作就是分解，抽象和消除歧義。而對於需求分析的本質線索則是人，事(流程)，物(資料)和介面。因此需求分析不能完全等同於建模型。分析是本質，建模僅僅是手段。
需求捕獲
需 求捕獲是乙個不斷的探索過程。在需求捕獲中，溝通佔40%，業務佔30%，技術佔30%。而對於溝通往往講究的並不是單純的技巧，而更多的是一種思維模式 和順序的問題。在這裡老師引入了思維模式的話題，也通過乙個案例講解了溝通中順序的重要性，如先將解決方案再講具體場景和問題(類似於我上個ppt裡面強 調的結構化思維的乙個重要原則即開門見山的逐層展開)。在溝通中講了三個可以借鑑的方法。
探求本源(問題背後的問題，引入了《你的燈亮著嗎》，講到了沒有荒唐需求，只有荒唐的解決方案)
需求訪談是捕獲中的乙個重要內容，這裡做乙個概括總結：
需求規格說明書
業界關注需求有很多標準，如gb2006等，但是關於功能性需求方面都不能再細化展開，因此標準僅僅是乙個展開。各個行業或組織還需要根據自身軟體專案特點對模板進行補充和完善。
需求分析過程應該是乙個業務流程驅動的至上而下的過程。開始不應該一下轉入到乙個具體的功能細節，而是應該先規劃目錄和打提綱，然後以流程為主線逐層分解和展開。在需求描述上可以是文字，也可以是圖形化的，也可以是一種形式化規格表達。
需求規格說明書模板的內容也可以逆向思維，如設計需求我們提供什麼樣的需求對他們才是最有參考意義的。我們的需求調研不應該是通過模板格式來決定內容，再決定溝通。而是應該根據需要的溝通來決定內容，根據內容來決定我們需要什麼樣的需求模板和格式。
需求驗證是一種質量活動，在這裡要注意驗證和確認的區別，一般驗證活動主要方式就是reivew，而reivew根據正式程度又包括了審查，多人複審，單人複審等多種方式。需求驗證的五大要素包括：
思想：找到盡可能多的錯誤
方法：從非正式的開始，並逐漸形成文化
語言：從評價者轉化為建議者，強調協作者進來減少用你**錯了，而多用我建議如何
內容：不是全部而是最合適
需求管理的三大內容是基線，變更和狀態跟蹤。其實基線和變更都屬於配置管理的需求跟蹤。需求跟蹤又包括了對需求-》設計-》測試整個需求鏈的跟蹤，同時也 包括了對需求實現狀態的跟蹤。在這個過程中基線是迭代開發的基礎，但是迭代開發往往又是最難去規劃和打基線的。在這裡的原因是我們是以整個文件作為基線的 物件，而不是以文件中的條目化需求作為基線的物件。另外對於變更管理其核心作用是通過變更管理減少變更對目標的影響。
迭代開發和分階段開發
在rup的三要素中最後乙個就是增量迭代，但是要注意到迭代是手段，增量是目標。而且每乙個迭代其本身就是乙個微型的瀑布。迭代使目標更加容易分解和明確。
估 算是在專案管理中做專案計畫的基礎，不能因為估算不準確而不去做估算和計畫，堅持估算和檢查估算歷史資料的收集就不斷的糾正估算的經驗資料，而使估算準確 性得到提高。同時，估算的本質是計算單元和複雜因子，首先要選擇好相應的估算方法，如在需求早期往往並不適合用功能點法進行估算；其次就是要識別計算單 元，然後再確定具體的複雜度。
需求變更是無法避免的，但是我們要儘量減少和控制變更帶來的影響。需求變更是需求管理的乙個核心內容，有了需求變更自然會涉及到需求基線和配置管理的內容。例如我們可以講對於已經基線的配置項要修改都必須要走變更流程等。對於需求變更主要有以下重點：
目標的尋找方法可以用gpoa方法：goal-problem-option-answer。在確定專案目標和範圍的時候，我們往往容易提出類似要建立一 個先進的資訊系統一類的不清晰的目標。而如何破解不清晰的目標？可以從兩個方面來考慮:內部溯源(專案的原始發起人，溝通)；外部尋因(受到外部刺激)
rup中的問題分析五步法:
對於訪談這塊的案例和實戰都很好，暫時不展開了，感覺還是有很多原來在訪談中沒有注意的內容，特別是開門點和訪談策略兩個方面。具體綜述下高層訪談主要關注點:
開門點：易於回答而且激發其興趣
用例是一種紀錄新系統或軟體更換時的需求的技術。每個用例包含乙個系統在作業時與使用者或與其它系統之間交換資訊的場景。一般用例避免使用術語，而盡量使用顧客、使用者或他們的專家的語言。一般用例由軟體開發者和顧客一起寫成。用例之道：
在用例中常用的關係是擴充套件(extend)，包含(include)和泛化。對於擴充套件和包含區別如下：
對於獲取用例的方法主要有兩種，一種是自頂向下的流程派生法，跨職能流程圖和泳道就是參與者，其中的業務活動就是用例；另外一種就是自底向上的合併法，比如可以從條目化的使用者需求進行合併。在第一種方法中派生用例的時候需要注意：
對 於用例分析重點是事件和業務流程，而對於資料分析則重點是在業務資料上面。用例分析代替不了資料分析。資料分析常用的就是業務實體分析，通過資料分析可以 建立系統的領域模型。資料分析的目標就是理解業務領域中的業務術語和實體，包括語義關係，數量關係和主要內容。資料分析的要點就是要識別出具體的業務實 體，以及這些業務實體間的關係。在fdd中的領域建模是基於資料和行為的綜合分析，包括together之父petercoad發明的菜色建模法。他將數 據類分為了行為，參與角色，人事物，通用描述四個方面的內容。
在用例模板中有幾個關鍵 點，包括前置條件應該是系統必須能夠檢測和驗證的。在用例描述中應該拒絕太多的實現細節；用例本身無法展示很多介面互動，因此需求建模還應該包括介面和交 互建模的內容。而對於報表等需求往往並不太適合用例的表達方式，可以根據企業情況來確定具體的報表類需求的描述方法。
在用例模板中還有干係人利益的內容，在這裡特別說明的是分析干係人利益可以幫助我們挖掘潛在的需求。雖然關係人不是action事件的之間操作者，但是干係人的利益往往會影響到用例本身的需求。
軟體需求最佳實踐
需求實踐所面臨的問題 需求分析的核心線索 在 原有的需求分析方法中，我們往往過多的關注how，而沒有關注what，或者關注了what而沒有關注what背後的需求場景和背後的問題why。這都導 致我們沒有進行很好的需求挖掘。需求分為業務需求，使用者需求和軟體需求三個層面。而我們在平時的需求分析中往往很...
軟體需求的12條最佳實踐
筆者在諮詢實踐中總結了針對軟體需求工程的12條最佳實踐，羅列如下。所謂最佳並非嚴密的邏輯證明，而是經過大量的實踐與觀察依據經驗確定的，智者見智，仁者見仁，有爭議在所難免，僅供參考，能夠對大家有所啟發，足矣。1 成立甲乙雙方參與的需求控制組 專案的成功不單是乙方的成功，而是甲乙雙方的成功，甲乙雙方緊密...
《軟體需求最佳實踐》閱讀筆記06
第7章 需求描述最佳實踐 在描述需求時，我們首先確定以什麼風格來表述，另外還應該選擇與專案 團隊特點相符合的風格模板。常見的描述風格與選用標準 在描述需求時，最常見的描述風格個可以分成自然語言 圖形化模型和形式化規格描述3種 自然語言，也就是使用結構合理的自然語言來描述需求，這種形式不管對於寫的人還...