專案管理 怎樣做需求分析(一)

2021-04-20 22:31:23 字數 1910 閱讀 1778

如果將需求分析階段的工作歸結為編寫需求規格說明書,這種簡化的做法往往是導致專案後期層出不窮問題的罪魁禍首。建議採用以下步驟形成軟體需求:獲取使用者 需求→分析使用者需求→編寫需求文件→評審需求文件→管理需求。下面我們先來討論前兩個步驟(獲取使用者需求、分析使用者需求)的做法。

獲取使用者需求

這是該階段的乙個最重要的任務。以下為獲取使用者需求需要執行的活動(如圖1所示)。

● 了解客戶方的所有使用者型別以及潛在的型別。然後,根據他們的要求來確定系統的整體目標和系統的工作範圍。

● 對使用者進行訪談和調研。交流的方式可以是會議、**、電子郵件、小組討論、模擬演示等不同形式。需要注意的是,每一次交流一定要有記錄,對於交流的結果還 可以進行分類,便於後續的分析活動。例如,可以將需求細分為功能需求、非功能需求(如響應時間、平均無故障工作時間、自動恢復時間等)、環境限制、設計約 束等型別。

⑴對於使用者提出的每個需求都要知道「為什麼」,並判斷使用者提出的需求是否有充足的理由;

圖1 獲取使用者需求的活動

⑵將那種以「如何實現」的表述方式轉換為「實現什麼」的方式,因為需求分析階段關注的目標是「做什麼」,而不是「怎麼做」;

⑶分析由使用者需求衍生出的隱含需求,並識別使用者沒有明確提出來的隱含需求(有可能是實現使用者需求的前提條件),這一點往往容易忽略掉,經常因為對隱含需求考慮得不夠充分而引起需求變更。

⑴明確標識出那些未確定的需求項(在需求分析初期往往有很多這樣的待定項);

⑵使需求符合系統的整體目標;

⑶保證需求項之間的一致性,解決需求項之間可能存在的衝突。

分析使用者需求

在很多情形下,分析使用者需求是與獲取使用者需求並行的,主要通過建立模型的方式來描述使用者的需求,為客戶、使用者、開發方等不同參與方提供乙個交流的渠道。 這些模型是對需求的抽象,以視覺化的方式提供乙個易於溝通的橋梁。使用者需求的分析與獲取使用者需求有著相似的步驟,區別在於分析使用者需求時使用模型來描述, 以獲取使用者更明確的需求。分析使用者需求需要執行下列活動:

● 以圖形表示的方式描述系統的整體結構,包括系統的邊界與介面;

● 通過原型、頁面流或其它方式向使用者提供視覺化的介面,使用者可以對需求做出自己的評價;

● 系統可行性分析,需求實現的技術可行性、環境分析、費用分析、時間分析等;

● 以模型描述系統的功能項、資料實體、外部實體、實體之間的關係、實體之間的狀態轉換等方面的內容。

圖2 dfd示意圖

用於需求建模的方法有很多種,最常用的包括資料流圖(dfd)、實體關係圖(erd)和用例圖(use case)三種方式。dfd作為結構化系統分析與設計的主要方法,已經得到了廣泛的應用,dfd尤其適用於mis系統的表述。dfd使用四種基本元素來描 述系統的行為,過程、實體、資料流和資料儲存。dfd方法直觀易懂,使用者可以方便地得到系統的邏輯模型和物理模型,但是從dfd圖中無法判斷活動的時序 關係。圖2描述的是某個專案的dfd示意圖。

erd方法用於描述系統實體間的對應關係,需求分析階段使用erd描述系統中實體的邏 輯關係,在設計階段則使用erd描述物理表之間的關係。需求分析階段使用erd來描述現實世界中的物件。erd只關注系統中資料間的關係,而缺乏對系統功 能的描述。如果將erd與dfd兩種方法相結合,則可以更準確地描述系統的需求。

在物件導向分析的方法中通常使用use case來獲取軟體的需求。use case通過描述「系統」和「活動者」之間的互動來描述系統的行為。通過分解系統目標,use case描述活動者為了實現這些目標而執行的所有步驟。use case方法最主要的優點,在於它是使用者導向的,使用者可以根據自己所對應的use case來不斷細化自己的需求。此外,使用use case還可以方便地得到系統功能的測試用例。

專案管理 怎樣做需求分析(二)

自 http mypm.net articles show article content.asp?articleid 5369 1 編寫需求文件 需求文件可以使用自然語言或形式化語言來描述,還可以新增圖形的表述方式和模型表徵的方式。需求文件應該包括使用者的所有需求 功能性需求和非功能性需求 2 評...

怎樣做需求分析

如果將需求分析階段的工作歸結為編寫需求規格說明書,這種簡化的做法往往是導致專案後期層出不窮問題的罪魁禍首。建議採用以下步驟形成軟體需求 獲取使用者需求 分析使用者需求 編寫需求文件 評審需求文件 管理需求。下面我們先來討論前兩個步驟 獲取使用者需求 分析使用者需求 的做法。獲取使用者需求 這是該階段...

怎樣做需求分析

如果將需求分析階段的工作歸結為編寫需求規格說明書,這種簡化的做法往往是導致專案後期層出不窮問題的罪魁禍首。建議採用以下步驟形成軟體需求 獲取使用者需求 分析使用者需求 編寫需求文件 評審需求文件 管理需求。下面我們先來討論前兩個步驟 獲取使用者需求 分析使用者需求 的做法。獲取使用者需求 這是該階段...