在資訊化高速發展的今天，構建與時俱進的資訊化系統已成為所有**、企事業單位的重點課題之一。然而在軟體專案實施過程中，進度超期、經費超預算、變更頻繁的現象層出不窮，甚至有許多專案根本無法達到預期的目標，更談不上為業主創造真正的效益。歸根結底，軟體需求實踐這一共同的軟肋是問題的根源。
隨著資訊化應用的逐漸深入，軟體專案在企業、**等各類組織中所擔負的角色也越來越多，應用層面也在逐漸地深入，同時也意味著不同的軟體專案具有不同的特點，這也就對需求工作產生了諸多影響。 在本章中，我們就將針對資訊系統、嵌入式系統、軟體產品等不同角度來說明如何進行相應的需求工作，為需求分析師提供乙個切實有效的檢視。
筆者在做需求分析師的培訓時，經常會問學員這樣的乙個問題：什麼是軟體需求？這個看似簡單的問題卻並不好回答，也許很多人會簡單地認為軟體需求就是使用者需要實現的功能加上一些非功能方面的要求。但這樣的理解卻並不完整，如果對使用者所處的業務場景沒有建立正確認識，經常會給工作帶來麻煩。因此本章將對一些與需求、需求工程相關的關鍵概念進行闡釋。
需求定義活動準確來說是不屬於需求工程範疇的，它實際上是立項管理需要做的工作。但需求定義階段的產物對於需求捕獲、分析與建模活動都有著直接的影響，如果這個階段的工作做得不理想，就會出現「上樑不正下樑歪」的結果。因此本書還是將這個活動納入進來，並將給大家提供乙個能夠與後續活動結合緊密的方法。
需求捕獲是需求開發中的第乙個活動，可以說任何乙個需求團隊對它都不陌生，但如何提高需求捕獲的有效性卻一直以來是困擾大家的問題。需求捕獲的要點在於計畫性和科學性，計畫性體現在對捕獲物件、問題、時間的計畫，科學性則表現在如何有效地選擇合適的捕獲方法。本章的目的就在於幫助大家更好地達到這兩個目標，從而提高需求捕獲活動的質量
需求分析是需求工程中最為核心的工作，而需求建模則是需求分析的主要手段。但由於分析這個詞比較抽象，很多時候讓人感到無從入手，甚至導致被輕易地滑過了，直接將需求捕獲的結果整理到軟體需求規格說明書中。而需求建模也有很多任務具，到底怎麼有效地應用到需求分析過程中也是令人感到難以掌握的東西。因此本章的目標就是為讀者勾勒出需求分析的階段與任務，指出如何選擇適合的建模工具，以及在什麼時機、如何應用這些建模工具。
需求描述就是將需求捕獲、分析的結果進行文件化的過程。在軟體開發時，將分析的結果文件化是不可或缺的任務，也稱為編寫規約活動；而在某個專案中，可能還會由使用者代表或需求捕獲人員對捕獲的內容進行整理，形成使用者需求說明書。具體要幹什麼，想必大家並不陌生，而且在前一章中也看到了一些例項的片段。因此本章將重點從需求描述的風格與格式、寫作策略與技巧兩個方面做些強調和補充。
需求驗證是需求開發的最後乙個環節，它是乙個質量關。也就是說，其目標是發現盡可能多的錯誤，減少因為需求的錯誤而帶來的工作量浪費。而需求驗證的主要手段就是review（複查，也常譯為評審）。但是許多需求團隊都覺得需求驗證比較容易變得「務虛」，收效很少，本章的目標就是幫助大家緩解這個問題。
軟體需求閱讀筆記01
軟體需求實際就是 業務知識 問題列表 其他元素 軟體需求的三層次 業務需求 使用者需求 軟體需求。需求也有著三種型別 功能需求 非功能需求 設計約束。不完整的需求 缺乏使用者參與 不切實際的使用者期望 需求變更頻繁 提供了不再需要的 敗因解決方案 1 不完整的需求 採用業務導向讓使用者參與到完整性評...
《軟體需求》閱讀筆記01
開篇首先先介紹了乙個關於phil和 maria 的關於客戶姓名更改這個功能沒有實現而造成的問題，這個問題包括很多內容 資訊收集不正規 功能隱晦 對假設功能有理解上的分歧 需求制定不明確以及需求變更不正規等。關於使用者需求，文中肯定了 ian sommerville and peter sawyer ...
軟體需求閱讀筆記01
建築往往是根據設計圖來完成的，軟體也不例外，乙個專案的質量和設計規劃圖有著密不可分的關係。這之間的聯絡，簡單來說，便是使用者和工程師的溝通，使用者說出自己的需求來讓工程師去實現。而需求包括三個不同的層次 業務需求 使用者需求和功能需求，需求使問題變得明確，它是一一指明實現說明的規格說明，描述了系統的...