問題二:如何系統分析用戶需求1。概念
需求的定義包括從用戶的角度(系統的外部行為)和從開發人員的角度(壹些內部特征)解釋需求。
關鍵問題是編寫需求文檔。我曾經目睹過所有的開發人員在壹個項目中被更換，客戶被迫和新的需求分析師坐在壹起。系統分析師說:我們想和妳談談妳的要求。客戶的第壹反應是:我已經把我的要求都告訴妳前任了，現在只想給我編個系統。
自稱無所不知的人
其實UGGs，需求是沒有文檔化的，所以新分析師得從頭開始。所以如果只有壹堆郵件、會議記錄或者壹些零碎的對話，妳就確定妳已經了解了用戶的需求，這完全是自欺欺人。
需求的另壹個定義是，需求是用戶所需要的，並且可以觸發程序或系統開發。壹些需求分析師對這個概念進行了擴展:可以從系統外部找到讓用戶滿意的特性、功能和屬性。這些定義強調產品是什麽樣的，而不是產品是如何設計和構造的。以下定義進壹步從用戶需求轉移到系統特性:
需求是指明必須實現什麽的規範。它描述了系統的行為、特征或屬性，是開發過程中對系統的約束。
從這些不同的定義中，不難發現，並沒有明確的、模棱兩可的需求術語。真正的要求其實存在於人們的頭腦中。這個人主要是指客戶。但是，壹般情況下，用戶無法描述自己的需求。他們只是需要系統分析師根據自己的語言描述整理出相關需求，然後和客戶核對。系統分析師和客戶需要確保所有項目涉眾都必須* * *理解描述需求的術語。
任何文檔化的需求(比如下面描述的需求規範)都只是壹個模型和描述。
2.需求分析的任務
開發壹個軟件系統最困難的部分是準確地解釋要開發什麽。最困難的概念性工作是寫出詳細的技術要求，包括用戶、機器和其他軟件系統的所有接口。同時，這也是壹旦做錯最終會給系統帶來巨大損害的部分，後期修改極其困難。
目前國內產品很多，壹個企業可能有幾個系統並行運行。它們之間的接口是系統開發人員最頭疼的。
對於商業最終用戶應用程序來說，企業信息系統和軟件顯然是作為壹個大系統的壹部分的產品。但是對於我們開發人員來說，我們並沒有寫出客戶認可的需求文檔。我們怎麽知道項目什麽時候結束？如果我們不知道什麽對我們的客戶是重要的，我們如何滿足他們？
然而，即使是非商業目的的軟件需求也是必要的。例如，庫、組件和工具由開發團隊內部使用。當然，在沒有文檔的情況下，您可能偶爾會同意其他人的觀點，但更常見的是重復返工的不可避免的後果，重新編程代碼的成本遠遠超過重寫壹個需求文檔的成本。這些血淋淋的教訓正發生在國內軟件開發者身上。
最近，我遇到了壹個開發團隊，他們開發了壹套供內部使用的計算機輔助軟件，其中包括壹個代碼編輯器。遺憾的是，當他們開發完這個工具後，發現這個工具無法打印源代碼文件，用戶當然想要這個功能。結果，團隊不得不手動復制源代碼文檔進行代碼檢查。這說明，即使需求是清晰準確的，如果我們不寫文檔，軟件也只能怪自己沒有達到預期的目標。
相反，我見過壹個簡單的接口被集成到壹個錯誤跟蹤系統中寫壹頁需求描述。然而，操作系統管理員發現壹個簡單的需求列表在處理腳本時非常有用。當他們根據需求對系統進行測試時，系統不僅清晰地實現了所有必要的功能，而且沒有發現任何錯誤。
事實上，需求文檔在開發過程中壹直起著指導作用。
3.需求分析過程
整個軟件需求可以被工程化...> & gt
問題3:需求分析解決的問題是系統必須要做的。妳好。
要解決的問題是怎麽辦。
如果對我的回答不滿意，請繼續提問；
回答問題不容易，互相理解~
問題4:需求分析的作用以及如何進行。通過對相應問題及其環境的理解和分析，對問題涉及的信息、功能和系統行為建立模型，對用戶的需求進行準確、完整的描述，最終形成需求規格說明。這壹系列活動構成了軟件開發生命周期的需求分析階段。
需求分析是系統分析和軟件設計之間的橋梁。需求分析壹方面以系統規格和項目規劃作為分析活動的基本出發點，從軟件的角度進行檢查和調整；另壹方面，需求規格說明是軟件設計、實現、測試和維護的主要依據。良好的分析活動有助於盡快避免或消除早期錯誤，從而提高軟件生產率、降低開發成本和提高軟件質量。
需求工程隨著計算機的發展而發展。計算機開發初期，軟件規模不大，軟件開發側重於代碼編寫，很少關註需求分析。後來，生命周期的概念被引入軟件開發，需求分析成為其第壹階段。隨著軟件系統規模的擴大，需求分析和定義在整個軟件開發和維護過程中變得越來越重要，直接關系到軟件的成敗。人們逐漸意識到需求分析活動不再局限於軟件開發的初始階段，而是貫穿於系統開發的整個生命周期。80年代中期，形成了軟件工程的壹個子領域——需求工程(re)。自20世紀90年代以來，需求工程成為研究熱點之壹。從1993開始，需求工程國際研討會(ISRE)每兩年舉行壹次，從1994開始，需求工程國際會議(ICRE)每兩年舉行壹次。1996年，Springer-Verlag出版了壹本新的出版物——需求工程。壹些關於需求工程的工作組也已經成立，如歐洲的Renoir(國際合作研究小組的需求工程網絡)，並開始工作。需求工程是指應用成熟的技術和方法來分析需求、確定客戶需求、幫助分析師理解問題並定義目標系統的所有外部特征的學科。它通過適當的工具和符號，系統地描述待開發的系統及其行為特征和相關約束，形成需求文檔，支持用戶不斷變化的需求演化。RE可分為系統需求工程(如果是針對軟硬件組成的整個系統)和軟件需求工程(如果只是針對純軟件)。軟件需求工程是壹門分析和記錄軟件需求的學科。它將系統需求分解成壹些主要的子系統和任務，將這些子系統或任務分配給軟件，通過壹系列反復的分析、設計、比較研究和原型開發過程，將這些系統需求轉化為軟件需求描述和壹些性能參數。
需求工程是壹個反復定義、記錄和發展需求，並最終在驗證的基礎上凍結需求的過程。20世紀80年代，HerbKrasner定義了需求工程的五階段生命周期:需求定義與分析、需求決策、需求規格說明形成、需求實現與驗證、需求演化管理。最近，MatthiasJarke和KlausPohl提出了三階段循環理論:獲得、表征和驗證。
綜合幾種觀點，需求工程活動可以分為以下五個獨立的階段:
(1)需求獲取:通過與用戶溝通，觀察現有系統，分析任務，從而開發、捕捉、修改用戶需求；
(2)需求建模:為最終用戶所看到的系統建立壹個概念模型，作為需求的抽象描述，盡可能捕捉真實世界的語義；
(3)形成需求規格說明:生成需求模型組件的準確形式化描述，作為用戶和開發人員之間的契約；
(4)需求驗證:以需求規格說明為輸入，通過符號執行、仿真或快速原型分析需求規格說明的正確性和可行性；
(5)需求管理:支持系統的需求演化，如需求變更和可追溯性。...& gt& gt
問題5:軟件需求是什麽，功能需求是什麽？我們的軟件產品或項目有三個層次，三個方面。首先，我們來看三個層次的要求。軟件需求包括三個不同層次的業務需求、用戶需求和功能需求。業務需求代表了組織或客戶的高層目標。業務需求通常來自項目投資人、購買產品的客戶、實際用戶的管理者、營銷部門或產品策劃部門。業務需求描述了組織為什麽要開發壹個系統，也就是組織希望達到的目標。使用願景和範圍文檔來記錄業務需求，該文檔有時稱為項目圖表或市場需求文檔。用戶需求描述了用戶的目標或用戶要求系統完成的任務。用例、場景描述、事件DD響應表都是表達用戶需求的有效方式。換句話說，用戶需求描述了用戶可以用系統做什麽。功能需求規定了開發人員必須在產品中實現的軟件功能，用戶使用這些功能來完成任務和滿足業務需求。功能需求有時被稱為行為需求，因為習慣上用“應該”來描述它們:“系統應該發送壹封電子郵件通知用戶它已經接受了它的預訂”。功能需求描述是開發人員需要實現的。註:用戶需求並不總是轉化為功能需求。產品功能，所謂特性，是指壹組邏輯上相關的功能需求，為用戶提供某種功能，以滿足業務目標。對於商業軟件來說，功能是壹組能夠被客戶認可並幫助他們決定是否購買的需求，也就是產品手冊中用項目符號標註的部分。客戶想要的產品特性和用戶的任務相關需求並不完全相同。壹個特性可以包含多個用例，每個用例需要實現多個功能需求，以便用戶可以執行某個任務。系統需求用於描述包含多個子系統的產品(即系統)的頂層需求。壹個系統可以只包含軟件系統，或者同時包含軟件和硬件子系統。人也可以是系統的壹部分，所以有些系統功能可能由人來承擔。業務規則包括企業政策、法規、行業標準、會計準則和計算方法。商業計劃本身不是軟件需求，因為它們不屬於任何特定軟件系統的範圍。然而，業務規則經常限制誰可以執行某些用例，或者規定系統必須實現某些功能，以便遵守相關的規則。有時，功能中的特定質量屬性(由功能實現)也來自業務規則。所以當追溯到壹些功能需求時，會發現它的來源是壹個特定的業務規則。功能需求記錄在軟件需求規範(SRS)中。SRS完整地描述了軟件系統的預期特征。SRS我們壹般把它當做壹個文件。事實上，SRS也可以是包含需求信息的數據庫或電子表格。或者存儲在業務需求管理工具中的信息；對於小項目，它甚至可能是壹疊索引卡。SRS用於開發、測試、質量保證、項目管理和其他相關的項目職能。另外，對於需求層面，我們還有其他的子方法:組織層面需求-->；業務需求->；用戶需求-& gt；功能需求(有時稱為行為需求)。組織級需求:通常代表組織的願景和目標。對於大公司來說，壹般是通過資深顧問和咨詢公司獲取，呈現方式是咨詢報告。例如，在ITSM或企業信息化。典型的組織需求有:降低成本、降低庫存成本、提升企業IT服務部門的價值、采用ISO20000、提高IT服務效率、提高員工滿意度。業務需求:每個業務流程和業務單元完成使命和實現組織願景的要求。業務需求從屬於組織需求。用戶需求:用戶級需求是指業務級需求，每個崗位的需求...> & gt
問題6:如何寫系統需求分析？第壹部分系統需求分析1。系統功能模塊基本分為三個子系統:系統管理系統:學生選課系統的系統維護:學生選課操作教師查詢系統:學生選課查詢2。系統維護2 1 2.1。學生基本信息的維護目標:2.1.2。學生基礎數據維護概述:前提條件:管理員要對學生基礎數據進行添加、刪除、更新或查詢。角色:各級系統管理員輸入:學生基本屬性(學號、姓名、院系、班級、密碼、選修課總學分)。基本流程:登錄管理員系統→驗證當前用戶權限→選擇“學生基礎數據維護”→管理員添加、刪除或修改更新→驗證輸入或修改的數據→驗證通過:更新數據庫；驗證失敗:給出提示，要求用戶重新輸入。輸出:學生基本信息報告。2 2 2.2.1.教師基本信息維護目標:添加、刪除、更新、查詢教師基本信息。2.2.2.教師基本信息維護概述:前提條件:管理員要對教師基本信息進行添加、刪除、更新或查詢。角色:各級系統管理員輸入:教師基本信息(工號、姓名、部門、密碼及相關信息)。基本流程:登錄管理員系統→驗證當前用戶權限→選擇“教師基本信息維護”→管理員添加、刪除或修改更新→驗證輸入或修改的數據→驗證通過:更新數據庫，驗證失敗:給出提示信息，要求用戶重新輸入。輸出:教師基本信息報表。2 3 2.3.1.課程基礎數據維護目標:增加、刪除、更新和查詢課程的基礎數據。2.3.2.課程基礎數據維護概述:前提條件:管理員應能增加、刪除、更新或查詢課程基礎數據。角色:二級系統管理員輸入:課程基本信息(課程號、課程名稱、課程介紹、上課時間、上課地點、課時、學分、在線人數、當前人數、教師人數)基本流程:登錄管理員系統→驗證當前用戶權限→選擇“課程基本信息維護”→管理員添加、刪除或修改更新→驗證輸入或修改的數據→驗證通過:更新數據庫。輸出:課程詳細信息。242.4.1.部門數據的維護目標:增加、刪除、更新和查詢部門數據。2.4.2.部門維護概述:前提條件:管理員需要增加、刪除、更新或查詢部門數據。角色:壹級系統管理員輸入:部門數據(部門編號、部門名稱)基本流程:登錄管理員系統→驗證當前用戶權限→選擇“部門數據維護”→管理員新增、刪除或修改更新→驗證輸入或修改的數據→驗證通過:更新數據庫，驗證失敗:給出提示要求用戶重新輸入。輸出:無2 5 2.5.1。管理員維護目標:設置各級管理員權限2.5.2。管理員維護概述:前提條件:角色:初級管理員輸入:管理員權限基本流程:登錄系統→驗證權限→設置管理員權限→驗證設置→成功更新或失敗返回輸出:2 6 2.6.65438+。標準:正確修改管理員2.6.2的登錄密碼。密碼修改概述:前提條件:使用舊密碼正確登錄角色:各級管理員輸入:舊密碼、新密碼、密碼驗證。基本流程:登錄選課系統→驗證權限→輸入舊密碼、新密碼，提交驗證密碼→驗證舊密碼是否正確。新密碼和驗證密碼是否相同→成功或失敗(壹天內不超過3次)輸出:成功或失敗信息2 7 2.7.1。系統設置目標:通過系統設置2.7.2修改系統環境變量。系統設置......>;& gt
問題7:系統設計和需求分析是什麽關系？迫切需求2012-4-27 12:19滿意答案網絡規劃與需求分析從字面上看，需求分析就是找出需求與需求之間的關系，從當前的業務中找出最重要的方面，從已經運行的網絡中找出最需要改進的地方，滿足客戶提出的各種合理要求。根據客戶要求修改已形成的方案。本章重點介紹2.1類型需求分析2.2如何獲取需求2.3可行性論證2.4工程招投標2.2.1應用背景分析，總結了當前網絡應用的技術背景，介紹了行業應用的方向和技術趨勢。說明這個企業網絡信息化的必然性。應用背景需求分析應該回答壹些為什麽要實施網絡集成的問題。(1)國外同行業信息化程度，取得了哪些成績。(2)國內同行業信息化趨勢如何？(3)這個企業信息化的目的是什麽？(4)如何分析本企業要采用的信息化步驟？鍵入P332.2.1應用背景分析應用背景需求分析要回答壹些為什麽要實施網絡集成的問題。(1)國外同行業信息化程度，取得了哪些成績。(2)國內同行業信息化趨勢如何？(3)該企業信息化的目的是什麽？(4)如何分析本企業要采用的信息化步驟？P332.2.2業務需求類型業務需求分析的目標是明確企業的業務類型、應用系統軟件的類型及其對網絡功能指標(如帶寬、服務質量QoS)的要求。業務需求是企業網絡建設的首要環節。它是網絡規劃和設計的基本依據。需求分析的類型P332.2.2業務需求要通過業務需求分析為以下幾個方面提供決策依據:(1)需要實現或改進哪些企業網絡功能？(2)需要集成哪些企業應用？(3)您需要電子郵件服務嗎？(4)是否需要Web服務？(5)需要上網嗎？帶寬是多少？(6).妳需要視頻服務嗎？(7)需要什麽樣的數據* * *模式？(8)需要什麽樣的帶寬？(9)計劃投資規模是多少？需求分析的類型P332.2.3管理需求網絡管理是企業網絡建設不可或缺的壹個方面。網絡是否按照設計目標提供穩定的服務主要取決於有效的網絡管理。高效的管理策略可以提高網絡的運行效率。我們應該在網絡建設之初就註意這些策略。需求分析的類型P342.2.3管理需求網絡管理的需求分析要回答以下類似問題:是否有必要對網絡進行遠程管理？遠程管理可以幫助網絡管理員使用遠程控制軟件管理網絡設備，使網絡管理更加方便和高效。誰將負責網絡管理？需要哪些管理功能，比如是否收費，是否為網絡建立域，選擇什麽域模式等。需求分析類型P342.2.3管理需求選擇哪個廠商的網管軟件，是否有詳細的評估；選用哪個供應商的網絡設備，可管理性如何；是否需要對網絡運行信息進行跟蹤、分析和處理；網絡管理控制臺配置在哪裏？設備和接線方式容易管理嗎？P342.2.4安全需求在分析企業安全需求時要明確以下幾點:企業敏感數據的安全級別和分布情況；網絡用戶及其權利的安全等級；可能的安全漏洞，以及這些漏洞如何影響該系統；網絡設備的安全功能要求；需求分析的類型P342.2.4網絡系統軟件安全需求的安全評估；應用系統安全要求；用的是什麽殺毒軟件；采用什麽樣的防火墻技術方案；安全軟件系統的評估；網絡遵循的安全規範和達到的安全級別。需求分析的類型P342.2.5流量需求流量需求是以網絡應用為基礎，對當前技術條件下所能提供的網絡帶寬進行評估分析。
問題8:解決方案與需求分析和系統設計有什麽區別？解決方法是整體解釋。
需求就是系統要做的事情。
系統設計意味著如何去做
問題9:軟件需求分析的需求類型以下定義是需求工程領域常用術語的定義。軟件需求包括三個不同的層次:業務需求、用戶需求和功能需求(包括非功能需求)。1.業務需求反映了組織或客戶對系統和產品的高級目標需求，這些需求在項目視圖和範圍文檔中進行了描述。2.用戶需求文檔描述用戶在使用產品時必須完成的任務，在用例文檔或方案腳本描述中有解釋。3.功能需求定義了開發人員必須實現的軟件功能，以便用戶完成任務，從而滿足業務需求。軟件需求規範(SRS)中描述的功能需求充分描述了軟件系統應該具有的外部行為。軟件需求規格在開發、測試、質量保證、項目管理和相關項目功能中起著重要的作用。對於壹個大規模的系統，軟件功能需求可能只是系統需求的壹個子集，因為其他的可能屬於子系統(或者軟件組件)。作為功能需求的補充，軟件需求說明書還應該包括非功能需求，非功能需求描述了系統呈現給用戶的行為和操作。它包括產品必須遵守的標準、規範和合同；外部接口的具體細節；性能要求；設計或實現的約束和質量屬性。所謂約束，是指對開發者設計和構建軟件產品的限制。質量屬性是從各個角度描述產品的特性，從而反映產品的功能。對用戶和開發者來說，多角度描述產品是非常重要的。讓我們以壹個子流程為例來說明不同類型的需求。業務需求可以是:“用戶可以有效地糾正文檔中的拼寫錯誤”，產品包裝盒的封面可以表明這是符合業務需求的拼寫檢查器。對應的用戶需求可能是“找出文檔中的拼寫錯誤，並通過提供的備選列表選擇替換拼寫錯誤的單詞”。同時，拼寫檢查器也有很多功能需求，比如查找和突出錯誤單詞的操作；顯示壹個對話框，提供替換詞，實現整個文檔範圍的替換。從上面的定義可以發現，需求不包括設計細節、實現細節、項目規劃信息或測試信息。需求與這些無關，它關心的是充分解釋妳真正想要開發什麽。項目還有其他需求，比如開發環境或者發布產品並移植到支撐環境的需求。盡管這些需求對於項目的成功也是至關重要的，但它們並不在本書中討論。