功能需求分析方法

『壹』 如何進行軟體需求分析

軟體需求分析免費下載

鏈接:https://pan..com/s/1qNBwqvbRS5ziBSIeanLQAQ

需求分析也稱為軟體需求分析、系統需求分析或需求分析工程等，是開發人員經過深入細致的調研和分析，准確理解用戶和項目的功能、性能、可靠性等具體要求，將用戶非形式的需求表述轉化為完整的需求定義，從而確定系統必須做什麼的過程。

『貳』 需求分析的步驟有哪些

一、需求識別
需求人員在此步驟應該分析需求類別、需求復雜度和需求價值用來確定需求實施的優先順序。

1.需求類別確認：

需求類別包含流程類需求、統計分析類需求、介面類需求，一個需求可能為某一類型需求，也可能包含多類需求。

確認需求類別後應對每類需求的數量進行初步分析（比如流程類需求包含幾個流程、統計分析類需求包含幾個報表、介面類需求包含幾個介面）。

2.需求復雜度分析：

一般需求受理工作量在1-5人天的需求復雜度低，工作量在5-15人天的需求復雜度中，工作量在15人天以上需求復雜度高。（工作量表示需求受理全過程需求人員需要付出的工作量）。

3.價值分析：

需求人員收到需求後應根據收集需求內容初步分析需求痛點/目標、需求復雜度、業務重要程度確定需求價值，需求價值分析
二、業務流程/統計查詢/介面分析
針對流程類需求必須進行業務流程分析，統計查詢和介面類需求可不進行詳細的流程分析。

1.業務流程分為部門級、組織級和崗位級

部門級流程關注脈絡需要分析涉及哪些具體崗位、執行活動、每個活動之間的關聯關系，它是需求分析的主線條，也是流程分析的主要產物。
組織級流程關注宏觀一般不會直接繪制，是對部門級流程的概括和抽象。
崗位級流程關注每個業務活動的執行步驟屬需求細節范疇，在流程分析階段不要過度進入細節。
2.需求識別階段確認的流程均為部門級流程

需求人員在進行流程分析應遵循如下方法：

（1）業務流程確認：

一個流程為一個業務事件，一般是外部角色發起或系統內部主動發起（比如時間事件或狀態事件），發起後會觸發一系列業務活動。

（2）角色及業務活動確認：

流程圖中的每個泳道都必須對應到角色，每個角色對應多個業務活動。需求人員在確認業務活動時一定要保證活動的粒度，一個業務活動一定是由一個角色完成且每個業務活動都是有價值的活動。

比如項目輸入項目名稱是一個執行步驟，這個動作沒有價值，項目經理查詢項目信息就是一個業務活動。

在需求描述時針對線下活動或新增活動應該應標識區分。

（3）業務活動間關系及數據確認：

確定所有業務活動的前後置關系，並明確流程間的傳遞的數據實體。

（4）流程整體瓶頸分析：

一般若某個角色業務活動工作量較大，或流程涉及高級領導，一般都會造成瓶頸，這種情況需求人員應想辦法分散工作量提出流程優化建議。

3.針對統計查詢類需求及介面類需求，按照上述業務活動確定原則分析、確定角色，並明確每個角色所執行的業務活動即可。

三、數據實體分析
針對流程類需求需要分析各業務活動傳遞的數據實體，統計分析類需求需要分析統計查詢條件和查詢展現兩類數據實體、介面類需求需要分析介面傳遞數據實體，具體分析包含如下內容：

1.明確數據實體：

確認需要分析的所有數據實體，明確哪些為系統原有實體、哪些為新增實體、哪些為改造實體。

2.明確所有數據實體間關系：

實體間關系包含（1對1、1對多、多對多），另外需要分析數據實體變更是否需要保留版本，實體刪除（邏輯刪除、物理刪除）是否影響其它數據實體。

3.明確數據實體欄位：

針對新增數據或改造數據實體需要明確新增欄位的名稱、欄位類型、是否必填、欄位取值方式（人工輸入、系統自動繼承自其它數據實體、系統自動計算需要明確計算公式）。

4.數據許可權分析：

需要分析不同角色在數據許可權方面的差異，若涉及縱向多級用戶，要說明對於集團/省/地市用戶的數據隔離。

四、角色及使用場景分析
一般來說每個業務活動是對用戶使用場景的抽象，每個業務活動可能包含多個場景，分析使用場景時應按照業務活動為主線逐個進行分析，每個業務活動分析時應包含如下內容：

1.明確活動執行角色。

2.明確活動執行的前置條件和後置條件。

3.明確不同場景：

一個業務活動可能包含正常的使用場景、備選使用場景和異常使用場景；

4.明確每個場景的執行步驟：

描述執行步驟時應使用簡單的語法，主語明確語義易於理解，每個步驟不應該在任何一方（執行角色、系統）停留兩部以上，重點描述如何交互。

5.業務規則和約束：

明確在每個業務活動下應遵循的業務規則和約束，這里一般是與業務流程相關的行為規則（比如項目周期時長超過90天必須提交二級領導審批），或與數據實體相關的數據規則（需求交接單拒收時候必須填寫拒收原因，且拒收原因不能超過500字）。

五、系統功能分析

『叄』 需求分析的方法

原型法：獲取一組基本需求之後，快速構造出一個能夠反映客戶需求的初始系統原型。

讓用戶看到未來系統的概貌，以便判斷哪些功能是符合要求的，哪些還需要改進。

按照信息的流向、結構和內容三個方面將現有的需求分析建模方法劃分為結構化分析方法，Jackson分析方法和面向對象分析方法。

通過E-R圖提供表示實體、屬性和聯系的方法，描述顯示世界中的概念模型，不涉及這些實體在系統中的實現方法。

通過數據流圖描述邏輯模型，表示數據在系統內的變化；分層表示信息流和功能的細節。

行為建模採用動態分析方法，直觀地分析系統的動作，最常用的動態分析方法包括狀態遷移圖，時序圖和Petri網。

狀態遷移圖通過描述狀態以及導致系統改變狀態的事件來表示系統的行為，指明了系統如何在狀態間移動。

『肆』 軟體工程中常用的需求分析的方法有哪些

一、過濾需求的方法
做後端系統，要學會的第一個技能就是砍需求。也就是過濾需求。

這不是一個貶義詞，反而是體現後端產品價值判斷的基礎。

過濾需求的方法，就是通過一定的手段判斷需求是否是偽需求，應該被過濾掉。

1. 用戶場景模擬法
後端產品的出發點就是幫助業務用戶，因此在調研需求的時候要模擬業務的場景，分析業務用戶提到的需求是否能解決他的問題。

如果不能幫助用戶，那麼這個需求就可能是偽需求。

以下面的案例說明：

背景：「貨到付款」類型的訂單會因為缺貨而無法發出，如果超過一定的時間，客服就會跟顧客溝通，幫顧客取消訂單。

需求：由於這種訂單的數量還是蠻多的，逐個取消太費時間，因此業務用戶要求在「缺貨訂單」列表頁增加「批量取消訂單」按鈕。

分析：調研到業務操作場景,是先找到該類缺貨訂單，然後和顧客溝通，顧客同意刪除，才進行刪除。也就是逐個溝通確認，再逐個取消訂單的，所以「批量取消訂單」無法被有效使用。

因此，該需求是個偽需求，應該被過濾掉。

2. 功能歸屬分析
專門的系統做專職功能，有助於合理的產品體系建設。

因此需求調研的時候，可以通過系統的定位，判斷需求是否應該在該系統完成。

如果不屬於該系統范疇，那麼直接說服需求方更換方案。以

下面的案例說明：

背景：CRM系統（顧客關系管理系統）有一個顧客標簽生成功能，就是根據顧客的消費行為數據，自動對應關聯上標簽，如優質顧客、高潛力顧客、欺詐顧客等。

需求：業務用戶提出需求，除了做上述的基礎標簽之外，還要做出英語版本的標簽（就是把標簽文案翻譯成英文），這樣歐美員工可以在英語版本的系統下使用。

分析：調研到翻譯之後的標簽不是在CRM系統使用的，而是給到SMS（客服系統）使用的。

所以應該由SMS根據CMS提供的基礎標簽數據，自己做二次的衍生。

之所以這樣，首先是為了避免未來更多語言版本的擴展需求或更多系統提出類似的需求；

其次，CRM系統已經完成了「接力賽」的第一棒，創造了基礎數據，那麼其他系統要特殊化使用，完全可以自行進行特殊化處理，無需耦合回CRM系統。

結論：案例的需求本身是真需求，並且實現上也沒難度，但是該功能的定位超出了本系統范疇，專門系統做專職功能，化衍生需求應該在下游執行。

否則，耦合性過高只會增加系統的復雜程度，難以維護和擴展。

二、拆分和聚合的方法
1. 拆分需求法
業務用戶提出一個需求，很可能只是短短的一段話。

但是不要高興太早，可能這一句話暗含了很多線索，因此要善於拆分：

先找他要解決的核心問題，再圍繞核心點，理清前、後、左、右、上、下的旁系需求點。

每個需求點再當做一個子需求進行調研，最後再聚合在一起。

以下面的案例說明：

背景：訂單業務的類型很多，訂單退貨之後需要創建售後單據，但是因為數量大，所以花費很多人力，且手動創建有出錯的風險。

需求：業務提出的需求是「增加退貨訂單自動創建售後單的功能」，這是個一句話需求。

該一句話需求，其實包含了多種具體的訂單類型和場景，那麼我們就要拆分調研，拆分的維度比如：

自營訂單、第三方訂單、貨到付款訂單、先款後貨訂單、部分退貨訂單、完全退貨訂單、服裝事業部訂單、電子事業部訂單等，其中每一個維度就相當於一個小需求。

這里不一一展開。

2. 聚合需求法
拆分法是對單個需求分解成若干小需求進行調研，聚合法相反，是找到許多個相互關聯的小需求的共性，然後統籌成一個大需求去完成。例如：

由於業務用戶分散在不同的部門，各自為政，於是張三、李四可能都對一個業務流程有相同的需求，或者對同一個功能有相同的優化期望，結果倆人分別提了需求過來。那麼產品經理就要找到二者背後的相關性和交叉區。

然後統籌規劃，聚合在一起當作一個需求來調研，最終輸出一個整體的需求調研結果。

三、利用輔助功能調研需求
調研產品現有功能，可以用來確認原有功能的邏輯，或者確定新需求方案是否可行。

比如業務用戶需要更新一個功能，為了避免更新出錯或遺漏，產品經理需要知道修改前和修改後是否會能正常運行。

最基礎的辦法就是自己設計一個測試用例，記錄操作方式、狀態變化、數據流向等。看看下面的例子：

背景：從銷售網站獲取到OMS系統（訂單管理系統）的訂單信息中帶著顧客的郵箱。顧客下完單，可能會在銷售網站修改郵箱，而此時已經獲取到OMS的歷史訂單中的郵箱是不變的。

需求：顧客若在銷售網站修改郵箱，要求已獲取到OMS的該顧客的訂單中的郵箱也要同步修改。

分析：需求是很明白的，也有它的意義，但有風險。

因為我們知道訂單信息貫穿於整個訂單流轉過程中，牽扯到訂單編輯、審核、取消、配貨、發貨等，而這些環節跳轉的觸發條件可能就是某個信息更新（這裡面就可能包括有郵箱更新）。

因此，更新郵箱是否會影響流程中的某些環節，一時間很難准確知道。

於是，我們可以採用預測試的方式，設計測試用例，在測試機運行一些訂單，觀察各個環節郵箱變更的影響，然後收集起來分析對策。

測試法就像是探雷一樣，主要用來解決未知風險點。這個方式的重點是記錄和分析操作前狀態、操作位點、操作後狀態、操作後觸發的連鎖反應、數據流向等。

四、「拔蘿卜帶出泥」的方式調研需求
調研需求時，產品經理要拔蘿卜帶出泥,挖掘用戶沒看到的需求點和價值。

舉例說明：

背景：公司入駐到銷售平台後，銷售平台會對入駐的店鋪的違規行為進行罰款。

需求：業務用戶提出需求，將銷售平台的罰款數據抓取到訂單系統，關聯訂單數據，以便進行人工分析。

分析：

第一步，先拆分需求，確定什麼是罰款數據，總共有哪些罰款種類，需要對接哪些罰款種類，罰款數據與訂單系統關聯方式是什麼，是否都能關聯到，關聯不到怎麼辦，銷售平台是否已經提供了公用的罰款介面，Token（請求許可權）如何獲取，抓取頻率怎麼樣，數據增長幅度多大，獲取之後做哪些展示和搜索，用戶許可權怎麼設置，需要和訂單系統做哪些交互，該需求的價值是什麼……

第二步，挖掘需求：是否需要作分析功能，分析功能的規則是什麼；是否需要做監控和預警，是否需要指派負責人；其他業務人員是否也有類似需求，其他平台是否也有類似需求……

通過「拔蘿卜帶出泥」的方式，連帶出更多需求點。將上述調研結果重新組裝起來，得到一個系統化的完整需求。

羅列出需求要點和對應的驗收目標，這樣使得需求具象化，同時又不會遺漏細節，內部充實，外部閉環，並且進行了價值挖掘，做成控制閾值、預警、責任人分派、趨勢分析、損失分析等高價值的功能，超出業務的預期。

『伍』 需求分析常用方法

行為事件分析

行為事件分析是根據運營關鍵指標對用戶特定事件進行分析。通過追蹤或記錄用戶行為事件，可以快速的了解到事件的趨勢走向和用戶的完成情況。

以用戶投標的行為事件為例，出借人在完成投標過程中，所進行的注冊、認證、開戶、充值、投資等行為，都可以定義為事件，也是完成投標成功的一個完整事件。
確定投標行為事件後，我們可以根據事件屬性細分維度：用戶來源、性別、出生年月、注冊時間、綁卡時間、首次充值時間、首次投資時間、標的ID，標名、期限、利率、還款方式等。然後從中找出符合指標的規律，並制定針對性的措施。

用戶留存分析

用戶留存分析是一種用來分析用戶參與情況與活躍程度的模型。通過留存量和留存率，可以了解用戶的留存和流失狀況。比如用次日留存、周留存、月留存等指標來衡量產品的人氣或粘度。以渠道訪問的用戶留存為例，我們對APP端有過訪問行為的渠道用戶進行留存分析。用戶留存一般符合40-20-10法則，即新用戶的次日留存應該大於40%，周留存大於20%，月留存大於10%才符合業務標准。我們做用戶留存分析主要驗證是否達到既定的運營目標，進而影響下一步的產品決策。

漏斗模型分析

漏斗模型分析是用戶在使用產品過程中，描述各個階段中關鍵環節的用戶轉化和流失率情況。比如在日常活動運營中，通過確定各個環節的流失率，分析用戶怎麼流失、為什麼流失、在哪裡流失。找到需要改進的環節，要重點關注，並採取有效的措施來提升整體轉化率。

邀請人將活動專題頁分享給好友，之後進行的注冊、認證、開戶、充值到投資，用漏斗模型分析一些關鍵節點的轉化率。其中用戶注冊轉化率為68%，實名認證轉化率為45%，綁卡開戶轉化率為29%，線上充值轉化率為17%，投資標的轉化率為8%。
漏斗模型分析可以驗證整個流程的設計是否合理。經過對比發現，訪問到注冊的轉化率為68%，遠低於預期的80%。這次運營策略是用戶必須先注冊才能領取新手福利。之後採取A/B測試的方式，優化為先領取新手福利再誘導用戶注冊。經過數據對比分析，注冊轉化率提升了20%。因此，通過對各環節相關轉化率的比較，可以發現運營活動中哪些環節的轉化率沒有達到預期指標，從而發現問題所在，並找到優化方向。

行為路徑分析

行為路徑分析就是分析用戶在產品使用過程中的訪問路徑。通過對行為路徑的數據分析，可以發現用戶最常用的功能和使用路徑。並從頁面的多維度分析，追蹤用戶轉化路徑，提升產品用戶體驗。

不管是產品冷啟動，還是日常活動營銷，做行為路徑分析首先要梳理用戶行為軌跡。用戶行為軌跡包括認知、熟悉、試用、使用到忠誠等。軌跡背後反映的是用戶特徵，這些特徵對產品運營有重要的參考價值。我們可以記錄用戶從注冊、認證、開戶、充值到投資的行為軌跡。通過分析用戶的這些行為軌跡數據，來驗證訪問路徑是否和預期指標的一致。

『陸』 需求分析常用方法都有哪些，請舉例說明

問卷調查法，是指設計方就用戶需求中的一些個性化的、需要進一步明確的需求或問題，通過採用向用戶問卷調查表的方式，達到徹底弄清項目需求的一種需求獲取方法。 這種方法適合於設計方和建設方、使用方都清楚項目需求的情況。因為建設方和使用方都清楚項目的需求，需要雙方進一步溝通的需求或問題就比較少，通過採用這種簡單的問卷調查方法就能使問題得到較好的解決。顯然對於樂百氏集團這樣規模龐大的公司，簡單的問卷調查是不能夠滿足准確獲得需求的需要的。會議討論法，是指設計方和用戶相關人員召開若干次需求討論會議，達到徹底弄清項目需求的一種需求獲取方法。這種方法適合於設計方不清楚用戶的詳細業務需求，但使用方清楚項目需求的情況。因為使用方清楚項目的需求，他們能准確地表達出他們的需求，而設計方有專業的需求，而我們有專業的軟體開發經驗，經過回憶討論交流之後，能夠對用戶的需求進行准確描述和把握。這個方法對於准確的獲得樂百氏公司的需求是一種不錯的選擇。在本案例中系統的設計人員也是這么做的，他們通過和樂百氏項目組經理的討論，很快了解了樂百氏的運作過程的數據。界面原型法，是指設計方根據自己所了解的用戶需求，描畫出應用系統的功能界面後與用戶進行交流和溝通，通過「界面原型」這一載體，達到雙方逐步明確項目需求的一種需求獲取的方法。這種方法比較適合於設計方和用戶都不是非常清楚項目需求、只是大概了解用戶需求的情況。因為設計方和用戶方都不能非常准確的描述出客戶的需求，因此此時就更需要藉助於一定的「載體」來加快對需求的挖掘和雙方對需求理解

『柒』 軟體的功能需求分析要怎麼寫

1. 引言

1.1編寫目的:編寫此文檔的目的是進一步定製軟體開發的細節問題,便於用戶與開發商協調工作.本文檔面向的讀者主要是項目委託單位的管理人員.希望能使本軟體開發工作更具體.

1.2項目背景

1.2.1項目委託單位:****公司

1.2.2開發單位:***公司

1.3定義

1.4參考資料

2. 任務概述

2.1目標:

<1> 決策支持:根據公司的要求及時提供所需報表及文件,並在適當時候對各部門領導給予銷售及進貨等方面的提示

<2>提高效率:利用軟體進行管理,避免人工管理的失誤以及 延遲性,從而實現高效率的管理.

2.2運行環境:

<1> 硬體方面:Pentium級處理晶元
1兆顯存的兼容顯卡
256色,800*600的兼容顯示器
標准兼容列印機

<2>軟體方面: WIN95操作系統

2.3條件與限制:

編程用計算機一台
完成期限2000/7/1
無資金供給

3. 數據概述

數據流程圖如下:

3.1靜態數據:包括系統登錄密碼,各資料庫所在位置,系統分析原始數據

3.2 動態數據:包括各資料庫內各項顯示數據,用戶登錄信息,系統時間

3.3資料庫描述:

人事管理資料庫:公司內人員的個人詳細信息,包括檔案信息
銷售管理資料庫:當日銷售記錄及以前的銷售統計,用於銷售分析
財務管理資料庫:公司內部賬目及收支情況詳表
技術管理資料庫:公司所需各技術檔案的詳細記錄(包括文檔)

3.4 數據字典:

<1>數據流詞條描述:

1.數據流名:登錄信息
來源:用戶的輸入
去向:系統內部檢驗部分
組成:用戶名,密碼
流通量:每次登錄輸入一次

2.數據流名:登錄結果
來源:系統
去向:用戶
組成:返回信息
流通量:每次登錄返回一次

3.數據流名:輸入修改信息
來源:用戶
去向:系統判斷部分
組成:根據各資料庫內容而不同
流通量:依用戶輸入而定

4.數據流名:反饋信息
來源:系統判斷部分
去向:用戶
組成:系統經判斷後發回的字元數據
流通量: 依系統當前信息而定

5.數據流名:識別信息
來源:系統內部檢驗部分
去向:系統判斷部分
組成:系統各資料庫的標識信息
流通量:用戶每次輸入流通一次

6.數據流名:處理信息
來源:系統判斷部分
去向:各資料庫處理部分
組成:讀取/修改標識,讀取/修改的變數名稱
流通量:用戶每次輸入流通一次

7.數據流名:讀取修改
來源:系統判斷部分
去向:系統各資料庫
組成:讀取/修改標識,讀取/修改內容
流通量: 用戶每次輸入流通一次

<2>數據文件詞條描述:

1.數據文件名:人事數據
簡述:存儲人員信息
數據文件組成:人員的各項信息(以CString類型為主)

2.數據文件名:銷售數據
簡述:存儲當日及從前的銷售記錄
數據文件組成:銷售的各項信息

3.數據文件名:財務數據
簡述:存儲財務管理信息
數據文件組成:財務管理的各項記錄

4.數據文件名:技術數據
簡述:存儲公司內部使用的技術檔案信息
數據文件組成:技術檔案名稱,內容

<3>加工邏輯詞條描述:

1.加工名:檢驗
簡要描述:判斷用戶的許可性
輸入數據流:登錄信息
輸出數據流:登錄結果
加工邏輯:判斷是否與系統內部用戶信息相符合

2.加工名:判斷
簡要描述:判斷用戶的操作並進行相應的讀取/存儲工作
輸入數據流:輸入修改信息
輸出數據流:反饋信息
加工邏輯:判斷用戶的操作->調用資料庫->讀取/修改->反饋

3.加工名:人事檔案管理
簡要描述:對人事資料庫進行相應要求的操作,並與判斷部分交互
輸入數據流:處理信息,讀取修改
輸出數據流: 讀取修改, 處理信息
加工邏輯:判斷用戶要讀取/修改的內容->反饋用戶所需信息

4.加工名:銷售統計
簡要描述:對銷售資料庫進行相應要求的操作,並與判斷部分交互
輸入數據流:處理信息,讀取修改
輸出數據流: 讀取修改, 處理信息
加工邏輯:判斷用戶要讀取/修改的內容->反饋用戶所需信息

5.加工名:財務統計
簡要描述:對財務資料庫進行相應要求的操作,並與判斷部分交互
輸入數據流:處理信息,讀取修改
輸出數據流: 讀取修改, 處理信息
加工邏輯:判斷用戶要讀取/修改的內容->反饋用戶所需信息

6.加工名:技術管理
簡要描述:對技術統計資料庫進行相應要求的操作,並與判斷部分交互信息
輸入數據流:處理信息,讀取修改
輸出數據流: 讀取修改, 處理信息
加工邏輯:判斷用戶要讀取/修改的內容->反饋用戶所需信息

<4>源點及匯點詞條描述:

名稱:用戶
簡要描述:既是源點又是匯點,發出動作信息給"檢驗"和"判斷"加工,通過交互界面接受反饋信息有關數據流:登錄結果,登錄信息,輸入修改信息,反饋信息
數目:一個

4. 功能需求

4.1功能劃分

可細分為四部分:人事管理,銷售管理,財務管理,技術檔案管理

4.2功能描述

<1>人事功能:

(1)能對公司內部的所有人員有關檔案詳細資料記錄並保存。
(2)能對資料庫內人事檔案的數據進行查閱和修改。
(3)能按部門或姓名檢索人員。
(4)當某員工的僱用期限達到整年時，按時提醒。

<2>銷售統計功能

(1)按日對公司的銷售情況進行統計,包括銷售額\銷售數量\各地區銷售比例\不同銷售方式的銷售量比例以及銷售毛利潤情況
(2)制定銷售情況的月報表\季報表以及年報表對銷售情況進行分析,對不同銷售人員的業績進行評定

<3>財務管理功能

(1)協助財務人員進行計算機管理,對庫存情況\進貨情況\銷貨進行登錄和輸出
(2) 根據預設的庫存情況提醒進貨
(3) 對收款情況進行統計,在應收帳款達到預設值時進行提示

<4>技術管理功能

(1)對技術資料進行登錄
(2)對維修記錄進行登錄和統計,按不同型號的機器進行故障整體分析,並作出分析報告
(3)對維修配件的需求進行管理並及時提示備貨

5. 性能需求

5.1數據精確度:因為此數據為公司內部數據,所以要求不能有誤差

5.2時間特性:當日銷售統計要求有即時性,馬上能反應出存貨的問題;同時財務管理數據計算當前存貨情況,並對進貨情況進行估算

5.3 適應性:此軟體只在公司內部管理人員的機器上使用,因此不考慮適應性

6. 運行需求

6.1用戶界面:

屏幕格式:

(1)要求有菜單及工具欄以方便操作
(2)各資料庫信息可在屏幕上直接修改
(3)各數據統計結果可在屏幕上顯示
(4)進行系統分析後的結果在另一窗口中顯示

報表格式:

(1)人事管理報表只要求有個人的普通數據
(2)銷售統計報表要求可分別列印當日統計或之前的統計
(3)財務統計報表要求列印出存貨及公司帳務詳表
(4)技術管理報表要求可以分別列印技術檔案總表和任一技術檔案文檔內容菜單格式:要求菜單項大致與WIN95標准相同,另外附加的功能做到新的單項中輸入輸出時間:年份以4位數字表示

6.2硬體介面:需要標准列印機介面進行報表列印

6.3 軟體介面:Windows標准介面

7. 其他需求

可使用性:要求容易使用,界面友好

安全保密性:因本數據屬於公司內部管理用關鍵數據,因此除公司管理人員外,其他人員不得訪問.要求設有登錄密碼檢驗功能,並且此密碼可以在以後進行修改

可維護性:要求本軟體的維護文檔齊全,便於維護

『捌』 軟體工程 需求分析有哪三種方法

軟體工程中包含需求、設計、編碼和測試四個階段,其中需求工程是軟體工程第一個也是很重要的一個階段，需求分析是要決定「做什麼，不做什麼」。 在一個軟體項目中，軟體需求包括三個不同的層次-業務需求、用戶需求和功能需求-也包括非功能需求:業務需說明了提供給客戶和產品開發商的新系統的最初利益,反映了組織機構或客戶對系統、產品高層次的目標要求。 軟體開發，能否獲得成功，最重要的是需求分析的工作。因此，軟體需求分析能力和水平，對軟體項目至關重要。 一般的分析方法和步驟如下： ⑴首先調查組織機構情況 包括了解該組織的部門組成情況，各部門的職能等，為分析信息流程作準備。 ⑵然後調查各部門的業務活動情況 包括了解各個部門輸入和使用什麼數據，如何加工處理這些數據，輸出什麼信息，輸出到什麼部門，輸出結果的格式是什麼。 ⑶協助用戶明確對新系統的各種要求 包括信息要求、處理要求、完全性與完整性要求。 ⑷確定新系統的邊界 確定哪些功能由計算機完成或將來准備讓計算機完成，哪些活動由人工完成。由計算機完成的功能就是新系統應該實現的功能。 常用的調查方法有： ⑴跟班作業 通過親身參加業務工作來了解業務活動的情況。這種方法可以比較准確地理解用戶的需求，但比較耗費時間。 ⑵開調查會 通過與用戶座談來了解業務活動情況及用戶需求。座談時，參加者之間可以相互啟發。 ⑶請專人介紹。 ⑷詢問 對某些調查中的問題，可以找專人詢問。 ⑸設計調查表請用戶填寫 如果調查表設計得合理，這種方法是很有效，也很易於為用戶接受的。 ⑹查閱記錄 即查閱與原系統有關的數據記錄，包括原始單據、賬簿、報表等。 通過調查了解了用戶需求後，還需要進一步分析和表達用戶的需求。分析和表達用戶需求的方法主要包括自頂向下和自底向上兩類方法。

『玖』 傳統需求分析方法包括哪些主要特點是什麼

傳統需求分析方法：結構化分析方法。

主要特點：結構化的分析方法是傳統的分析法，它的好處是在需求階段可以不需要精確地定義系統，只需要根據業務框架確定系統的功能范圍，以及每個功能的處理邏輯和業務規則，功能需求規格書等。

因為不需要精確描述，因此描述系統的方式比較靈活多樣，可以採用圖表、示例圖、文字等等方式來描述系統。在系統開發以前，一般還可以採用更為直觀的原型系統方式和最終用戶進行交流和確認，因此對業務需求的要求會低一些，業務需求階段的周期相對容易控制。

通過業務全景圖，最終用戶也能了解系統的功能；通過功能活動圖和業務規則的描述，也可以相對精確地描述業務系統；因為沒有嚴格的標記語言，可以採用適當的篇幅描述適當的系統。

當然，這種方法的缺點也是明顯的，分析人員和業務人員之間可能缺乏共同語言，機器不能識別業務需求書，在設計階段還需要繼續和用戶確認一部分功能。

需求分析原則

為了促進軟體研發工作的規范化、科學化，軟體領域提出了許多軟體開發與說明的方法，如結構化方法、原型化法、面向對象方法等。這些方法有的很相似。在實際需求分析工作中．每一種需求分析方法都有獨特的思路和表示法，基本都適用下面的需求分析的基本原則。

1、側重表達理解問題的數據域和功能域。對新系統程序處理的數據，其數據域包括數據流、數據內容和數據結構。而功能域則反映它們關系的控制處理信息。

2、需求問題應分解細化，建立問題層次結構。可將復雜問題按具體功能、性能等分解並逐層細化、逐一分析。

3、建立分析模型。模型包括各種圖表，是對研究對象特徵的一種重要表達形式。通過邏輯視圖可給出目標功能和信息處理間關系，而非實現細節。由系統運行及處理環境確定物理視圖，通過它確定處理功能和數據結構的實際表現形式。