一場戰爭開始前，最重要的就是情報。正所謂知己知彼，方能百戰百勝。而軟體開發前最重要的一點，莫過於使用者需求的分析。做好了需求分析，才能有的放矢，避免開發出為開發而開發的軟體。
如何準確的獲取需求呢？書中給出以下步驟：
獲取和引導需求（elicitation）
分析和定義需求
驗證需求
軟體產品的生命週期中管理需求
軟體的需求可以劃分為：對產品功能性的需求、產品開發過程中的需求、非功能續期、綜合需求等
值得注意的是軟體的需求不僅僅包括使用者的需求，還包括顧客、市場分析者、監管機構、整合應用商、軟體團隊、軟體工程師等軟體利益相關方的需求。軟體開發中不一定能同時滿足所有相關方的需求，需要注意優先順序
使用者的需求需要人和人之間的準確溝通，在軟體開發的溝通鏈中，使用者真正的想要的需求往往會發生變形，導致軟體最終開發出來的並不是使用者真正想要的。如何準確掌握使用者的需求？書中列出以下方法：焦點小組、深入面談、卡片分來、使用者調查問卷、使用者日誌研究、人類學調查、眼動跟蹤研究、快速原型調研、a/b測試等。但是也要注意在應用使用者資料改進時，避免掉入吹毛求疵的陷阱。
在得到需求之後，下一步就是功能實現。功能實現可以分為殺手功能/外圍功能、必要需求/輔助需求四個象限劃分。
劃分好功能後，下一步就是制定計畫，在計畫制定和實施過程中，也需要準確估計計畫實現需要的時間。首先要區分好目標、估計和決心。估計各專案所需要的時間，看似容易卻不簡單。如果混淆了三者，後果會很嚴重，歷史上的「大躍進」就是典型的例子。軟體專案的估計可以從自底向上和回溯兩個方面來看。
專案要一點一點的做，感覺無從下手的專案要逐步分解成可以操作的工作。書中列舉的常用的分而治之的方法就是wbs：work breakdown structure wbs的目的就是從最終的產品開始，將專案分解成小型、具體的小件，「直到wbs的使用者（開發團隊、接收方）達到共識。」
《構建之法》需求分析 讀書筆記
後悔沒有早點讀完這章，回想團隊專案剛開始時做的需求分析，深深感到我們實在太天真 太理想。畢竟沒有理論指導，按習慣做調研是容易碰釘子的，不過現在專案還未正式啟動，亡羊補牢，為時未晚。我們踩中了哪些坑？未能充分引導使用者表達需求 我們採用了問卷調查的方式，但沒有做進一步的深入調研。問卷調查有其好處 簡單...
構建之法 第8章 需求分析
本章重點 如何準確而全面地找到需求 分析和定義需求 analysis specification 這是指對從各個方面獲取的需求進行規整，定義需求的內涵，從各個角度將需求量化，包括需求實現的最後期限 實現需求大致所需的時間和資源成本 各個不同需求的優先順序 需求帶來的收益等等 在軟體產品的生命週期中管...
《構建之法》讀書筆記第3章
第三章講的是軟體工程師的發展。主要從軟體工程師的評價方法，團隊期望和技能的反面進行闡述，並對應的分為3個小節。在第一小節中講的是個人能力的衡量與發展。對於初級軟體工程師的成長，從以下5個方面開始 積累軟體開發相關的知識，提公升技術技能 積累問題領域的知識和經驗 例如 對醫療或金融行業的了解 對通用的...