·可靠性需求:各種軟件在運行時，失效的影響各不相同。在需求分析時，應對所開發軟件在投入運行后不發生故障的概率，按實際的運行環境提出要求，對于那些重要的軟件，或是運行失效會造成嚴重后果的軟件，應當提出較高的可靠性要求，以期在開發的過程中采取必要的措施，使軟件能夠高度可靠地穩定運行，避免因運行事故而帶來的損失。

　　·安全保密要求:工作在不同環境的軟件對其安全，保密的要求顯然是不同的。應當把這方面的需求恰當地做出規定，以便對所開發的軟件給予特殊的設計，使其在運行中其安全方面的性能得到必要的保證。

　　·用戶界面需求:軟件與用戶界面的友好性是用戶能夠方便、有效、愉快地使用該軟件的關鍵之一。從市場角度來看，具有友好用戶界面的軟件有很強的競爭力。因此，必須在需求分析時，為用戶界面細致地規定達到的要求。

　　·資源使用需求:這是指所開發軟件運行時所需的數據、軟件、內存空間等各項資源外，軟件開發時所需的人力、支撐軟件、開發設備等則屬于軟件開發的資源，需要在需求分析時加以確定。

　　·軟件成本消耗與開發進度需求:在軟件項目立項后，要根據合同規定，對軟件開發的進度和步驟的費用提出要求，作為開發管理的依據。

　　·預先估計以后系統可能達到的目標。這樣，在開發過程中，可對系統將來可能擴充與修改做準備。一旦需要時，就比較容易進行補充和修改。

　　·功能性需求是人們普遍關注的，但常常忽視對非功能性需求的分析。其實非功能性需求并不是無關緊要的，它們涉及到的方面多而廣，因而容易被忽略。如果在進行需求分析之前沒有做過可行性分析，那么補充完成這部分工作往往是必要的。從問題定義和調查研究入手，與用戶密切聯系，詳細了解問題提出的背景，弄清要解決什么問題。然后從軟件系統特性和用戶目標出發，做市場調查和現場考察。仔細收集信息之后進行數據分析和功能分析，建立系統的高層邏輯模型，再進一步做成本/效益分析。最后提交一份可行性分析報告，從技術、經濟、社會效應等方面論證可行性，以確認軟件開發的目標是否可行。

　　問題識別的另一項工作是建立分析所需要的通信途徑，以保證能順利地對問題進行分析。分析員必須與用戶、軟件開發機構的管理部門、軟件開發組的人員建立聯系。項目負責人在此過程中起協調人的作用。分析員通過這種通信途徑與各方商討，以便能滿足用戶的要求。

　　(2)分析與綜合

　　需求分析的第二步工作是問題分析和方案的綜合。分析員需從數據流和數據結構出發，逐步細化所有的軟件功能，找出系統各元素之間的聯系、接口特性和設計上的限制分析它們是否滿足功能要求，是否合理。依據功能需求、性能需求、運行特性和設計上的限制分析它們是否滿足功能要求，是否合理。依據功能需求、性能需求、運行環境需求等，剔除其不合理的部分，增加其需要的部分。最終綜合成系統的解決方案，給出目標系統的詳細邏輯模型。

　　在這個步驟中，分析和綜合工作反復地進行。在對現行問題和期望的信息(輸入和輸出)進行分析的基礎上，分析員開始綜合出一個或幾個解決方案，然后檢查這些方案是否符合軟件計劃中規定的范圍等等，再進行修改�？傊�，對問題進行分析和綜合的過程將一直持續到分析員與用戶雙方都感到有把握正確地制定該軟件的規格說明為止。

　　常用的分析方法有面向數據流的結構化分析方法(簡稱SA)、面向數據結構的Jackson方法(簡稱JSD)、面向對象的分析方法(簡稱OOA)等，以及用于建立動態、模型的狀態遷移圖或Petri網等。這些方法都采用圖文結合的方式，可以直觀地描述軟件的邏輯模型。

　　(3)編制需求分析的文檔

　　已經確定的需求應當得到清晰準確的描述。通常把描述需求的文檔叫做軟件需求規格說明書。同時，為了確切表達用戶對軟件的輸入輸出要求，還需要制定數據要求說明書及編寫初步的用戶手冊，著重反映被開發軟件的用戶界面和用戶使用的具體要求。

　　此外，依據在需求分析階段對系統的進一步分析，從目標系統的精細模型出發，可以更確切地估計所開發項目的成本與進度，從而修改、完善與確定軟件開發的實施計劃。

　　(4)需求分析評審

　　作為需求分析階段工作的復查手段，在需求分析的最后一步，應該對功能的正確性、完整性和清晰性，以及其他需求給予評價。評審的主要內容是:

　　·系統定義的目標是否與用戶的要求一致;

　　·系統需求分析階段提供的文檔資料是否齊全;

　　·文檔中的所有描述是否完整、清晰、準確所反映用戶要求;

　　·與所在其他系統成分的重要接口是否都已經描述;

　　·所開發項目的數據流與數據結構是否足夠、確定;

　　·所有圖表是否清楚，在不補充說明時能否理解;

　　·主要功能是否已包括在規定的軟件范圍之內，是否都已充分說明;

　　·設計的約束條件或限制條件是否符合實際;

　　·開發的技術風險是什么;

　　·是否考慮過軟件需求的其他方案;

　　·是否考慮過將來可能會提出的軟件需求;

　　·是否詳細制定了檢驗標準，它們能否對系統定義是否成功進行確認;

　　·有沒有遺漏、重復或不一致的地方;

　　·用戶是否審查了初步的用戶手冊;

　　·軟件開發計劃中的估算是否受到了影響。

　　為保證軟件需求定義的質量，評審應以專門指定的人員負責，并按規程嚴格進行。評審結束應有評審負責人的結論意見及簽字。除分析員之外，用戶，開發部門的管理者，軟件設計、實現、測試的人員都應當參加評審工作。通常，評審的結果都包括了一些修改意見，待修改完成后再經評審通過，才可進入設計階段。

　　相關推薦：

　　計算機等級考試合格標準

　　2014年計算機等考上機六大注意事項

　　2014年計算機等級考試三級真題及答案匯總