軟體需求實際就是「業務知識+問題列表+其他元素」。軟體需求的三層次：業務需求、使用者需求、軟體需求。需求也有著三種型別：功能需求、非功能需求、設計約束。
不完整的需求
缺乏使用者參與
不切實際的使用者期望
需求變更頻繁
提供了不再需要的
敗因解決方案：
1 不完整的需求
採用業務導向讓使用者參與到完整性評價當中，在實際過程中利用樹形層次結構將巨集觀資訊與微觀資訊進行有效的剝離。
分析:利用樹形層次結構面向不同的層面：決策層，事務管理層，操作層，讓合適的人驗證相關的部分，這樣可以有效的避免事不關己，高高掛起。讓使用者逃離無趣區和有效的啟發使用者的積極性，減少被專業人士排除在系統的完整性評價之外
2 缺乏使用者參與
3 不切實際的使用者期望
由於軟體的無形和成本的不透明，需要說明軟體中不能完成的需求的原因
4 需求變更頻繁
對變更進行分類，統計，有針對性的改進需求過程，提高設計的彈性
5 提供不在需要的
找到使用者經常使用到的功能，也即使用者的需求，放棄使用者很少使用的功能模組的開發
具體方案：在每個功能模組入口處，放置乙個計數器
溝通失真
客戶的需求放大（圖1、10）
專案經理的需求控制（圖1、2）
分析人員的技術加工（圖3）
編碼人員的斷章取義（圖4）
失敗的原因
分析原因與解決方案
1、溝通失真
分析：每個角色（如專案經理，商業顧問等）更加自己的特點和需求對資訊（漫畫）進行了不同程度的加工，從而導致資訊內容有很大的變化
解決方案：
1、 利用文件：防止資訊在傳遞的過程中走樣
2、reviews （評審）：在此審閱，需求人員在此用語言複述軟體需求。
2、客戶需求放大
分析：1、客戶希望支付的成本盡可能少，獲得的效益盡可能多。
2、解決方案的選擇權較給了不熟悉技術的客戶。
解決方案1：
1、需要提公升軟體估算實踐的有效性
2、提高產業成熟度
解決方案2：
需求捕獲的過程中多問為什麼
3、專案經理的需求控制
分析：需求捕獲的過程中，導致需求產生了偏差，部分從技術的角度對需求進行了控制，造成無法對需求的有效理解
解決方案：
減少技術在需求提取過程中的不利影響
4、分析人員的技術加工
分析：分析人員對技術能力的追求高於業務能力的追求
解決方案:
提高自己的業務分析能力
5、編碼人員的斷章取義
解決方案：業務場景是需求之魂
需求規格說明書應該採用業務導向的樹形層次結構來組織
對於需求分析員而言，真正的專業主義是基於業務利益（解決問題、創造機會、提高管控力等）的溝通
緩解溝通失真的最有效的方法是及時複述
需求分析的本質在於業務分析而不是技術分析
業務場景是需求之魂
軟體需求閱讀筆記01
在資訊化高速發展的今天，構建與時俱進的資訊化系統已成為所有 企事業單位的重點課題之一。然而在軟體專案實施過程中，進度超期 經費超預算 變更頻繁的現象層出不窮，甚至有許多專案根本無法達到預期的目標，更談不上為業主創造真正的效益。歸根結底，軟體需求實踐這一共同的軟肋是問題的根源。隨著資訊化應用的逐漸深入...
《軟體需求》閱讀筆記01
開篇首先先介紹了乙個關於phil和 maria 的關於客戶姓名更改這個功能沒有實現而造成的問題，這個問題包括很多內容 資訊收集不正規 功能隱晦 對假設功能有理解上的分歧 需求制定不明確以及需求變更不正規等。關於使用者需求，文中肯定了 ian sommerville and peter sawyer ...
軟體需求閱讀筆記01
建築往往是根據設計圖來完成的，軟體也不例外，乙個專案的質量和設計規劃圖有著密不可分的關係。這之間的聯絡，簡單來說，便是使用者和工程師的溝通，使用者說出自己的需求來讓工程師去實現。而需求包括三個不同的層次 業務需求 使用者需求和功能需求，需求使問題變得明確，它是一一指明實現說明的規格說明，描述了系統的...