在現實社會中，人們為了解決生活中的各種問題，需要借助於軟體。但，每個人的需求都有不同，軟體團隊通過以下幾個步驟來獲取人們的需求：
1.獲取和引導需求
軟體團隊需要找到軟體得利益相關者，了解挖掘他們對軟體的需求，引導他們表達出真實需求。同時，需求還可以來自各種管理機構，還可以來自軟體企業本身，也可以來自技術團隊本身。有些需求的目的是要「更好的了解使用者的行為和需求」。
2.分析和定義需求
這是指對從各個方面獲取的需求進行規整，定義需求的內涵，從各個角度將需求量化。
3.驗證需求
軟體團隊要跟利益相關者溝通，通過分析報告、技術原型、使用者調查或演示等形式向他們驗證軟體團隊對於這些需求的認知。
4.在軟體產品的生命週期中管理這些需求
在軟體的生命週期中，需求在發生變化，技術在發展，團隊成員的能力也在提高。對軟體的需求也可作以下角度的劃分：
1.對產品功能性的需求：要求產品必須實現某些功能。
2.對產品開發過程的需求：要求軟體的開發流程必須滿足某些約束條件。
3.非功能性需求：這也叫「服務質量需求」。
4.綜合需求：有些需求不單單是乙個軟體模組就能滿足。
軟體開發不可能一次滿足所有利益相關者的要求，但我們一定要讓這些相關者在這個階段有機會提出他們的意見和需求，同時要弄清楚「他們想從軟體中得到什麼」。
軟體的開發過程，就是「使用者最需要的東西」在一條關係鏈中傳送、轉換、實現、扭曲、或丟失的過程。如何確定"使用者最需要的東西"我們可以靠一些經過實踐證明行之有效的辦法，其中許多具體做法既可以用在軟體需求的收集階段，也可以用在測試階段，下面就是經常用的使用者調研方法：
1.焦點小組、2.深入面談、3.卡片分類、4.使用者調查問卷、5.使用者日誌研究、6.人類學調查、7.眼動跟蹤研究、8.快速原型調研、9.a/b測試。
在使用者調查問卷方法中經常會出現一些常見錯誤，如問題1.定義不準確、2.使用含糊不清的形容詞、副詞描述時間、數量、頻率、**等、3.讓使用者花額外的努力來回答問題、4.問題帶有導向性、5.問題涉及使用者隱私、使用者所在公司的商業機密或細節等。問題調查問卷可以有以下這些問題：1.全開放式問題 2.二項選擇題 3.多項選擇題 4.順位選擇題等。
以上就是我對構建之法第八章的總結。
構建之法03
瀑布模型是將軟體生存週期的各項活動規定為按固定順序而連線的若干階段工作，形如瀑布流水，最終得到軟體產品。它在1970年由溫斯頓 羅伊斯 winston royce 提出，直到80年代早期，它一直是唯一被廣泛採用的軟體開發模型。本書中例出了瀑布模型的文件圖，但是鄙人並沒有看得很懂它的用意。搜尋一些關於...
構建之法03
軟體開發是一種集體活動，其中必然面臨各成員間的協調 統一問題。銀行每天都要對各網點進行清算結賬，軟體開發也是一樣的，必須找到一種方法來衡量每天的工作，保證每天的工作能夠有效的持續下去，最終把軟體開發的過程變成一種內在的過程。這種方法就稱為每日構建或是持續整合。每日構建構建的過程是完全自動化的，通過預...
構建之法閱讀筆記03
通過這幾天的閱讀，基本對本書又有了新的認識，讀完這本書是一回事，要想深入的理解又是另一回事。本書第一版出自2014年，當時軟體工程正在中國蓬勃發展，在此書出來之前大學裡的教材有些還是外國書籍的翻譯版本。豆瓣上對此書的介紹是 軟體工程牽涉的範圍很廣,同時也是一般院校的同學反映比較空洞乏味的課程。但是軟...