今天閱讀了《構建之法》有關需求分析和典型使用者及場景分析相關的章節，有很多思考。我們做軟體，必須了解使用者的需求。做需求分析得有步驟有條理的進行。
首先是引導需求。我們需要找到軟體的利益相關者，了解和挖掘他們對軟體的需求，引導他們表達出對軟體的需求。很多時候使用者並不知道自己確切的需求，或者不願意表達完整的需求，軟體團隊需要設身處地，替使用者著想，引導出需求。有些需求在實現之前，並沒有使用者明確表達具體的需求。我們還需要分析技術的發展趨勢以及產業的變化、社會發展的大趨勢，推測使用者會產生哪些新的需求。需求還可以來自技術團隊本身，團隊在考慮軟體的**、架構、所依賴平台的長期演化的時候，會提出技術性的需求，包括**的遷移、架構的演化、平台的變化，或者引入新的技術。有些需求的目的是要「更好地了解使用者的行為和需求」。
其次是分析和定義需求。這是指對從各個方面獲取的需求進行規整，定義需求的內涵，從各個角度將需求量化（需求實現的最後期限，實現需求大致所需的時間和資源成本，各個不同需求的優先順序，需求帶來的收益，等等）。
接著是驗證需求。軟體團隊要跟利益相關者溝通，通過分析報告、技術原型、使用者調查或演示等形式向他們驗證軟體團隊對於這些需求的認知。
最後需要我們在軟體產品的生命週期中管理需求。在軟體的生命週期中，需求在發生變化，技術在發展，團隊成員的能力也在提高。原來認為重要的事情可能不再重要，有些功能原來技術上很難實現，現在出現了捷徑，一些相關的法規會發生變化，外部的合作夥伴突然發生變化，這些都要求我們不斷對需求進行重新審核並做出相應的調整。
關於需求的分類，有這樣幾種分類方法。首先是對產品功能性的需求：要求產品必須實現某些功能。其次是對產品開發過程的需求：要求軟體的開發流程必須滿足某些約束條件，然後是非功能性需求：這也叫「服務質量需求」。最後是綜合需求，有些需求並不是單單乙個軟體模組就能滿足，例如，「購物**必須在24小時內把貨物傳送到使用者手中」，這個需求牽涉到軟體系統、貨物派送系統、送貨部門、監控系統等不同部門的功能和執行能力。
我的思考：我們說做需求分析的時間應該三倍於寫**的時間，可見需求分析是多麼的重要。我們需要在需求階段把很多問題定義清楚，不然寫出了**也是無效，做出的功能也是不盡人意的，從而違反了我們做軟體的初衷。
構建之法閱讀筆記05
時隔多日，自己又重拾 構建之法 今天對需求分析這部分進行了閱讀。當我們程式設計師在編寫軟體之前要做的就是了解使用者的需求，準確而全面地找到需求主要有以下幾個步驟 1 獲取和引導需求 elicitation 我們需要找到軟體的利益相關者，了解和挖掘他們對軟體的需求，引導他們表達出對軟體的需求。很多時候...
構建之法閱讀筆記05
本次閱讀了第十三 軟體測試 十四章 質量保障 在軟體發布前基本沒有進行測試，直到上台講述的之前的一段時間才發現了一些問題，甚是著急 第十三章中excel計算1900閏年錯誤的例子給了我乙個全新的概念 要服務於最主要的功能.傳說中的拐點 小飛 我聽說在軟體專案中，有這樣乙個拐點存在 在這一點之前，新的...
構建之法閱讀筆記05
這是構建之法的最後一篇閱讀筆記 這幾天主要閱讀了it的創新這一章，創新在現代的社會中是乙個被說爛了的詞語，各行各業都在提倡創新，就連學校裡也在提倡什麼創新創業大賽 在 構建之法 的創新迷思一節，列舉出了七個迷思，接下來分別作出乙個簡要的概述。迷思之一 偉大的創新總是靈光一現。迷思之二 大家都喜歡創新...