·可靠性需求:各種軟件在運行時,失效的影響各不相同。在需求分析時,應(yīng)對所開發(fā)軟件在投入運行后不發(fā)生故障的概率,按實際的運行環(huán)境提出要求,對于那些重要的軟件,或是運行失效會造成嚴重后果的軟件,應(yīng)當提出較高的可靠性要求,以期在開發(fā)的過程中采取必要的措施,使軟件能夠高度可靠地穩(wěn)定運行,避免因運行事故而帶來的損失。
·安全保密要求:工作在不同環(huán)境的軟件對其安全,保密的要求顯然是不同的。應(yīng)當把這方面的需求恰當?shù)刈龀鲆?guī)定,以便對所開發(fā)的軟件給予特殊的設(shè)計,使其在運行中其安全方面的性能得到必要的保證。
·用戶界面需求:軟件與用戶界面的友好性是用戶能夠方便、有效、愉快地使用該軟件的關(guān)鍵之一。從市場角度來看,具有友好用戶界面的軟件有很強的競爭力。因此,必須在需求分析時,為用戶界面細致地規(guī)定達到的要求。
·資源使用需求:這是指所開發(fā)軟件運行時所需的數(shù)據(jù)、軟件、內(nèi)存空間等各項資源外,軟件開發(fā)時所需的人力、支撐軟件、開發(fā)設(shè)備等則屬于軟件開發(fā)的資源,需要在需求分析時加以確定。
·軟件成本消耗與開發(fā)進度需求:在軟件項目立項后,要根據(jù)合同規(guī)定,對軟件開發(fā)的進度和步驟的費用提出要求,作為開發(fā)管理的依據(jù)。
·預先估計以后系統(tǒng)可能達到的目標。這樣,在開發(fā)過程中,可對系統(tǒng)將來可能擴充與修改做準備。一旦需要時,就比較容易進行補充和修改。
·功能性需求是人們普遍關(guān)注的,但常常忽視對非功能性需求的分析。其實非功能性需求并不是無關(guān)緊要的,它們涉及到的方面多而廣,因而容易被忽略。如果在進行需求分析之前沒有做過可行性分析,那么補充完成這部分工作往往是必要的。從問題定義和調(diào)查研究入手,與用戶密切聯(lián)系,詳細了解問題提出的背景,弄清要解決什么問題。然后從軟件系統(tǒng)特性和用戶目標出發(fā),做市場調(diào)查和現(xiàn)場考察。仔細收集信息之后進行數(shù)據(jù)分析和功能分析,建立系統(tǒng)的高層邏輯模型,再進一步做成本/效益分析。最后提交一份可行性分析報告,從技術(shù)、經(jīng)濟、社會效應(yīng)等方面論證可行性,以確認軟件開發(fā)的目標是否可行。
問題識別的另一項工作是建立分析所需要的通信途徑,以保證能順利地對問題進行分析。分析員必須與用戶、軟件開發(fā)機構(gòu)的管理部門、軟件開發(fā)組的人員建立聯(lián)系。項目負責人在此過程中起協(xié)調(diào)人的作用。分析員通過這種通信途徑與各方商討,以便能滿足用戶的要求。
(2)分析與綜合
需求分析的第二步工作是問題分析和方案的綜合。分析員需從數(shù)據(jù)流和數(shù)據(jù)結(jié)構(gòu)出發(fā),逐步細化所有的軟件功能,找出系統(tǒng)各元素之間的聯(lián)系、接口特性和設(shè)計上的限制分析它們是否滿足功能要求,是否合理。依據(jù)功能需求、性能需求、運行特性和設(shè)計上的限制分析它們是否滿足功能要求,是否合理。依據(jù)功能需求、性能需求、運行環(huán)境需求等,剔除其不合理的部分,增加其需要的部分。最終綜合成系統(tǒng)的解決方案,給出目標系統(tǒng)的詳細邏輯模型。
在這個步驟中,分析和綜合工作反復地進行。在對現(xiàn)行問題和期望的信息(輸入和輸出)進行分析的基礎(chǔ)上,分析員開始綜合出一個或幾個解決方案,然后檢查這些方案是否符合軟件計劃中規(guī)定的范圍等等,再進行修改?傊,對問題進行分析和綜合的過程將一直持續(xù)到分析員與用戶雙方都感到有把握正確地制定該軟件的規(guī)格說明為止。
常用的分析方法有面向數(shù)據(jù)流的結(jié)構(gòu)化分析方法(簡稱SA)、面向數(shù)據(jù)結(jié)構(gòu)的Jackson方法(簡稱JSD)、面向?qū)ο蟮姆治龇椒?簡稱OOA)等,以及用于建立動態(tài)、模型的狀態(tài)遷移圖或Petri網(wǎng)等。這些方法都采用圖文結(jié)合的方式,可以直觀地描述軟件的邏輯模型。
(3)編制需求分析的文檔
已經(jīng)確定的需求應(yīng)當?shù)玫角逦鷾蚀_的描述。通常把描述需求的文檔叫做軟件需求規(guī)格說明書。同時,為了確切表達用戶對軟件的輸入輸出要求,還需要制定數(shù)據(jù)要求說明書及編寫初步的用戶手冊,著重反映被開發(fā)軟件的用戶界面和用戶使用的具體要求。
此外,依據(jù)在需求分析階段對系統(tǒng)的進一步分析,從目標系統(tǒng)的精細模型出發(fā),可以更確切地估計所開發(fā)項目的成本與進度,從而修改、完善與確定軟件開發(fā)的實施計劃。
(4)需求分析評審
作為需求分析階段工作的復查手段,在需求分析的最后一步,應(yīng)該對功能的正確性、完整性和清晰性,以及其他需求給予評價。評審的主要內(nèi)容是:
·系統(tǒng)定義的目標是否與用戶的要求一致;
·系統(tǒng)需求分析階段提供的文檔資料是否齊全;
·文檔中的所有描述是否完整、清晰、準確所反映用戶要求;
·與所在其他系統(tǒng)成分的重要接口是否都已經(jīng)描述;
·所開發(fā)項目的數(shù)據(jù)流與數(shù)據(jù)結(jié)構(gòu)是否足夠、確定;
·所有圖表是否清楚,在不補充說明時能否理解;
·主要功能是否已包括在規(guī)定的軟件范圍之內(nèi),是否都已充分說明;
·設(shè)計的約束條件或限制條件是否符合實際;
·開發(fā)的技術(shù)風險是什么;
·是否考慮過軟件需求的其他方案;
·是否考慮過將來可能會提出的軟件需求;
·是否詳細制定了檢驗標準,它們能否對系統(tǒng)定義是否成功進行確認;
·有沒有遺漏、重復或不一致的地方;
·用戶是否審查了初步的用戶手冊;
·軟件開發(fā)計劃中的估算是否受到了影響。
為保證軟件需求定義的質(zhì)量,評審應(yīng)以專門指定的人員負責,并按規(guī)程嚴格進行。評審結(jié)束應(yīng)有評審負責人的結(jié)論意見及簽字。除分析員之外,用戶,開發(fā)部門的管理者,軟件設(shè)計、實現(xiàn)、測試的人員都應(yīng)當參加評審工作。通常,評審的結(jié)果都包括了一些修改意見,待修改完成后再經(jīng)評審通過,才可進入設(shè)計階段。
相關(guān)推薦:
北京 | 天津 | 上海 | 江蘇 | 山東 |
安徽 | 浙江 | 江西 | 福建 | 深圳 |
廣東 | 河北 | 湖南 | 廣西 | 河南 |
海南 | 湖北 | 四川 | 重慶 | 云南 |
貴州 | 西藏 | 新疆 | 陜西 | 山西 |
寧夏 | 甘肅 | 青海 | 遼寧 | 吉林 |
黑龍江 | 內(nèi)蒙古 |