編程怎麼做需求分析

A. java 記事本需求分析該怎麽寫呢

窗體frame上放菜單欄menubar 上面放menu（文件，編輯什麼的） 上面放menuitem（文件下有的新建，打開，保存什麼的） 然後給各個menuitem添加不同的監聽

補充下，可以寫個右鍵菜單什麼的，
保存的時候要打開文件保存對話框，打開的時候也要打開對話框才好，

最後，加上你的作者信息吧，祝成功！
要源碼我這里也有。

B. 實例幫我解釋下如何做軟體的需求分析

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. 其他需求

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

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

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

C. java項目需求分析怎麼寫

目前， 國內外信息化建設已經進入基於Web應用為核心的階段， Java作為應用於網路的最好語言，前景無限看好。然而，就算用Java建造一個不是很煩瑣的web應用，也不是件輕松的事情。概括一下，實施Java的WEB項目需要掌握的技術如下：

lJava語言

l面向對象分析設計思想

l設計模式和框架結構

lXML語言

l網頁腳本語言

l資料庫

l應用伺服器

l集成開發環境

下面我們具體地看每個技術.

1、Java語言

Java語言體系比較龐大，包括多個模塊。從WEB項目應用角度講有JSP、Servlet、JDBC、JavaBean(Application)四部分技術。

（1）、Java Database Connectivity(JDBC)技術

在Java Web應用開發中，資料庫管理系統（RDBMS）的使用是不可缺少的。JDBC(Java Database Connectivity) 是一種用於執行SQL 語句的 Java API。它由一組用 Java 編程語言編寫的類和介面組成。JDBC 為工具/資料庫開發人員提供了一個標準的API，使他們能夠用純Java API 來編寫資料庫應用程序。

簡單地說，JDBC 可做三件事：

l與資料庫建立連接，

l發送SQL 語句，

l處理結果。

（2）、Servlet技術

Servlet是運行在伺服器端的程序，可以被認為是伺服器端的applet。servlet被Web伺服器（例如Tomcat）載入和執行，就如同applet被瀏覽器載入和執行一樣。servlet從客戶端(通過Web伺服器)接收請求，執行某種操作，然後返回結果。

Servlet的主要優點包括

lServlet是持久的。servlet只需Web伺服器載入一次，而且可以在不同請求之間保持服務(例如一次資料庫連接)。

lServlet是與平台無關的。如前所述，servlet是用Java編寫的，它自然也繼承了Java的平台無關性。

lServlet是可擴展的。由於servlet是用Java編寫的，它就具備了Java所能帶來的所有優點。Java是健壯的、面向對象的編程語言，它很容易擴展以適應你的需求。servlet自然也具備了這些特徵。

lServlet是安全的。從外界調用一個servlet的惟一方法就是通過Web伺服器。這提供了高水平的安全性保障，尤其是在你的Web伺服器有防火牆保護的時候。

lServlet可以在多種多樣的客戶機上使用。由於servlet是用Java編寫的，所以你可以很方便地在HTML中使用它們。

（3）、JavaServer Pages(JSP)技術

JSP是從Servlet上分離出來的一小部分，簡化了開發，加強了界面設計。JSP定位在交互網頁的開發。運用Java語法，但功能較Servlet弱了很多，並且高級開發中只充當用戶界面部分。JSP容器收到客戶端發出的請求時，首先執行其中的程序片段，然後將執行結果以HTML格式響應給客戶端。其中程序片段可以是：操作資料庫、重新定向網頁以及發送 E-Mail 等等，這些都是建立動態網站所需要的功能。所有程序操作都在伺服器端執行，網路上傳送給客戶端的僅是得到的結果，與客戶端的瀏覽器無關，因此，JSP 稱為Server-Side Language。

JavaServer Pages的主要優點包括

●一次編寫，各處執行(Write o­nce, Run Anywhere)特性

作為Java 平台的一部分，JavaServer Pages 技術擁有Java語言「一次編寫，各處執行」的特點。隨著越來越多的供貨商將JavaServer Pages 技術添加到他們的產品中，您可以針對自己公司的需求，做出審慎評估後，選擇符合公司成本及規模的伺服器，假若未來的需求有所變更時，更換伺服器平台並不影響之前所投下的成本、人力所開發的應用程序。

● 搭配可重復使用的組件

JavaServer Pages技術可依賴於重復使用跨平台的組件（如：JavaBean或Enterprise JavaBean組件）來執行更復雜的運算、數據處理。開發人員能夠共享開發完成的組件，或者能夠加強這些組件的功能，讓更多用戶或是客戶團體使用。基於善加利用組件的方法，可以加快整體開發過程，也大大降低公司的開發成本和人力。

● 採用標簽化頁面開發

Web 網頁開發人員不一定都是熟悉Java 語言的程序員。因此，JSP 技術能夠將許多功能封裝起來，成為一個自定義的標簽，這些功能是完全根據XML 的標准來制訂的，即JSP 技術中的標簽庫(Tag Library)。因此，Web 頁面開發人員可以運用自定義好的標簽來達成工作需求，而無須再寫復雜的Java 語法，讓Web 頁面開發人員亦能快速開發出一動態內容網頁。

今後，第三方開發人員和其他人員可以為常用功能建立自己的標簽庫，讓Web 網頁開發人員能夠使用熟悉的開發工具，如同HTML 一樣的標簽語法來執行特定功能的工作。

●N-tier 企業應用架構的支持

有鑒於網際網路的發展，為因應未來服務越來越繁雜的要求，且不再受地域的限制，因此，

必須放棄以往Client-Server的Two-tier 架構，進而轉向更具威力、彈性的分散性對象系統。由於JavaServer Page 技術是Java 2 Platform Enterprise Edition (J2EE)集成中的一部分，它主要是負責前端顯示經過復雜運算後之結果內容，而分散性的對象系統則是主要依賴EJB ( Enterprise JavaBean )和JNDI ( Java Naming and Directory Interface )構建而成。

（4）、JavaBean(Application)應用組件技術
Application是Java應用程序，在WEB項目和一些開發中主要應用JavaBean。它就是Application的一部分，邏輯運算能力很強，能極大的發揮Java語言的優點。JavaBean 被稱為是Java 組件技術的核心。JavaBean 的結構必須滿足一定的命名約定。JavaBean能提供常用功能並且可以重復使用，這使得開發人員可以把某些關鍵功能和核心演算法提取出來封裝成為一個組件對象，這樣就增加了代碼的重用率和系統的安全性。

高級的WEB項目會應用到以上所有技術，它們之間聯合使用和協作開發會提高開發的效率和系統的性能。

2、面向對象分析設計思想

Java語言是完全面向對象的語言，所以在項目設計時會有很大的幫助，在設計時應盡量舍棄以往的面向過程的設計方式。

在分析項目業務關系的時候，應用一些UML(Unified Modeling Language)圖,例如常用的用例圖(use case diagram)，類圖(class diagram)，時序圖(sequence diagram)等等,會有很大的幫助，這樣能盡快找出業務邏輯主要面對的對象，然後對每個對象進行行為劃分，最後再實現對象之間的集成和通信。

3、設計模式和框架結構

Java從語言角度來講不是很難，但是從整體設計角度來講我們還需要了解一些高級應用框架。如果要設計一個良好的框架結構，單單只掌握Java語言遠遠不夠。這就涉及到一個設計模式，還有和設計模式相關的一些知識。

設計模式在Java項目實施過程更是重中之重。主要在與兩層的設計模式、三層的設計模式和N層的設計模式。它直接決定著項目的應用、部署和實際開發設計。

在普通的WEB項目中很多採用兩層的開發結構。JSP+Servlet或JSP+JavaBean。當對開發要求高的項目中使用很多的還是MVC的三層開發結構，也就是JSP+Servlet+JavaBean。它能分有效的分離邏輯開發，使開發人員能專注於各自的開發。同時也能時整個開發結構流程更清晰，但是需要比較高的開發配合度。
在項目中，我們經常使用著名的Model-View-Controller(MVC)架構。MVC架構是隨著smalltalk language語言的發展提出的，它是一個著名的用戶界面設計架構。經典的MVC架構把一個組件（可認為是整個應用程序的一個模塊）劃分成三部分組 Model管理這個模塊中所用到的數據和業務邏輯。而View 管理模塊如何顯示給用戶，Controller 決定如何處理用戶和該模塊互動式時候產生的事件 如用戶點擊一個按鈕等。

4、XML語言

在伺服器和設計模式結構中會應用到自定義文件，而且在應用高級設計時也會定義自用的標簽，現在流行的是用XML去定義配置，所以XML語言應該有一定掌握。

當前，Java 2平台企業版（J2EE）架構在廠商市場和開發者社區中倍受推崇。作為一種工具，可擴展標記語言（XML）簡化了數據交換、進程間消息交換這一類的事情，因而對開發者逐漸變得有吸引力，並開始流行起來。自然，在J2EE架構中訪問或集成XML解決方案的想法也很誘人。因為這將是強大系統架構同高度靈活的數據管理方案的結合。

XML的應用似乎是無窮無盡的，但它們大致上可以分為三大類：
1、簡單數據的表示和交換（針對XML的簡單API（SAX）和文檔對象模型（DOM）語法解析，不同的文檔類型定義（DTDs）和概要（schemas））
2、用戶界面相關、表示相關的上下文（可擴展樣式表語言（XSL），可擴展樣式表語言轉換（XSLT））
3、面向消息的計算（XML-RPC（遠程過程調用），基於SOAP協議的Web 服務（Web Services），電子化業務XML（ebXML））

5、網頁腳本語言

為了提高WEB項目的整體性能，提高人機交互的友好界面，網頁的腳本語言是很有用處的，有的時候可以解決很大的難題或提高程序的性能和應用性。

網頁腳本語言的執行都是在客戶端執行的，速度很很快，並且大多的操作與伺服器沒有交互運算，所以在一些應用中非常理想。在設計WEB項目的應用中，網頁的腳本語言起著不能忽視的作用，所以如果設計WEB項目的應用中，對JavaScript應有一定的了解。

JavaScript是一種基於對象(Object Based)和事件驅動(Event Driven)並具有安全性能（Secure）的腳本語言。使用它的目的是與HTML超文本標記語言、Java 腳本語言（Java小程序）一起實現在一個Web頁面中鏈接多個對象，與Web客戶交互作用。從而可以開發客戶端的應用程序等。它是通過嵌入或調入在標準的HTML語言中實現的。它具有以下幾個基本特點：

1.它是一種腳本編寫語言
JavaScript是一種腳本語言，它採用小程序段的方式實現編程。像其它腳本語言一樣,JavaScript同樣已是一種解釋性語言,它提供了一個易的開發過程。
它的基本結構形式與C、C++、VB十分類似。但它不像這些語言一樣，需要先編譯，而是在程序運行過程中被逐行地解釋。它與HTML標識結合在一起，從而方便用戶的使用操作。

2.基於對象的語言。
JavaScript是一種基於對象的語言，同時以可以看作一種面向對象的。這意味著它能運用自己已經創建的對象。因此，許多功能可以來自於腳本環境中對象的方法與腳本的相互作用。

3.簡單性
JavaScript的簡單性主要體現在：首先它是一種基於Java基本語句和控制流之上的簡單而緊湊的設計, 從而對於學習Java是一種非常好的過渡。其次它的變數類型是採用弱類型，並未使用嚴格的數據類型。

4.安全性
JavaScript是一種安全性語言，它不允許訪問本地的硬碟，並不能將數據存入到伺服器上，不允許對網路文檔進行修改和刪除，只能通過瀏覽器實現信息瀏覽或動態交互。從而有效地防止數據的丟失。

5. 動態性
JavaScript是動態的，它可以直接對用戶或客戶輸入做出響應，無須經過Web服務程序。它對用戶的響應，是採用以事件驅動的方式進行的。所謂事件驅動，就是指在主頁(Home Page)中執行了某種操作所產生的動作，就稱為「事件」(Event)。比如按下滑鼠、移動窗口、選擇菜單等都可以視為事件。當事件發生後，可能會引起相應的事件響應。

6、開發工具

（1）、資料庫

在主要的應用中，資料庫相關的環節應用很多，所以對資料庫應該有一定了解。不能單單只了解一種資料庫，因為在很多實際開發中會提出很多資料庫解決方案，所以只有在了解多種資料庫的情況下才能有一個比較方案。

對於資料庫應該了解他的性能和一些基本的操作常識，還有該資料庫的特點。而針對與Java語言WEB項目的資料庫開發則主要是對JDBC的應用，還有資料庫事務處理和連接池等高級概念的應用。

（2）、Web伺服器

同資料庫一樣，應該了解該伺服器的性能，特點和一些常識。

在應用方面，Web伺服器主要是針對於配置和部署，對目錄的配置，調試；對配置文件屬性的修改；對訪問許可權和並發性的控制；Java類的部署等。

（3）、集成開發環境（IDE）：

「公欲善其事， 必先利其器」. 對於Web應用開發人員來講，好的集成開發環境（IDE：Integrated Development Enviroment）是非常重要的。目前在市場上佔主導位置的一個集成開發工具就是Eclipse.

D. 程序員如何讓自己有清晰的編程邏輯

寫需求分析！在寫做程序之前，一定要寫好需求分析，在上面寫為什麼要做什麼，做的最終結果是什麼，先做什麼，後做什麼，這樣理清了，在做程序的時候，再仔細分析細節，長期訓練，基本就可以達到你要的目的。當然，一定的編程基礎是不少不了的，要房子，打好基礎是必經之路。有了基礎，才有後面的一切的一切。。。。。。。 嘿嘿，個人經驗，希望對你有幫助。

E. 軟體的需求分析怎麼寫啊

軟體需求分析免費下載

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

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

F. 論文高手進：軟體開發需求分析的認識和理解

應用軟體開發中的需求分析及方法 軟體工程一般具有以下基本活動：軟體描述：軟體的功能以及軟體操作上的約束定義；軟體設計和實現：軟體要按照描述來設計；軟體有效性驗證：軟體要被確定是有效的，能完成預期的應用；軟體進化：軟體按應用需要的變更來進化。其中，軟體描述的目標是，確定軟體系統需要哪些服務以及開發和運行期間受到哪些約束，對服務和約束的發現、分析、建立文檔、驗證活動，現在常稱為需求工程。為此，筆者談談如何進行需求分析及方法。 一、 需求的過程 需求工程對於軟體過程是一個特別關鍵的階段，這個階段的錯誤將不可避免地帶到後續的系統設計和實現階段中。需求工程階段的獨特之處在於很少有現成模式或特製的文檔可供參考。後續階段可以建立在前期所做工作基礎上（各種相關模型至少在一定程度上可以衍生導出），而需求工程階段的成果卻是靠創建而來的。 需求工程本身就是一個過程，這個過程將產生用以描述系統的需求文檔。通常需求在這個文檔中被分成兩個層次描述：最終用戶需要高層次的需求描述；而系統開發人員需要比較詳細的系統描述。 （一）需求過程的四個主要階段 1、可行性研究：指明現有的軟體、硬體技術能否實現用戶對新系統的要求。從業務角度來決定系統開發是否劃算以及在預算范圍內能否開發出來。可行性研究是初步的，結果就是要得出結論，該系統是否值得進行更細致的分析。 2、需求的導出和分析：這是一個通過對現有系統分析、與潛在用戶討論、進行任務分析等導出系統需求的過程。也可能需要開發一個或多個不同的系統模型和原型。這些都會幫助分析員了解所要描述的系統。 3、需求描述：需求描述就是把在分析活動中收集的信息以文檔的形式確定下來。在這個文檔中有兩類需求。用戶需求是從最終用戶對系統需求的抽象描述；系統需求是對系統要提供的功能的詳盡描述。 4、需求有效性驗證：這個活動檢查需求實現、一致和完備。在這個過程中，可發現需求文檔中的錯誤，並加以修正。 當然，需求過程中的各項活動並不是嚴格按順序進行的。在定義和描述期間，需求分析繼續進行，這樣在整個需求工程過程中不斷有新的需求出現。因此，分析、定義和描述是交替進行的。 （二）需求的進一步認識 1、軟體系統需求 常常分為功能需求、非功能需求和領域需求。 功能需求：包括對系統應該提供的服務、如何對輸入做出反應以及系統在特定條件下的行為的描述。在某些情況下，功能需求可能還需要明確申明系統不應該做什麼。理論上，系統的功能需求描述應該既全面又具有一致性。全面意味著用戶所需的所有服務都應該給出描述。一致性意味著需求描述不能前後矛盾。在實際過程中，對大型而又復雜的系統而言，要做到需求描述既全面又一致幾乎是不可能的。一方面是因為系統固有的復雜性，另一方面是因為觀點不同，需求也會發生矛盾。 非功能需求：對系統提供的服務或功能給出的約束。包括時間約束、開發過程約束、標准等。非功能需求源於用戶的限制，包括預算上的約束、機構政策、與其他軟硬體系統間的相互操作，還包括如安全規章、隱私權利保護等外部因素。 領域需求：這是來自系統的應用程序領域的需求，反映了該領域的特點。他們也可能是功能需求或非功能需求。 2、軟體需求文檔 也稱軟體需求描述（SRS），是對系統開發者要求的正式陳述。IEEE標准為需求文檔提出了以下結構：引言（目的、范圍、縮略詞等），一般描述（產品透視、功能、用戶特徵、約束等），專門需求（功能、非功能、介面），附錄，索引。 二、方法 （一）問題域（應用領域） 是指問題所存在的現實世界中的那個部分。問題域是需求分析員所要研究的首要對象。例如，對一個電梯控制系統來說，它將包含任何現存的硬體（電梯、指示器、感測器、按鈕等）、建築物特徵（樓層和電梯井的數目）、預期的使用模式、用戶特徵、使用約束（如限制短途搭乘）等等。在這個問題域內，問題可以確定為「讓電梯在建築物中更有效使用的控制系統」。為了解決問題，『解系統』顯然有必要在問題域內產生某些效果，構成軟體需求的正是這些想要獲得的效果，也就是為何做軟體需求的原因和目的。 到現在為止，我們得到初步論點。在構建一個新軟體系統之前，最好先決定它應當能夠做些什麼又不要做些什麼；從問題域的研究入手，獲得問題的描述，以及新的解系統在其中將產生效果的陳述（即需求）；確定新系統所需的行為，以便讓它在問題域內產生所需要的效果。 （二）需求分析 通過對問題域的研究，獲得對該領域特性及存在於其中（需要解決）的問題特性的透徹理解並用文檔說明。需求分析旨在揭示一個現有的系統（問題域）的結構，而內部設計則是要創建出一個尚未存在的軟體系統（解系統）的結構。對於這一重要任務其特性如下： 分析關注問題域及對其建立的模型，而不是解系統； 主要目標是要獲得對問題域及存在於其中的問題本質的理解； 分析在本質上先於解系統行為的規格說明（盡管有重疊和反復的過程）。 （三）方法論 方法不只是一種技術，它是解決任務的一種途徑，並且通常由一組技術組成。任何分析方法，要使它得到很好的利用，都應當要求並且做到便於描述以下幾個方面： 問題域的結構，根據其子域及其相互間的關系； 問題域數據，語法和語義方面 問題子域的內在屬性和行為； 問題域中的重要事件及現象； 需求，解系統在問題域中應產生的效果。 具體有以下三個方法： 1、結構化分析（SA） 結構化分析（SA）是一種具有相當長歷史的分析方法，其演化的方式既微妙又顯得很重要。如同結構化編程一樣，它致力於系統范圍內的事物處理，數據流以及存儲數據結構的建模。建模主要包括數據流模型（DFD），數據字典（DD），實體關系圖（ERD）。 結構化分析所用的原型，無論是對開發者還是客戶都顯得直觀易懂，若將初始重點放在對原有系統的建模是對實現理解問題域這一基本的分析目標的有力支持。 結構化分析方法和人們的思維方式很相似，注重的是事物的過程和方面。利用結構化分析很容易去理解一個剛剛接觸的問題域，適合對比較生疏領域做軟體需求。 2、 面向對象分析（OOA） 面向對象方法最初只是一種系統的結構進行建模的方式，後來擴展到了內部設計，如今也已經開始廣泛應用於分析階段。面向對象分析基本思想是：如果把對象類的建模限定在需求問題域，那麼面向對象的基本原理、模型以及表示法均可以用於分析。 OOA（面向對象分析）算不上一種真正的需求方法，OOA的起點是一份原有的需求文檔，或者甚至是一份行為規格說明，並且OOA隱含的假設問題域分析已經完成，即分析員已經了解了所要研究的事物。OOA的真正本質意義是作為解系統的高層體系結構的設計，並且有利於系統的下一步開發設計（如果是OOD開發的話）。 OOA的大致方法是：標識出問題域中的對象類；定義這些類的屬性和方法；定義這些類的行為；對這些類間的關系建模。 3、 面向問題域分析（PDOA） 面向問題域的分析（PDOA）是一種新技術。PDOA更多的強調描述，而較少的強調建模。描述大致劃分為兩個部分：一部分關注於問題域，而另一部分關注於解系統的待求行為。一般建議同時有兩個單獨文檔：第一文檔含有對問題域相關部分的描述以及一個需求在該域中求解的問題列表（即需求）；第二文檔（規格說明書）包含的是對解系統的待求行為的描述以解決需求。其中第一文檔才是通過做分析產生的；第二文檔推遲到後續的規格說明任務中。 PDOA整個方法過程的基本步驟： 搜集基本的信息並開發問題框架（一種模型），以建立問題域的類型 在問題框架類型的指導下，進一步搜集詳細信息並給出一個問題域相關的特性描述 基於以上兩點，收集並用文檔說明新系統的需求問題框架。問題框架是將問題域建模成一系列互相關聯的子域。一個子域可以是那些可能算是精選出來的問題域的任一部分。問題框架的目標就是大量地捕獲更多有關問題域的信息。基於不同問題子域的本質及存在於問題子域間的關系，可以把問題框架分類為： 工件系統——系統必須完成針對只存在於系統中的這些對象的直接操作。 控制系統——系統控制部分問題域的行為，包括待求行為框架和受控行為框架。 信息系統——系統將提供有關的問題域的信息，包括信息是自動提供的和信息只在響應具體的請求時提供。 轉換系統——系統必須將某種特定格式的輸入數據轉換成相應的、另一種特定格式的輸出。 連接系統——系統必須維持那些相互沒有直接連接的子域間的通信。 問題框架法在應用時，建議採用直截了當的策略： 抽象問題域：標識子域；標識子域間的交互；刻畫每個子域的特徵；生成一個上下文圖識別出相關的標准框架；調整框架，盡可能使之適用於問題；使用關於相關框架的內容技術表來指導進一步的分析與文檔編制任務。 問題域的描述與必須滿足的需求二者之間有著明顯的區別，對新的解系統的行為創建與定義應單獨處理並且推遲到下一步的規格說明階段。 4、方法的對比 結構化分析（SA）及其相應的派生方法，曾一度風行了許多年。它最初的版本主要是圍繞對數據流以及問題域的數據結構進行建模，而現代的SA則直接將重點放在開發解系統的模型。描述問題域的SA可以算是想當不錯的，所產生的功效可見一斑。然而，它對其他方面的支持卻不夠完善，在處理一些其他類型問題時顯得有些笨拙。 面向對象分析（OOA）是當今主流的方法。OOA要求所有的系統均可以按照對象的特點來建模。它也繼承了很多結構化分析的思想體系。OOA不能對問題域有個清楚的了解，因而它的起點若是有一份原需求文檔，便可大大簡化問題域的分析。OOA並不區分問題域描述與解系統描述之間的差異，而是直接交付出新的解系統的高層設計。 SA和OOA還有幾點相同特性：主要模型是結構模型；通常焦點集中在對解系統的建模上；兩中方法都較少地應用於需求獲取領域；分析與內部設計之間沒有明顯差異。 面向問題域分析（PDOA）被認為是一種較為理想的方法。PDOA特點是重新將重點定位在問題域及需求上，通過對問題域的分類，向分析人員提供具體問題的相關指南。並且它將規格說明作為另行的任務處理，它的成果只是一份問題域的全面描述和一份需求列表而已。PDOA豐富和完善了現今的「分析」方法，然而人們對它的了解和掌握還有一定距離。 因地制宜的應用三種方法，不僅能夠如實的認識問題域，創建出健全的解系統，還能夠向用戶和設計人員都提供滿意的需求文檔。 三、 總結 在做軟體需求的時候，我們完全沒必要去限定要用或將要使用何種方法。我們的目的在於分析軟體的需求，通常情況是都用到了所介紹的三種方法。首先我們用面向問題域的方法把問題分成幾個部分。接下來用面向結構或面向對象的方法對各個部分進行逐步分析細化。在逐步分析過程運用各種建模技術對問題各部分建立合適的模型來細化需求。隨著需求的進一步進行，我們越來越清晰的認識了軟體系統的需求。 雖然應用方法使我們能夠清楚地去了解軟體需求，但是，大部分的需求文檔和規格說明書都是以文本的形式記錄的，因此，如何去表達我們所了解的需求也是很值得注意的。

G. 請問做軟體需求分析需要掌握哪些編程知識

新手不能做需求分析！最好從coder做起
需求分析需要開發經驗，對軟體工具精準掌握，能夠判斷哪些需求能夠實現，通過何種方式實現。 同時必須對用戶業務有所了解，能夠充分溝通，這是一個綜合的能力。一般會由專門的系統分析工程師 、項目經理進行，
這個是軟體開發成敗的關鍵環節，非常重要！
如果單位安排你這個新人進行這個工作，應該有個高手給你把關，鍛煉的機會難得，要做好。

H. 幫忙寫個C程序設計的需求分析

每個部分的功能要求:
1.Program:根據題目要求，由於要求輸入數據個數n，以及n個數據，所以應提供數據的輸入及輸出等操作，並調用排序函數，以及精簡的循環和演算法達到題目要求。
2.Interface:為加強界面效果，應將提示語輸出到屏幕上，並盡量使排版整潔。而且有必要再進行一次操作後，調用清屏函數，使游標回到第一行第一列，以便下次運算。
3.Debug:在程序運行以及測試工作中，為了方便測試，核對結果的正確性，顯示運算過程，本程序應提供數據的運算過程及其循環一次的暫停，以便查找出錯原因。

I. 如何學好軟體開發編程

你和我的朋友遇到的問題一樣吧，學會了編程語言缺不知道如何入手。主要是沒了解軟體的開發流程吧。

不算美工，從純粹的開發來說。做軟體的第一步是做需求分析並把需求資料庫的對應，如果是大一點的項目，最好先畫出來的E-R圖、數據流圖等等。然後是設計表，（需求分析和資料庫的設計是重中之重，如果這一環節出問題，分析的不夠縝密，後期編碼絕對是事倍功半。在編碼期才發現資料庫的錯誤至少要花3-10倍的時間去修改和解決問題）
比如：圖書管理系統，你就要分析圖書館有什麼需求，然後設計對應的表，eg：圖書管理員表（涉及許可權）、圖書借閱者表、圖書分類表（外鍵關聯圖書表）、圖書表、圖書借閱表（這個是中間表，裡面是用戶ID和圖書ID對應的關系，同時還要記錄借閱時間，用戶超期問題等等）。這就是一個簡單的圖書管理的資料庫的分析（真實的情況要復雜很多，至少30個表以上）。

其實你所學的JAVA、.net、php就是在資料庫和顯示層（例如：網頁）之間的邏輯關系，例如：從資料庫取值，傳到顯示層（比如：顯示用戶的姓名等等）；從顯示層取值，傳到資料庫（例如：用戶注冊，會把頁面信息通過POST方式傳到邏輯層，再由邏輯層調用連接池，插入到資料庫）。

一般CS的系統就是界面和資料庫的設計，然後是編碼人員的開發；BS的系統開發正常的流程應該是網頁設計人員（設計靜態頁，和部分JS效果）和資料庫設計人員同時工作，當他倆的工作完成的時候，才是JAVA、PHP和.NET程序員出手的時候，網頁設計人員同時做技術支持。而你學的是java,php那樣的語言，不知道怎麼入手時正常的。

其實在大公司工作是不需要你分析項目和兼任美工的，那是高級程序員和專業美工的事，你的事其實並不難，就是把分配給你的任務做好而已。一般都是簡單的業務邏輯層的東西。

如果樓主想仔細研究下的話，建議看看E-R模型的分析，然後惡補一下資料庫的知識。資料庫的知識可是程序員的一種必備的高級「內功」啊。 資料庫不遇到難題看似簡單，其實資料庫本身比任何編程語言的復雜程度都不遜色。一旦真遇到難題，全團隊就你能解決，還怕不提升職位嗎？！
9月