《掌握需求過程》學習筆記

2021-05-05 03:58:15 字數 2768 閱讀 8414

這幾天讀了

suzanne robertson,james robertson

的《掌握需求過程》,本書用乙個接乙個的步驟、乙個接乙個的模板、乙個接乙個的例子,向我們展示了乙個經過業界檢驗的需求收集和驗證過程。

從專案啟動、專案計畫、專案實施、專案監控、專案結束主線角度描述了需求的目標與範圍;需求規格說明書模版與需求框架

;需求收集;通過需求原型獲取更多、豐富的需求並發現遺漏需求;需求驗證;需求管理、需求跟蹤、需求事後經驗總結。 一、

volere

需求規格說明書模版與需求框架

分類內容產品

現在條件

1、產品的目標——構建產品的原因和如果使用了該產品能帶給業務的優勢。

2、客戶、顧客和其他的風險承擔者——產品涉及他們的利益。

3、產品的使用者——預期的終端使用者,以及他們的水平對產品可用性的影響。

4、需求限制條件——專案的侷限性和產品設計的限制條件。

5、命名標準和定義——產品相關的詞彙表。

6、相關事實——對產品產生一定影響的外部因素。

7、假定——開發者所做的假定。功能

性需求8、

產品的範圍——定義產品的邊界,以及它與相鄰系統的連線情況。

9、功能與資料需求——產品必須做的事情和功能進行的資料操作。非功

能性需求

10、觀感需求——預期的外觀

11、易用性需求——基於預期使用者的操作水平作出。

12、操作需求——產品預期的操作環境。

13、效能需求——多快、多大、多精確、多安全、多可靠等。

14、可維護性和可移植性需求——產品的可改動性必須達到什麼水平。

15、安全性需求——產品的安全性、保密性和完整性。

16、文化與政策需求——人的因素。

17、法律需求——滿足適用的法律。專案

問題18、開放式問題——那些尚未解決的問題,可能對專案的成功有影響。

19、商業上架式軟體解決方案——利用已有的元件而不是從頭開發。

20、新問題——因為引入新產品而帶來的問題。

21、任務——將產品生產出來必須要做的一些事情。

22、遷移——從現存系統轉換的任務。

23、風險——專案最有可能面對的風險。

24、費用——早期對構建產品的成本或工作量的估計。

25、使用者文件——建立使用者指南和文件的計畫。

26、後續版本需求——可能在產品將來的發行版本中包括的需求。

二、需求收集

確定根本需求,將需求與解決方案分離,理解系統的真正目標。

做使用者的學徒,揭示有意識和無意識的需求,如果使用者因為「太忙」而無法交談,這種方法很有用。

業務事件研討會,產生業務規則與目標。

頭腦風暴,召集一組聰明的、有意願的、不同學科背景、不同經驗的人,讓他們對新產品產生盡可能多的想法。

用錄影記錄使用者和需求分析師參加的研討會和頭腦風暴的過程,錄影的作用有:記錄、確認、備忘。

通過網路查詢技術,可以收集需求的相關線索。

使用者訪談與問卷調查。

網羅知識

三、需求原型

低保真原型是一種快速模擬產品的方式,使用熟悉的技術,諸如筆、紙、白板等。低保真原型有助於將注意力集中在產品做什麼上,而不是產品看起來如何,他們有助於發現遺漏的功能和測試產品的範圍。

高保真原型使用做原型的工具來給出非常真實的外觀,他們對於發現易用性需求是特別有效的。

場景模型是一項是抽象主題變得生動的技巧,它通過對乙個特定例項講故事的方式來做到這一點。這些模型能有效地幫助人們將注意力集中在細節上,並發現其他情況可能會遺漏的異常。

四、需求驗證

方面驗收判斷標準

功能性需求

確保功能被正確地執行

非功能性需求

量化度量,引入該產品的

3個月之內,

60%的使用者將用它來完整規定的工作。在這些使用者之中,將有

75%對產品表示讚許。

客戶詢問客戶乙個關鍵問題來確定,這個問題是:「什麼會被認為是滿足需求失敗?」。

測試產品將不會讓測試組的

80%的人感覺到被冒犯。

觀感需求

介面的相容性作為驗收標準

易用性需求

經過一天培訓之後,

10個使用者中有

9個能夠成功地完成選擇的任務。

效能需求

在95%

的情況下,響應時間將不超過

1.5秒,在其他情況下不超過4秒。

可操作性需求

對要求的環境下使用是否容易或使用是否成功的量化標準。

可維護性需求

新的使用者將能被加入系統,並且對現存使用者的打斷不超過

5分鐘。

安全性需求

產品的資料必須與資料的權威**保持一致。

文化和政策需求

基於誰將認證產品是可接受的。

法律需求

法律部門

/公司的律師將認證產品符合相關法律。

用例需求

所有相關需求的意圖的總和。

限制條件度量

五、需求管理

需求跟蹤、需求變更、版本控制

需求事後分析,總結經驗,從成功中獲益並避免導致失敗的失誤。

六、需求開發過程

對收集、提取、編寫和檢查需求的過程進行剪裁,讓這些過程能適應您的技術與文化環境。

需求中可以包含技術元素,但不能包含技術實現。

「chattres

的bernard

曾說過,我們就像站在巨人肩膀上的侏儒,所有我們比巨人看得更多,看得更遠,這不是因為我們的眼光銳利,也不是因為我們的身體有什麼特別,而是因為我們被巨人的身軀托舉得很高。」——

john of salisbury

掌握過程需求

今日閱讀了 掌握需求過程 這本書,書中從基本事實 需求過程 確定業務問題的範圍 業務用例 工作調研 場景 理解真正的問題 開始解決方案 今日業務分析策略,功能需求 非功能需求 驗收標準和理由 質量關 需求與迭代開發 復用需求 溝通需求 需求完整性十七個方面對於需求過程進行詳細講解。目前讀到第四章,先...

掌握需求過程筆記 專案啟動

volere 過程模型 第一項活動 專案啟動 定義 專案啟動確定了工作領域的邊界,產品將成為其中的一部分,同時也確定了產品要實現的目標。它也確定了利益相關者,即對產品的成功感興趣的人。專案啟動的其他提交產物確定了專案的可行性,並作為後續需求發現活動的輸入資訊。提交的產物 專案的目標 一段簡短的 定量...

《掌握需求過程》 閱讀筆記03

為了找出對專案我們真正知道什麼,開始對專案盡早進行度量,我開始了對 專案啟動 的閱讀。專案啟動是一項突發性的活動,通過這個活動收集讓專案啟動所需的各種資訊,啟動階段確定產品作為其一部分的工作,並確定產品要實現的準確目標。通過icebreaker專案更好的展示了需求過程,這一部分老師在課堂上也重點講到...