在之前我老以為需求是通過和客戶的交流得來的在讀了構建之法後才知道事情遠非這麼簡單。
在現實社會中，人們為了解決生活中的各種問題，需要借助於軟體。但，每個人的需求都有不同，軟體團隊通過以下幾個步驟來獲取人們的需求：
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.順位選擇題等。
在以後的學習探索中我會選擇與構建之法中類似的方法深入探索明確客戶需求。
構建之法閱讀筆記05
時隔多日，自己又重拾 構建之法 今天對需求分析這部分進行了閱讀。當我們程式設計師在編寫軟體之前要做的就是了解使用者的需求，準確而全面地找到需求主要有以下幾個步驟 1 獲取和引導需求 elicitation 我們需要找到軟體的利益相關者，了解和挖掘他們對軟體的需求，引導他們表達出對軟體的需求。很多時候...
構建之法閱讀筆記05
本次閱讀了第十三 軟體測試 十四章 質量保障 在軟體發布前基本沒有進行測試，直到上台講述的之前的一段時間才發現了一些問題，甚是著急 第十三章中excel計算1900閏年錯誤的例子給了我乙個全新的概念 要服務於最主要的功能.傳說中的拐點 小飛 我聽說在軟體專案中，有這樣乙個拐點存在 在這一點之前，新的...
構建之法閱讀筆記05
這是構建之法的最後一篇閱讀筆記 這幾天主要閱讀了it的創新這一章，創新在現代的社會中是乙個被說爛了的詞語，各行各業都在提倡創新，就連學校裡也在提倡什麼創新創業大賽 在 構建之法 的創新迷思一節，列舉出了七個迷思，接下來分別作出乙個簡要的概述。迷思之一 偉大的創新總是靈光一現。迷思之二 大家都喜歡創新...