第1部分原型、模型與誤區
第1章需求實踐現狀分析
軟體專案失敗的根源
導致成本超支、進度超期的十大因素：缺乏使用者參與（12.8%）、不完整的需求（12.
3%）、需求變更頻繁（11.8%）、缺乏執行層的支援（7.5%）、技術能力缺乏（7.
0%）、資源不足（6.4%）、不切實際的使用者期望（5.9%）、沒有清晰的願景和目標（5.
3%）、不切實際的時間限制（4.3%）、新技術風險（3.7%）、其他（23.
0%）需求相關敗因簡要分析：
1、 不完整的需求
需求規格說明書應該採用業務導向的樹型層次結構來組織
2、 缺乏使用者參與
事不關己，高高掛起；逃離無趣區；被你趕走
對於需求分析員而言，真正的專業主義是基於業務利益（解決問題、創造機會、提高管控力等）的溝通
3、 不切實際的使用者期望
原因：軟體的無形和成本的不透明
做不到是無效的，要說明為什麼做不到
4、 需求變更頻繁
對變更進行分類、統計
讓使用者意識到變更對軟體專案的負面影響，統一變更處理渠道
5、 提供了不再需要的
在最開始有效地劃分優先順序
一幅漫畫帶來的思考（需求「迷途」）
1、 溝通失真
文件、review(再看一遍)：使用者代表闡述了需求之後，需求分析員用自己的語言再複述一遍，以確保溝通沒有失真
2、 客戶的需求放大
客戶希望支付的成本盡可能少，獲得的效益盡可能多：一方面需要提公升軟體估算實踐的有效性，另一方面則需要產業成熟度的提高
解決方案的選擇權交給了不熟悉技術的客戶：在需求捕獲的過程中多問「為什麼」。
3、 專案經理的需求控制
應該以業務為線索來組織需求，基於「why」的層面對需求建立高層次的認識。
4、 分析人員的技術加工
需求分析的本質在於業務分析，而非技術分析
5、 編碼人員的斷章取義
業務場景是需求之魂
透過表象，分析本質
1、需求變更頻繁
重視對需求變更的分析和管理
針對不同型別的變更進行分類，對於頻繁類的變更在調研的時候重點提問
2、上線阻力大
利益衝突（主要發生在管理層）
在需求捕獲的過程中細心地發現和總結潛在的行政因素，然後在系統實施之前將這些因素整理成文，直接提交給客戶方的高層。
工作量增大（主要針對基層，即操作層）
在需求階段就著手解決：提高易用性、工作量價值化、將資料遷移、準備工作獨立出來
執行效果差
從問題或機會入手，提高管理人員的推動力：針對不同管理人員的內動力分析
從障礙和困難出發，解決操作人員的積極性
完全崩潰
一般是忽略了某方面的非功能需求。「定性」的方法描述非功能需求，是一種無效資訊的傳遞，採用「定量」的方法描述
第2章不同軟體專案的需求檢視
1、資訊系統的需求檢視
資訊系統是人、資料、過程和介面的組合，它們之間相互作用，支援並改進企業的日常運作，並支援管理人員和使用者解決問題和做出決策。其本質就是資料資訊化
支援企業日常運作：對企業流程進行電子化，並且將其固化下來。
支援解決問題：解決企業運作中存在的問題
支援決策：通過有效地獲取、加工、處理資料，為管理人員提供決策的支援。
分類聯機事務處理系統（oltp）——資料的生產者，流程電子化
管理資訊系統（mis）——資料的消費者
主管資訊系統（eis）——資料的高階消費者
決策支援系統（dss）——資料的高階消費者
專家系統——個人知識的沉澱，同時也是資料的消費者
辦公自動化系統（oa）——對溝通與協作的直接支援
（1） 聯機事務處理系統——流程電子化
電子化的流程更利於流程的固化
電子化的流程會對業務產生一定的約束
（2） 管理資訊系統——資料資訊化
報表需求的分析（主要是對資料的消費），從管理的場景入手，從理解報表的目的著手來與使用者溝通，而不是從報表的格式上入手。
報表分析要點：why（目的）：報表的目的，使用的部門/職位，相關的場景
what（怎樣獲得）：關聯的實體，關鍵指標及計算規則
how（如何展現）：展現形式，輸入輸出需要
2、嵌入式系統的需求檢視
1) 面向直接使用者
在對面向使用者的嵌入式系統在需求梳理時首先是找到具體的使用場景，然後再對重要功能域中的重要使用場景進行行為分析。
2) 面向特定裝置
梳理對外介面，重點在於找到與該系統相關聯的外部系統，然後明確外部系統與其的功能互動點。
整理完外部介面之後，接著就是對其內部功能進行分析與描述。分析內部功能時以事件作為線索。
3、軟體產品的需求檢視
1) 資訊系統類產品
首先對目標市場進行分析（目標客戶分析、競爭對手分析、商業模式分析），然後再進行產品體系設計。
需求重點：針對不同目標客戶群體的不同商業模式分離變化點;經常需要減出通用性，再通過插接解決擴充套件性。
2) 工具類軟體產品
在整理需求時先對不同使用者進行分析，標識出具體的使用場景，然後針對不同的使用場景進行分析，確定所需的功能點。在確定使用者型別的時候還可以考慮根據不同人群的特點進行細分。
人機互動也是很重要的一部分，可以採用使用者介面原型驅動的方式進行描述。
第3章軟體需求與需求工程
一、 什麼是軟體需求
軟體需求=業務知識+問題列表+其他因素
業務知識：業務事件、業務實體、業務規則
問題列表：使用者在工作中遇到的困難與障礙，也是軟體開發時需要解決的問題
其他因素：設計約束和非功能方面需求
1. 需求的三個層次
業務需求：反映企業/組織對軟體系統的高層次目標要求，也是軟體系統的建設目標，通常體現在兩個方面
問題：解決企業/組織運作過程中遇到的問題。
機會：抓住外部環境變化所帶來的機會，以便為企業帶來新的發展。
時機：在專案立項階段整理，是需求定義的產物。
使用者需求：描述的是使用者使用軟體需要完成什麼任務。特點是零散和存在矛盾性。
時機：在業務需求定義的基礎上進行使用者訪談、調查，對使用者使用的場景進行整理，從而建立使用者角度的需求，是需求捕獲的產物。
軟體需求：需求分析人員對使用者需求進行分析、提煉、整理，生成指導開發的、更精確的軟體需求，是需求分析與建模的產物。
2. 需求的三種型別
功能需求：要點在於如何組織。
非功能需求：要點在於保證資訊的有效傳遞和注意其區域性性。
設計約束：包括非技術因素的技術選型、預期的軟硬體環境和預期的使用環境三大型別。
3. 優秀需求的標準
完整性——使用者驗證需求的完整性；不同層面需求完整性的驗證
不失真——正確性；無歧義性
有優先順序——必要性（通過滿意度/不滿意度確定）；需求的優先次序
有技術早期介入——保證可行性和可驗證性
二、 需求工程解析
需求工程包括需求開發和需求管理兩大範疇。
需求開發包括需求獲取、需求分析、編寫規約、需求驗證。
重點：開發出高質量的需求規格說明。
需求管理包括基線管理、變更管理、需求跟蹤。
重點：對需求的實現、變化進行追蹤，確保開發的軟體滿足這些需求。
需求開發中的需求獲、需求分析、編寫規約和需求驗證是多次迴圈的過程，如下圖所示：
整個軟體開發過程中至少經歷三次這樣的迴圈。
需求管理工作要點
1) 統
一、明確的需求項劃分標準：粒度均勻、大小合適、完整
2) 引入基線管理：關鍵是需求優先順序與工作量估算
3) 引入變更管理：業務影響分析、技術影響分析、專案影響分析
4) 引入需求跟蹤
《軟體需求最佳實踐》學習總結 第1部分 原型 模型與誤區
第1部分原型 模型與誤區 第1章需求實踐現狀分析 軟體專案失敗的根源 導致成本超支 進度超期的十大因素 缺乏使用者參與 12.8 不完整的需求 12.3 需求變更頻繁 11.8 缺乏執行層的支援 7.5 技術能力缺乏 7.0 資源不足 6.4 不切實際的使用者期望 5.9 沒有清晰的願景和目標 5....
軟體部測試總結 1
2009年基伍偉業手機軟體測試年終總結 作為軟體測試職員，我們至少要懂一點gsm標準協議的基礎知識，如果懂軟體工程的則更好，那就能更清楚地預知哪一塊容易出問題，當發現問題後，就要分析產生問題的原因，這樣就不是一種簡單的黑盒操作了。測試方向 1.驗證各種功能都已正常實現，如 1 簿中新增 編輯 查詢 ...
實踐部學習總結
七 加強部門內部建設 對於乙個部門的發展而言，實際上就是每乙個個人的發展。而發展需要總結和激情。短期的激情維持需要歡快向上的氣氛，而長期的激情維持則需要讓每乙個在其中切實感覺到有所提高，付出後有收穫，而大家在一起，本來就是一種珍貴的緣分在起著作用。所以和部門人員的關係不是簡單的上下級關係，更是親密的...