需求**、需求收集方法
軟體需求可以來自方方面面，這取決於所開發產品的性質和開發環境。需從不同使用者代表和**收集需求，這說明了需求工程是以相互交流為核心的性質。下面是幾個軟體需求的典型**。
1）. 訪問並與有潛力的使用者**為找出新軟體產品的使用者需求，最直截了當的方法是詢問他們。
2）. 把對目前的或競爭產品的描述寫成文件
文件可以描述一種所必須遵循的標準或產品所必須遵循的**或工業規則。
3）. 系統需求規格說明
乙個包含軟、硬體的產品需要乙個高檔次的系統需求規格說明以介紹整個產品。系統需求的子集被分配到每個軟體子系統中（nelsen 1990） 。附加的詳細軟體功能需求將從有關軟體
的系統需求裡獲得。
4）. 對當前系統的問題報告和增強要求指導使用者和提供技術支援的工作人員是最有價值的需求**。他們收集了使用者在使用現有系統過程中所遇到問題的資訊，還接受了使用者關於系統改進的想法。
5）. 市場調查和使用者問卷調查
調查有助於從廣大有潛力的使用者那裡獲得大量定量的資料，務必調查相關的使用者並詢問一些能產生反響的好問題。
6）. 觀察正在工作的使用者
對當前系統的使用者和將來系統的有潛力的使用者，分析員觀察「日常工作」以獲得經驗，這些經驗能提供很有價值的資訊。分析員可通過觀察使用者與所關聯的任務環境的工作流程來預見使用者在使用當前系統時所遇到的問題，並能分析新的系統可有效支援工作流程的方面（mcgraw and harbison 1997; beyer and holtzblatt 1998） 。比起僅僅簡單地詢問使用者，並記下使用者在處理任務時的步驟來說，直接觀察使用者的工作流程可以對他們的活動有更正確的理解。分析員必須抽象和總結使用者的直接活動，以確保所獲得的需求具有普遍性，而不僅僅代表單個使用者。乙個富有技巧的分析員還可以為改進使用者的當前事務處理過程提出一些見解。
7）. 使用者任務的內容分析
通常通過開發具體的情節（s c e n a r i o）或活動順序（有時稱作「情節」 ） ，可以確定使用者利用系統需要完成的任務，分析員由此可以獲得使用者用於處理任務的必要的功能需求。這是使用例項方法的精髓。
7、需求開發活動指導方針
對於需求開發沒有乙個簡單的、公式化的途徑。下面列出了1 4個步驟，你可以利用它們指導你的需求開發活動。
1）. 定義專案的檢視和範圍
2）. 確定使用者類（比如市場人員、財務人員、生產人員等）
3）. 在每個使用者類中確定適當的代表
4）. 確定需求決策者和他們的決策過程
5）. 選擇你所用的需求獲取技術
6）. 運用需求獲取技術對作為系統一部分的使用例項進行開發並設定優先順序
7）. 從使用者那裡收集質量屬性的資訊和其它非功能需求
8）. 詳細擬訂使用例項使其融合到必要的功能需求中
9）. 評審使用例項的描述和功能需求
10）. 如果有必要，就要開發分析模型用以澄清需求獲取的參與者對需求的理解
11）. 開發並評估使用者介面原型以助想像還未理解的需求
12）. 從使用例項中開發出概念測試用例
13）. 用測試用例來論證使用例項、功能需求、分析模型和原型
《軟體需求》讀書筆記四
需求捕獲應該是主動的 需求捕獲應該是聚焦的 案例 小趙問監控中心的小張 你對這個系統有什麼需求？小張說 我想到的功能包括值班日誌 告警的聲光提示 基於簡訊的告警通知.老李問小徐 當監控中心收到乙個告警的時候，希望以什麼形式來體現？收到後，你們一般會進行什麼樣的處理？小張的提問使得捕獲過程很發散，而老...
《軟體需求》讀書筆記03
業務需求代表了需求鏈中最高層的抽象 他們為軟體系統定義了專案檢視和範圍。軟體功能需求必須根據使用者的需求來考慮，且要與業務需求所設定的目標相一致。對不利於實現專案業務目標的需求應該排除在外。乙個專案可能包括一些與軟體沒有直接關係的需求，例如 硬體的購買 產品的安裝 維護或廣告。但在此，我們只關心與軟...
《軟體需求》讀書筆記01
許多軟體問題都源於收集 記錄 協商和修改產品需求過程中的方式不當，包括資訊收集方式不正規，沒有明確提出想要的功能，假設是未經過溝通的錯誤假設，需求的定義不夠充分，以及未經仔細考慮進行需求變更等。在軟體開發中遇到的問題時，人們常常輕率地將其忽略。軟體專案中40 60 的缺陷都是由需求分析階段的過失所致...