軟體需求管理－用例方法，讀書摘要

軟體需求管理，是軟體設計的第一個環節，與軟體的成與敗休戚相關。很多軟體都在需求未完全清楚前（或自以為清楚）開始，在修修補補中結束。因此需求管理是
一個軟體開發人員首先要掌握的技能。且，需求管理方面的知識，無實踐不行，而有實踐無理論也不行。因此，不同的人對此方面知識的需求不同。本人應該屬於第
二種類型。因此下文主要是我在看此書過程中的摘要。也許會有自己的思想，也許只有書中語句的copy。

前言部分：
軟體項目中的兩個最基本問題：這個軟體到底做什麼；我們怎麼才能知道軟體完成了所要求的工作而不是其他工作。－－往往看起來最簡單的問題，恰恰是最難以回答的問題。
開放團隊所需要的技能：分析問題；理解使用者和涉眾的要求；定義系統。－－很多時候都會忽略“涉眾”的要求。
我們必須學會在正確的時間，用正確的方式提出正確的問題。－－能做到此點，是軟體開發的萬幸。

引言部分：

第一章  需求問題
軟體開發目標是在預算內按時開發出符合客戶真正需要的高品質的軟體。
解決任何問題的第一步都是理解問題的基本原因。
據統計軟體項目失敗的三大首要原因：缺乏使用者的輸入（13％）；不完整的需求和規格說明（12％）；不斷變更的需求和規格說明（12％）。
軟體成功的三個重要因素：使用者介入（16％）；行政管理支援（14％）；需求陳述清晰（12％）。
一半以上被調查人認為兩個最大問題是：需求規格說明；管理客戶需求。相對而言，編碼不是問題。
需求階段發現並修複錯誤與維護階段發現並修複錯誤所花費的成本為1：200。
設計階段發生錯誤可能有兩類：需求正確，設計錯誤；需求錯誤，設計時才發現。後一種危害更大。
小結：
本章資料表明兩件事情：需求錯誤可能是最常見的錯誤；需求錯誤可能是修改花費最昂貴的錯誤。
從經濟上講，需求錯誤可能消耗整個項目預算的25%-40%

第二章  需求管理簡介
需求定義了系統必須的能力，項目成功往往取決於它是否符合需求。
開發路線圖－在規定時間和預算內開發符合客戶真正需要的系統。需要－特性－軟體需求
問題領域是真正使用者和其他涉眾的所在，要理解他們用他們的文化表達出的他們的問題，並轉化為我們要解決的問題。
理解使用者以及其他涉眾的要求，也是我們的責任。
特性：系統提供的一項服務，用來滿足一個或多個涉眾的需要。

第三章  需求和軟體生命週期
團隊開發過程為4W：定義了誰（Who）正在做什麼（What）、什麼時候做（When）、怎麼做（How）－－工作流程好像也有類似的表達
瀑布模型最重要問題之一：對系統還沒有足夠理解時，就開始了編碼。－－感覺是瀑布模型容易使需求僵化，研著錯誤的路線前進，到最後才發現問題。
螺旋模型：增量式開發。優點在於，可以即使得到反饋。
迭代方法，集合了兩者優點。由四個過程組成：先啟（inception）、精化（elaboration）、構建（construction）和產品化（transition）
先啟：理解需求，問題分析；精化：細化需求，建立體繫結構，開發原型系統；構建：編碼實現；產品化：B測試
在軟體開發的每個過程中，都需要採用迭代方法。
迭代優點：更好的需求適應性；更好的範圍管理

第四章 軟體團隊
電腦程式設計是一種人類活動－GeraldWeinberg
軟體開發已經變成了一種團隊活動－Grady Booch
軟體開發曆史就是規模逐漸層大的曆史
需求管理觸及團隊的每一個成員，儘管以不同的方式
高效的需求管理只有通過一支高效的團隊才能實現
團隊六大技能：分析問題；理解使用者與涉眾的需求；定義系統；管理範圍；細化系統定義；構建正確的系統
缺乏使用者介入、不完整的需求和規格說明、不斷變化的需求和規格說明是所有未能完成目標的項目的普遍問題

下部分介紹：團隊技能之一——分析問題