① 軟體需求分析
需求分析就是對客戶提出的「要求」或者「需求」進行深入細致地調研和分析,准確理解用戶和項目的功能、性能、可靠性等具體要求,將用戶非形式的需求表述轉化為完整的需求定義,從而確定系統必須做什麼,為系統設計、系統完善和系統維護提供依據。
需求分析是項目計劃階段非常重要的環節,該環節決定了需要「實現什麼」,為下一步如何去「實現」提供了明確的方向。
進行需求分析需要做到以下幾點:
(一)需求獲取:在准備階段,我們首先要確定需求獲取的目標及范圍,根據你的目標來選擇對應的方式獲取需求。
(二)需求分類:一般情況下,我們會根據對象的不同,將需求分為業務需求、用戶需求、功能需求等。
(三)需求篩選:有些需求是偽需求,有些需求則不具備實現價值,我們可以通過真實性、價值性、可行性三個維度來篩選需求,過濾掉虛假的、不可行的、沒有價值、價值不大或投入產出比不理想的需求。
(四)需求提煉:對剩下的需求進行提煉,目的在於從獲取的表面需求中提煉出客戶的本質需求。找出「為什麼要做」比「做什麼」更重要。
(五)需求優先順序排序:挖掘到客戶的真實目的後,我們需要根據不同維度的需求歸類方法,如KANO模型分析法、投入產出比ROI等,對其進行歸納整理並排出優先順序,幫助產品有條理地安排開發秩序,避免盲目排序。
(六)產出需求文檔:通過以上的分析,我們需要將收集到的需求進行分析、匯總、歸類,輸出產出需求文檔,為接下來的工作做好鋪墊。
以上是對需求分析的一些理解和思路,做好需求分析工作之後,就可以對可實現的需求進行落地方案的跟進。
② 軟體工程:3.需求分析
需求分析的任務就是准確地回答「 系統必須做什麼 」。是通過系統分析員與用戶一起商定,清晰、准確、具體地描述軟體產品必須具有的 功能 、 性能 、 運行環境 等要求。
用戶:知道做什麼,不知道怎麼做。
開發人員:知道怎麼做,不知道做什麼。
因此,系統分析員必須和用戶密切配合、充分交流信息,得出經過用戶認可的系統需求。
需求分析的目的是澄清用戶的需求,並把雙方共同的理解明確地表達成一份書面文檔—— 需求規格說明書 。
需求分析是一項軟體工程活動,它包括: 需求獲取 、 需求建模 、 需求規格說明 、 需求評審 。
需求分析模型 是准確地描述需求的圖形化工具,主要有 實體關系圖 、 數據流圖 、 狀態轉換圖 。需求分析建立起來的模型為日後軟體設計人員提供了可被翻譯成 數據結構 、 體系結構 、 介面 和 處理過程 設計的模型。
如上圖所示,目標系統模型的建立過程分 4 步完成:
把分析的結果用正式的文檔記錄下來,作為最終軟體配置的一個組成成分。需求規格說明為開發人員和用戶提供軟體開發完成時質量評價的依據。
作為需求分析階段的復審手段,在需求分析的最後一步應該對功能的正確性、完整性和清晰性以及其他需求給予評價。
需求分析研究的對象是 用戶的要求 。必須 全面理解 用戶的各項要求, 准確表達 用戶的要求。只有經過確切描述的軟體需求才能成為軟體設計的基礎。
評審應由專人負責,評審組由軟體開發成員、軟體專家、領域專家和用戶構成。
需求分析是一個不斷的迭代過程。只有需求全面,准確無誤,才能開發出用戶滿意的系統。
需求獲取是軟體開發工作中最重要的環節之一,其工作質量對整個軟體系統開發的成敗具有決定性影響。需求獲取工作量大,所涉及的過程、人員、數據、信息非常多,因此要想獲得真實、全面的需求必須要有正確的方法。常規的需求獲取的方法有以下幾種:
需求分析模型 是准確地描述系統需求的圖形化工具。它可以使人們更好地理解將要建造的系統,它有助於系統分析員理解系統的信息、功能和行為,成為確定需求規格說明完整性、一致性和精確性的重要依據,奠定軟體設計基礎。
需求分析建模的方法有 結構化分析建模 和 面向對象分析建模 。
結構化分析導出的分析模型包括 數據模型 、 功能模型 和 行為模型 。
需求分析模型以「 數據字典 」為核心,描述了軟體使用的所有數據對象,圍繞這個核心的是「 實體關系圖 」、「 數據流圖 」和「 狀態轉換圖 」。
具體形式如下圖所示:
實體關系圖(ER,Entity-Relationship Diagram) :是一種數據模型,是以實體、關系、屬性三個基本概念概括數據的基本結構,從而描述 靜態數據結構 的概念模型。
ER 包括三種基本元素:
關聯的重數 定義了在關聯的一端可以存在的數據實體實例的數量。 關聯重數可以具有下列值之一:
兩個數據對象之間按關聯的重數有以下三種關聯:
以下實體關系圖描述的是教師、課程、學生三者之間的關系。
以下實體關系圖描述的是出勤、職工、獎金、扣款之間的關系。
數據流圖(DFD,Data flow diagram) ,是描述數據流和數據轉換的圖形工具,它是進行結構化分析的基本工具,也是進行軟體體系結構設計的基礎。
DFD 有四種元素,其基本符號如圖所示:
示例,工資計算系統的頂層(0層)數據流圖:
在數據流圖中有時也使用 附加符號 : * 、 + 、 ⊕ ,分別表示與、或、互斥關系。
數據流圖可分為不同層次,頂層(0層)DFD 稱為 基本系統模型 ,可以將整個軟體系統表示為一個具有輸入和輸出的黑匣子,其加工處理是 軟體項目的名稱 ,用一個圓圈表示。
DFD 中的每一個加工可以進一步擴展成一個獨立的數據流圖,以揭示系統中加工的細節。這種循序漸進的細化過程可以繼續進行,直到最底層的 DFD 圖僅描述加工的 原子過程 為止。每一層數據流圖必須與它上一層數據流圖的輸入輸出保持平衡和一致。
數據流圖是在需求陳述的基礎上繪制的。
這個數據流圖只是一個高層的系統邏輯模型,它反映了目標系統要實現的功能。
第二層數據流圖——銷售細化:
第二層數據流圖——采購細化:
當軟體系統涉及 時序關系 時需要進行 行為建模 ,由於數據流圖不描述時序關系,系統的控制和事件流需要通過行為模型來描述。
在描述系統或各個數據對象的行為時,採用 狀態轉換圖 。通過描述系統或對象的 狀態 ,以及引起系統或對象狀態轉換的 事件 來表示系統或對象的行為。
狀態轉換圖(STD,Status Transition Diagram) ,是描述系統狀態如何響應外部事件進行轉移的一種圖形表示。
狀態 是任何可以被觀察到的系統行為模式,一個狀態代表系統的一種行為模式。狀態規定了系統對事件的響應方式。在狀態圖中定義的狀態主要有: 初始狀態 、 中間狀態 和 最終狀態 。
事件 是在某個特定時刻發生的事情,它是對引起系統從一個狀態轉換到另一個狀態的外界事件的抽象。
在狀態轉換圖中,圓圈「○」表示可得到的 系統狀態 ,箭頭「→」表示從一種狀態向另一種 狀態的轉移 。箭頭旁標上 事件名 。
數據字典(DD,Data Dictionary) 用來描述數據流圖中的數據存儲、數據加工和數據流。 數據字典與數據流圖配合,能夠准確、清晰地表達數據處理的要求。
對於在數據流圖中每一個被命名的圖形元素均加以定義 ,其內容有: 名字、別名或編號、分類、描述、定義、位置、其它。
在數據字典中,數據元素的定義可以是基本元素及其組合,數據進行自頂向下地分解,直到不需要進一步解釋且參與人員都清楚其含義為止。
數據流定義實例:航班訂票單的數據定義
數據元素定義實例:考試成績的數據定義
數據文件定義實例:圖書庫存的數據定義
數據處理定義實例:編輯訂票的數據定義
外部實體定義實例:教師的數據定義
存摺=戶名+所號+帳號+開戶日+性質+(印密)+1{存取行}50
戶名=2{字母}24
所號=「001」..「999」
帳號=「00000001」..「99999999」
開戶日=年+月+日
性質=「1」..「6」 註:「1」表示普通戶,「5」表示工資戶等
印密=「0」 註:印密在存摺上不顯示
存取行=日期+(摘要)+支出+存入+余額+操作+復核
需求規格說明書(SRS,Software Requirement Specification) ,是系統分析人員在需求分析階段完成的文檔,是軟體需求分析的最終結果。
它的 作用 主要是: 作為軟體人員與用戶之間事實上的技術合同;作為軟體人員下一步進行設計和編碼的基礎;作為測試和驗收的依據 。
SRS 必須用統一格式的文檔進行描述。為了使需求分析描述具有統一的風格,可以採用已有的且能滿足項目需要的模板,如中國國家標准推薦的SRS模板,也可以根據項目特點和軟體開發小組的特點對標准進行適當的改動,形成自己的模板。