1. 首頁 > 生活百科 > >

軟件需求分析_軟件的需求分析怎么寫啊？

生活百科

如何進行軟件需求分析1.概念
需求的定義包括從用戶角度(系統的外部行為),以及從開發者角度(一些內部特性)來闡述需求.
關鍵的問題是一定要編寫需求文檔.我曾經目睹過一個項目中途更換了所有的開發者,客戶被迫與新的需求分析者坐到一起.系統的分析人員說:"我們想與你談談你的需求."客戶的第一反應便是:"我已經將我的要求都告訴你們前任了,現在我要的就是給我編一個系統".
百事通
而實際上,UGGs,需求并未編寫成文檔,因此新的分析人員不得不從頭做起.所以如果只有一堆郵件、會談記錄或一些零碎的未整理的對話,你就確信你已明白用戶的需求,那完全是自欺欺人.
需求的另外一種定義認為需求是"用戶所需要的并能觸發一個程序或系統開發工作的說明".有些需求分析專家拓展了這個概念:"從系統外部能發現系統所具有的滿足于用戶的特點、功能及屬性等".這些定義強調的是產品是什么樣的,而并非產品是怎樣設計、構造的.而下面的定義則從用戶需要進一步轉移到了系統特性:
需求是指明必須實現什么的規格說明.它描述了系統的行為、特性或屬性,是在開發過程中對系統的約束.
從上面這些不同形式的定義不難發現:并沒有一個清晰、毫無二義性的"需求"術語存在,真正的"需求"實際上在人們的腦海中,這個人們主要是指客戶,但一般情況下,用戶并不能描述自己的需要,只就需要系統分析人員根據用戶的自己語言的描述整理出相關的需要再進一步和客戶核對.系統分析員和客戶需要確保所有項目風險承擔者在描述需求的那些名詞的理解上務必達成共識.
任何文檔形式的需求(例如如下將要描述的需求規格說明書)僅是一個模型,一種描述.
2.需求分析的任務
開發軟件系統最為困難的部分就是準確說明開發什么.最為困難的概念性工作便是編寫出詳細技術需求,這包括所有面向用戶、面向機器和其它軟件系統的接口.同時這也是一旦做錯,將最終會給系統帶來極大損害的部分,并且以后再對它進行修改也極為困難.
目前,國內產品的龐雜,一家企業可能有幾個系統并立運行,它們之間接口是系統開發人員最頭痛的問題.
對于商業最終用戶應用程序,企業信息系統和軟件作為一個大系統的一部分的產品是顯而易見的.但是對于我們開發人員來說,并沒有編寫出客戶認可的需求文檔,我們如何知道項目于何時結束?而如果我們不知道什么對客戶來說是重要的,那我們又如何能使客戶感到滿意呢?
然而,即便并非出于商業目的的軟件需求也是必須的.例如庫、組件和工具這些供開發小組內部使用的軟件.當然你可能偶爾勿需文檔說明就能與其他人意見較為一致,但更常見的是出現重復返工這種不可避免的后果,而重新編制代碼的代價遠遠超過重寫一份需求文檔的代價,這些血的教訓正在國內的軟件開發者身上發生.
近來,我遇到一個開發小組開發包括代碼編輯器在內的一套內部使用的計算機輔助軟件.不幸的是,當他們開發完這個工具后,發現這個工具不能打印出源代碼文件,使用者當然希望有這個功能.結果這個小組只好手工抄寫源代碼文檔以供代碼檢查.這說明那怕需求明確無誤并構思準確,如果我們沒有編寫文檔,軟件達不到期望目標也只能是咎由自取了.
相反的情況,我曾見一個要集成到"錯誤跟蹤系統"中的簡單界面寫了一頁需求說明.而操作系統系統管理員在為處理腳本時發現簡單的一張需求清單竟是如此有用.他們依據需求對系統進行測試時,此系統不僅非常清晰地實現了所有必需功能,而且未發現任何錯誤.
事實上,需求文檔在開發過程中一直起指導作用.
3.需求分析過程
可把整個軟件需求工程研究領域劃分為需求開發和需求管理兩部分更合適,如圖4-1所示:
圖4-1 需求工程域的層次分解示意圖
需求開發可進一步分為:問題獲取、分析、編寫規格說明和驗證四個階段.這些子項包括軟件類產品中需求收集、評價、編寫文檔等所有活動.需求開發活動包括以下幾個方面:
確定產品所期望的用戶類別.
獲取每個用戶類的需求.
了解實際用戶任務和目標以及這些任務所支持的業務需求.
分析源于用戶的信息以區別用戶任務需求、功能需求、業務規則、質量屬性、建議解決方法和附加信息.
將系統級的需求分為幾個子系統,并將需求中的一部份分配給軟件組件.
了解相關質量屬性的重要性.
商討實施優先級的劃分.
將所收集的用戶需求編寫成文檔和模型.
評審需求規格說明,確保對用戶需求達到共同的理解與認識,并在整個開發小組接受說明之前將問題都弄清楚.
需求管理需要"建立并維護在軟件工程中同客戶達成的合同" .這種合同都包含在編寫的需求文檔與模型中.客戶的接受僅是需求成功的一半,開發人員也必須能夠接受他們,并真正把需求應用到產品中.通常的需求管理活動包括:
定義需求基線(迅速制定需求文檔的主體).
評審提出的需求變更、評估每項變更的可能影響從而決定是否實施它.
以一種可控制的方式將需求變更融入到項目中.
使當前的項目計劃與需求一致.
估計變更需求所產生影響并在此基礎上協商新的承諾,這種承諾具體體現在項目解決方案上.
讓每項需求都能與其對應的設計、源代碼和測試用例聯系起來以實現跟蹤.
在整個項目過程中跟蹤需求狀態及其變更情況.
以上幾點說明是我總結了成功實施項目后系統分析人員的經驗,同時也根據國內外的其他系統實施的相關成功經驗,進行了總結.
4.需求的類型
下面這些定義是需求工程領域中常見術語的定義.
軟件需求包括三個不同的層次:業務需求、用戶需求和功能需求(也包括非功能需求).
1.業務需求(business requirement)反映了組織機構或客戶對系統、產品高層次的目標要求,它們在項目視圖與范圍文檔中予以說明.
2.用戶需求(user requirement) 文檔描述了用戶使用產品必須要完成的任務,這在使用實例(use case)文檔或方案腳本說明中予以說明.
3.功能需求(functional requirement)定義了開發人員必須實現的軟件功能,使得用戶能完成他們的任務,從而滿足了業務需求.
在軟件需求規格說明書 (SRS)中說明的功能需求充分描述了軟件系統所應具有的外部行為.軟件需求規格說明在開發、測試、質量保證、項目管理以及相關項目功能中都起了重要的作用.對一個大型系統來說,軟件功能需求也許只是系統需求的一個子集,因為另外一些可能屬于子系統(或軟件部件).
作為功能需求的補充,軟件需求規格說明還應包括非功能需求,它描述了系統展現給用戶的行為和執行的操作等.它包括產品必須遵從的標準、規范和合約;外部界面的具體細節;性能要求;設計或實現的約束條件及質量屬性.所謂約束是指對開發人員在軟件產品設計和構造上的限制.質量屬性是通過多種角度對產品的特點進行描述,從而反映產品功能.多角度描述產品對用戶和開發人員都極為重要.
下面以一個字處理程序為例來說明需求的不同種類.業務需求可能是:"用戶能有效地糾正文檔中的拼寫錯誤",該產品的包裝盒封面上可能會標明這是個滿足業務需求的拼寫檢查器.而對應的用戶需求可能是"找出文檔中的拼寫錯誤并通過一個提供的替換項列表來供選擇替換拼錯的詞".同時,該拼寫檢查器還有許多功能需求,如找到并高亮度提示錯詞的操作;顯示提供替換詞的對話框以及實現整個文檔范圍的替換.
從以上定義可以發現,需求并未包括設計細節、實現細節、項目計劃信息或測試信息.需求與這些沒有關系,它關注的是充分說明你究竟想開發什么.項目也有其它方面的需求,如開發環境需求或發布產品及移植到支撐環境的需求.盡管這些需求對項目成功也至關重要,但它們并非本書所要討論的.
5.需求分析的原則
不重視需求過程的項目隊伍將自食其果.需求工程中的缺陷將給項目成功帶來極大風險,這里的"成功"是指推出的產品能以合理的價格、及時地在功能、質量上完全滿足用戶的期望.下面將討論一些需求風險.
不適當的需求過程所引起的一些風險:
1. 無足夠用戶參與
客戶經常不明白為什么收集需求和確保需求質量需花費那么多功夫,開發人員可能也不重視用戶的參與.究其原因:一是因為開發人員感覺與用戶合作不如編寫代碼有意思;二是因為開發人員覺得已經明白用戶的需求了.在某些情況下,與實際使用產品的用戶直接接觸很困難,而客戶也不太明白自己的真正需求.但還是應讓具有代表性的用戶在項目早期直接參與到開發隊伍中,并一同經歷整個開發過程.
系統人員在實踐過程中,也有些感覺,在實施一家公司的項目時,若無足夠的用戶參與,系統人員獲得的需求是片面的,不完整的,這樣系統在需求之初就埋下風險.
2. 用戶需求的不斷增加
在開發中若不斷地補充需求,項目就越變越龐大以致超過其計劃及預算范圍.計劃并不總是與項目需求規模與復雜性、風險、開發生產率及需求變更實際情況相一致,這使得問題更難解決.實際上,問題根源在于用戶需求的改變和開發者對新需求所作的修改.
要想把需求變更范圍控制到最小,必須一開始就對項目視圖、范圍、目標、約束限制和成功標準給予明確說明,并將此說明作為評價需求變更和新特性的參照框架.說明中包括了對每種變更進行變更影響因素分析的變更控制過程,有助于所有風險承擔者明白業務決策的合理性,即為何進行某些變更,相應消耗的時間、資源或特性上的折中.
產品開發中不斷延續的變更會使其整體結構日漸紊亂,補丁代碼也使得整個程序難以理解和維護.插入補丁代碼使模塊違背強內聚、松耦合的設計原則,特別是如果項目配置管理工作不完善的話,收回變更和刪除特性會帶來問題.如果你盡早地區別這些可能帶來變更的特性,你就能開發一個更為健壯的結構,并能更好地適應它.這樣設計階段需求變更不會直接導致補丁代碼,同時也有利于減少因變更導致質量的下降.
3. 模棱兩可的需求
模棱兩可是需求規格說明中最為可怕的問題.它的一層含義是指諸多讀者對需求說明產生了不同的理解;另一層含義是指單個讀者能用不止一個方式來解釋某個需求說明.
模棱兩可的需求會使不同的風險承擔者產生不同的期望,它會使開發人員為錯誤問題而浪費時間,并且使測試者與開發者所期望的不一致.一位系統測試人員曾告訴我,她所在的測試組經常對需求理解有誤,以致不得不重寫許多測試用例并重做許多測試.
處理模棱兩可需求的一種方法是組織好負責從不同角度審查需求的隊伍.僅僅簡單瀏覽一下需求文檔是不能解決模棱兩可問題的.如果不同的評審者從不同的角度對需求說明給予解釋,但每個評審人員都真正了解需求文檔,這樣二義性就不會直到項目后期才被發現,那時再發現的話會使得更正代價很大.
4. 不必要的特性
"畫蛇添足"是指開發人員力圖增加一些"用戶欣賞"但需求規格說明中并未涉及的新功能.經常發生的情況是用戶并不認為這些功能性很有用,以致在其上耗費的努力"白搭"了.開發人員應當為客戶構思方案并為他們提供一些具有創新意識的思路,具體提供哪些功能要在客戶所需與開發人員在允許時限內的技術可行性之間求得平衡,開發人員應努力使功能簡單易用,而不要未經客戶同意,擅自脫離客戶要求,自作主張.
同樣,客戶有時也可能要求一些看上去很"酷",但缺乏實用價值的功能,而實現這些功能只能徒耗時間和成本.為了將"畫蛇添足"的危害盡量減小,應確信:你明白為什么要包括這些功能,以及這些功能的"來龍去脈",這樣使得需求分析過程始終是注重那些能使用戶完成他們業務任務的核心功能.
5. 過于精簡的規格說明
有時,客戶并不明白需求分析有如此重要,于是只作一份簡略之至的規格說明,僅涉及了產品概念上的內容,然后讓開發人員在項目進展中去完善,結果很可能出現的是開發人員先建立產品的結構之后再完成需求說明.這種方法可能適合于尖端研究性的產品或需求本身就十分靈活的情況.但在大多數情況下,這會給開發人員帶來挫折(使他們在不正確的假設前提和極其有限的指導下工作),也會給客戶帶來煩惱(他們無法得到他們所設想的產品).
6. 忽略了用戶分類
大多數產品是由不同的人使用其不同的特性,使用頻繁程度也有所差異,使用者受教育程度和經驗水平也不盡相同.如果你不能在項目早期就針對所有這些主要用戶進行分類的話,必然導致有的用戶對產品感到失望.例如,菜單驅動操作對高級用戶太低效了,但含義不清的命令和快捷鍵又會使不熟練的用戶感到困難.
7. 不準確的計劃
據統計,導致需求過程中軟件成本估計極不準確的原因主要有以下五點:頻繁的需求變更、遺漏的需求、與用戶交流不夠、質量低下的需求規格說明和不完善的需求分析.
對不準確的要求所提問題的正確響應是"等我真正明白你的需求時,我就會來告訴你".基于不充分信息和未經深思的對需求不成熟的估計很容易為一些因素左右.要作出估計時,最好還是給出一個范圍.未經準備的估計通常是作為一種猜測給出的,聽者卻認為是一種承諾.因此我們要盡力給出可達到的目標并堅持完成它.
6.需求分析人員和用戶的合作關系
優秀的軟件產品是建立在優秀的需求基礎之上的.而高質量的需求來源于客戶與開發人員之間有效的交流與合作.通常,開發人員與客戶或客戶代理人,如市場人員間的關系反而會成為一種對立關系.雙方的管理者都只想自己的利益而擱置用戶提供的需求從而產生摩擦,在這種情況下,不會給雙方帶來一點益處.
只有當雙方參與者都明白要成功自己需要什么,同時也應知道要成功合作方需要什么時,才能建立起一種合作關系.由于項目壓力與日漸增,所有風險承擔者有著一個共同的目標這一點容易被遺忘.其實大家都想開發出一個既能實現商業價值,又能滿足用戶需要,還能使開發者感到滿足的優秀軟件產品.
軟件客戶需求權利書列出了十條關于客戶在項目需求工程實施中與分析人員、開發人員交流時的合法要求.每一項權利都對應著軟件開發人員、分析人員的義務.而軟件客戶需求義務書也列出了十條關于客戶在需求過程中應承擔的義務.如果愿意,可以將其作為開發人員的權利書.
客戶有如下權利:
1:要求分析人員使用符合客戶語言習慣的表達
需求討論應集中于業務需要和任務,故要使用業務術語,你應將其教給分析人員,而你 不一定要懂得計算機的行業術語.
2:要求分析人員了解客戶的業務及目標
通過與用戶交流來獲取用戶需求、分析人員才能更好地了解你的業務任務和怎樣才能使產品更好地滿足你的需要.這將有助于開發人員設計出真正滿足你的需要并達到你期望的優秀軟件.為幫助開發人員和分析人員,可以考慮邀請他們觀察你或你的同事是怎樣工作的.如果新開發系統是用來替代已有的系統,那么開發人員應使用一下目前的系統,這將有利于他們明白目前系統是怎樣工作的,其工作流程的情況,以及可供改進之處.
3:要求分析人員編寫軟件需求規格說明
分析人員要把從你和其他客戶那里獲得的所有信息進行整理,以區分開業務需求及規范、功能需求、質量目標、解決方法和其它信息.通過這些分析就能得到一份軟件需求規格說明.而這份軟件需求規格說明便在開發人員和客戶之間針對要開發的產品內容達成了協議.軟件需求規格說明書可以用一種你認為易于翻閱和理解的方式組織編寫.要評審編寫出的規格說明以確保它們準確而完整地表達了你的需求.一份高質量的軟件需求規格說明能有助于開發人員開發出真正需要的產品.
4:要求得到需求工作結果的解釋說明
分析人員可能采用了多種圖表作為文字性軟件需求規格說明的補充.因為如工作流程圖那樣的圖表能很清楚地描述出系統行為的某些方面.所以需求說明中的各種圖表有著極高的價值.雖然它們不太難于理解,但是你很可能對此并不熟悉.因此可以要求分析人員解釋說明每張圖表的作用或其它的需求開發工作結果和符號的意義,及怎樣檢查圖表有無錯誤及不一致等.
5:要求開發人員尊重你的意見
如果用戶與開發人員之間不能相互理解,那關于需求的討論將會有障礙,共同合作能使大家"兼聽則明".參與需求開發過程的客戶有權要求開發人員尊重他們并珍惜他們為項目成功所付出的時間.同樣,客戶也應對開發人員為項目成功這一共同目標所作出的努力表示尊重與感激.
6:要求開發人員對需求及產品實施提供建議,拿出主意
通常,客戶所說的"需求"已是一種實際可能的實施解決方案,分析人員將盡力從這些解決方法中了解真正的業務及其需求,同時還應找出已有系統不適合當前業務之處,以確保產品不會無效或低效.在徹底弄清業務領域內的事情后,分析人員有時就能提出相當好的改進方法.有經驗且富有創造力的分析人員還能提出增加一些用戶并未發現的很有價值的系統特性.
7:描述產品易使用的特性
你可以要求分析人員在實現功能需求的同時還要注重軟件的易用性.因為這些易用特性或質量屬性能使你更準確、高效地完成任務.例如,客戶有時要求產品要"用戶友好"或"健壯"或"高效率",但這對于開發人員來說,太主觀了并無實用價值.正確的應是:分析人員通過詢問和調查了解客戶所要的友好、健壯、高效所包含的具體特性.
8:調整需求,允許重用已有的軟件組件
需求通常要有一定的靈活性.分析人員可能發現已有的某個軟件組件與你描述的需求很相符.在這種情況下,分析人員應提供一些修改需求的選擇以便開發人員能夠在新系統開發中重用一些已有的軟件.如果有可重用的機會出現,同時你又能調整你的需求說明,那就能降低成本和節省時間,而不必嚴格按原有的需求說明開發.所以說,如果想在產品中使用一些已有的商業常用組件,而它們并不完全適合你所需的特性,這時一定程度上的需求靈活性就顯得極為重要了.
9:獲得滿足客戶功能和質量要求的系統
每個人都希望項目獲得成功.但這不僅要求你要清晰地告知開發人員關于系統"做什么"所需的所有信息,而且還要求開發人員能通過交流了解清楚取舍與限制.一定要明確說明你的假設和潛在的期望.否則,開發人員開發出的產品很可能無法讓你滿意.
客戶有下列義務:
1:給分析人員講解你的業務
分析人員要依靠你給他們講解的業務概念及術語.但你不能指望分析人員會成為該領域的專家,而只能讓他們真正明白你的問題和目標.不要期望分析人員能把握你們業務的細微與潛在之處,他們很可能并不知道那些對于你和你的同事來說理所當然的"常識".
2:抽出時間清楚地說明并完善需求
客戶很忙,經常在最忙的時候還得參與需求開發.但無論如何,你有義務抽出時間參與"頭腦風暴"會議的討論,接受采訪或其它獲取需求的活動.有時分析人員可能先以為明白了你的觀點,而過后發現還需要你的講解.這時,請耐心一些對待需求和需求的精化工作過程中的反復,因為它是人們交流中的很自然的現象,何況這對軟件產品的成功極為重要.
3:準確而詳細地說明需求
編寫一份清晰、準確的需求文檔是很困難的.由于處理細節問題不但煩人而且又耗時,故很容易留下模糊不清的需求.但是,在開發過程中,必須得解決這種模糊性和不準確性.而你恰是為解決這些問題作出決定的最佳人選.不然的話,你就只好靠開發人員去正確猜測了.在需求規格說明中暫時加上待定(to be determined, TBD也可采用漢語拼音略寫"DQD:待確定")的標志是個不錯的辦法.用該標志可指明了哪些需要進一步探討、分析或增加信息的地方.不過,有時也可能因為某個特殊需求難以解決或沒有人愿意處理它而注上TBD標志.盡量將每項需求的內容都闡述清楚,以便分析人員能準確的將其寫進軟件需求規格說明中.如果你一時不能準確表述,那就得允許獲取必要的準確信息這樣一個過程.通常使用所謂的原型技術.通過開發的原型,你可以同開發人員一起反復修改,不斷完善需求定義.
4:及時地作出決定
正如一位建筑師為你修建房屋,分析人員將要求你做出一些選擇和決定.這些決定包括來自多個用戶提出的處理方法或在質量特性沖突和信息準確度中選擇折衷方案等.有權做出決定的客戶必須積極地對待這一切,盡快做處理、做決定.因為開發人員通常只有等你做出了決定才能行動,而這種等待會延誤項目的進展.
5:尊重開發人員的需求可行性及成本評估
所有的軟件功能都有其成本價格,開發人員最適合預算這些成本(盡管許多開發人員并不擅長評估預測).你所希望的某些產品特性可能在技術上行不通,或者實現它要付出極為高昂的代價.而某些需求試圖在操作環境中要求不可能達到的性能或試圖得到一些根本得不到的數據,開發人員會對此作出負面的評價意見,你應該尊重他們的意見.有時,你可以重新給出一個在技術上可行、實現上便宜的需求,例如,要求某個行為在"瞬間"發生是不可行的,但換種更具體的時間需求說法("在50ms以內",但若沒有準確的技術分析不能輕易下結論),這就可以實現了.
6: 劃分需求優先級別
大多數項目沒有足夠的時間或資源來實現功能性的每個細節.決定哪些特性是必要的,哪些是重要的,哪些是好的,是需求開發的主要部分.只能由你來負責設定需求優先級,因為開發者并不可能按你的觀點決定需求優先級.開發者將為你確定優先級提供有關每個需求的花費和風險的信息.當你設定優先級時,你幫助開發者確保在適當的時間內用最小的開支取得最好的效果.在時間和資源限制下,關于所需特性能否完成或完成多少應該尊重開發人員的意見.盡管沒有人愿意看到自己所希望的需求在項目中未被實現,但畢竟是要面對這種現實的.業務決策有時不得不依據優先級來縮小項目范圍或延長工期,或增加資源,或在質量上尋找折衷.
7:評審需求文檔和原型
正如我們將在第1 4章討論的,無論是正式的還是非正式的方式,對需求文檔進行評審都會對軟件質量提高有所幫助.讓客戶參與評審才能真正鑒別需求文檔是否的確完整、正確說明了期望的必要特性.評審也給客戶代表提供一個機會,給需求分析人員帶來反饋信息以改進他們的工作.如果你認為編寫的需求文檔不夠準確,就有義務盡早告訴分析人員并為改進提供建議.通過閱讀需求規格說明,很難想象實際的軟件是什么樣子的.更好的方法是先為產品開發一個原型.這樣你就能提供更有價值的反饋信息給開發人員,幫助他們更好地理解你的需求.必須認識到:原型并非是一個實際產品,但開發人員能將其轉變、擴充成功能齊全的系統.
8:需求出現變更要馬上聯系
不斷的需求變更會給在預定計劃內完成高質量產品帶來嚴重的負面影響.變更是不可避免的,但在開發周期中變更越在晚期出現,其影響越大.變更不僅會導致代價極高的返工,而且工期也會被迫延誤,特別是在大體結構已完成后又需要增加新特性時.所以一旦你發現需要變更需求時,請一定立即通知分析人員.
9:應遵照開發組織處理需求變更的過程
為了將變更帶來的負面影響減少到最低限度,所有的參與者必須遵照項目的變更控制過程.這要求不放棄所有提出的變更,對每項要求的變更進行分析、綜合考慮,最后作出合適的決策以確定將某些變更引入項目中.
10:尊重開發人員采用的需求工程過程
軟件開發中最具挑戰性的莫過于收集需求并確定其正確性.分析人員采用的方法有其合理性.也許你認為需求過程不太劃算,但請相信花在需求開發上的時間是"很有價值"的.如果你理解并支持分析人員為收集、編寫需求文檔和確保其質量所采用的技術,那么整個過程將會更為順利.盡管去詢問分析人員為什么他們要收集某些信息,或參與與需求有關的活動.
系統分析人員在開發過程中可能會遇到以下問題,一些很忙的客戶可能不愿意積極參與需求過程,而缺少客戶參與將很可能導致不理想的產品.故一定要確保需求開發中的主要參與者都了解并接受他們的義務.如果遇到分歧,通過協商以達成對各自義務的相互理解,這樣能減少今后的摩擦.
7.需求文檔
需求開發的最終成果是:客戶和開發小組對將要開發的產品達成一致協議.協議綜合了業務需求、用戶需求和軟件功能需求.就像我們早先所看到的,項目視圖和范圍文檔包含了業務需求,而使用實例文檔則包含了用戶需求.你必須編寫從使用實例派生出的功能需求文檔,還要編寫產品的非功能需求文檔,包括質量屬性和外部接口需求.只有以結構化和可讀性方式編寫這些文檔,并由項目的風險承擔者評審通過后,各方面人員才能確信他們所贊同的需求是可靠的.
你可以使用以下三種方法編寫軟件需求規格說明:
用好的結構化和自然語言編寫文本型文檔.
建立圖形化模型,這些模型可以描繪轉換過程、系統狀態和它們之間的變化、數據關系、邏輯流或對象類和它們的關系.
編寫形式化規格說明,這可以通過使用數學上精確的形式化邏輯語言來定義需求.
由于形式化規格說明具有很強的嚴密性和精確度,因此,所使用的形式化語言只有極少數軟件開發人員才熟悉,更不用說客戶了.雖然結構化的自然語言具有許多缺點,但在大多數軟件工程中,它仍是編寫需求文檔最現實的方法.包含了功能和非功能需求的基于文本的軟件需求規格說明已經為大多數項目所接受.圖形化分析模型通過提供另一種需求視圖,增強了軟件需求規格說明.
如果解決了您的問題請！
如果未解決請繼續擴展
怎樣做軟件的需求分析？軟件需求的定義：
（1）用戶解決問題或達到目標所需的條件或能力 。
（2）系統或系統部件要滿足合同、標準、規范或其它正式規定文檔所需具有的條件或能力 。
（3）一種反映上面(1)或(2)所描述的條件或權能的文檔說明 。實通俗的講，“需求”就是用戶的需要，它包括用戶要解決的問題、達到的目標、以及實現這些目標所需要的條件，它是一個程序或系統開發工作的說明，表現形式一般為文檔形式 。
需求工程的定義：
需求分析的過程，也叫做需求工程和需求階段，它包括了需求開發和需求管理兩個部分 。需求開發是指從情況收集、分析和評價到編寫文檔、評審等一系列產生需求的活動，分為四個階段：情況獲取、分析、制訂規格說明和評審 。這四個階段不一定是遵循線性順序的 ， 他們的活動是相互獨立和反復的 。需求管理是軟件項目開發過程中控制和維持需求約定的活動 ， 它包括：變更控制、版本控制、需求跟蹤、需求狀態跟蹤等工作 。
需求開發與管理的一些方法：
（1）繪制關聯圖：繪制系統關聯圖是用于定義系統與系統外部實體間的界限和接口的簡單模型 。
（2）可行性分析：在允許的成本、性能要求下，分析每項需求實施的可行性，提出需求實現相關風險，包括與其它需求的沖突，對外界因素的依賴和技術障礙 。
（4）系統原型：當用戶自身對有的需求不十分清楚時，我們可以建立一個系統原型 ， 用戶通過評價原型更好地理解所要解決的問題 。。
（5）圖形分析模型：繪制圖形分析模型是編制軟件需求規格說明重要手段 。它們能幫助分析人員理清數據、業務模式、工作流程以及他們之間的關系，找出遺漏、冗余和不一致的需求 。這樣的模型包括數據流圖、實體關系圖、狀態變換圖、對話框圖、對象類及交互作用圖 。
（6）數據字典：數據字典是對系統用到的所有數據項和結構的定義 ， 以確保開發人員使用統一的數據定義 。在需求階段，數據字典至少應定義客戶數據項，確?？蛻襞c開發小組是使用一致的定義和術語 。
需求管理的方法主要包括以下一些方面：
1）確定需求變更控制過程 。制定一個選擇、分析和決策需求變更的過程，所有的需求變更都需遵循此過程 。
2）進行需求變更影響分析 。評估每項需求變更，以確定它對項目計劃安排和其它需求的影響，明確與變更相關的任務并評估完成這些任務需要的工作量 。通過這些分析將有助于需求變更控制部門做出更好的決策 。
3）建立需求基準版本和需求控制版本文檔 。確定需求基準，這是項目各方對需求達成一致認識時刻的一個快照，之后的需求變更遵循變更控制過程即可 。每個版本的需求規格說明都必須是獨立說明 ， 以避免將底稿和基準或新舊版本相混淆 。
4）維護需求變更的歷史記錄 。將需求變更情況寫成文檔，記錄變更日期、原因、負責人、版本號等內容，及時通知到項目開發所涉及的人員 。為了盡量減少困惑、沖突、誤傳，應指定專人來負責更新需求 。
5）跟蹤每項需求的狀態 ?？梢园衙恳豁椥枨蟮臓顟B屬性（如已推薦的，已通過的，已實施的，或已驗證的）保存在數據庫中，這樣可以在任何時候得到每個狀態類的需求數量 。
6）衡量需求穩定性 ?？梢远ㄆ诎研枨髷盗亢托枨笞兏ㄌ砑?、修改、刪除）數量進行比較 。過多的需求變更"是一個報警信號"，意味著問題并未真正弄清楚 。
4.需求分析評價標準
（1）清晰：目前大多數的需求分析采用的仍然是自然語言 ， 自然語言對需求分析最大的弊病就是它的二義性，所以開發人員需要對需求分析中采用的語言做某些限制 。例如盡量采用主語＋動作的簡單表達方式 。需求分析中的描述一定要簡單，千萬不要采用疑問句、修飾這些復雜的表達方式 。除了語言的二義性之外，注意不要使用行話，就是計算機術語 。需求分析最重要的是和用戶溝通 ， 可是用戶多半不是計算機的專業人士 ， 如果在需求分析中使用了行話，就會造成用戶理解上的困難 。
（2）完整：需求的完整性是非常重要的，如果有遺漏需求，則不得不返工，在軟件開發過程中，最糟糕的事情莫過于在軟件開發接近完成時發現遺漏了一項需求 。但實際情況是，需求的遺漏是常發生的事情，這不僅僅是開發人員的問題，更多發生在用戶那里 。要做到需求的完整性是很艱難的一件事情，它涉及到需求分析過程的各個方面，貫穿整個過程 ， 從最初的需求計劃制定到最后的需求評審 。
（3）一致：一致性是指用戶需求必須和業務需求一致，功能需求必須和用戶需求一致 。在需求過程中，開發人員需要把一致性關系進行細化，比如用戶需求不能超出預前指定的范圍 。嚴格的遵守不同層次間的一致性關系，就可以保證最后開發出來的軟件系統不會偏離最初的實現目標 。
（4）可測試：一個項目的測試從什么時候開始呢？有人說是從編碼完成后開始，有人說是編碼的時候同時進行單元測試 ， 編碼完成后進行系統測試，這些結論都不完全正確 。實際上，測試是從需求分析過程就開始了，因為需求是測試計劃的輸入和參照 。這就要求需求分析是可測試的，只有系統的所有需求都是可以被測試的 ， 才能夠保證軟件始終圍繞著用戶的需要，保證軟件系統是成功的 。
什么是需求分析，其目標是什么？《軟件工程》需求分析 ， 也叫軟件需求分析、系統需求分析或需求分析工程等，是開發人員經過深入細致的調研和分析，準確理解用戶和項目的功能、性能、可靠性等具體要求 ， 將用戶非形式的需求表述轉化為完整的需求定義，從而確定系統功能的過程 。
需求分析的目標是把用戶對待開發軟件提出的要求或需要進行分析與整理，確認后形成描述完整、清晰與規范的文檔 ， 確定軟件需要實現的功能 ， 完成的工作 。此外，軟件的一些非功能性需求、軟件設計的約束條件、運行時與其他軟件的關系等也是軟件需求分析的目標 。

軟件需求分析_軟件的需求分析怎么寫啊？

文章插圖
擴展資料：
需求分析階段分為四個方面：問題識別、分析與綜合、制訂規格說明、評審 。
1、問題識別：從系統角度來理解軟件 ， 確定對所開發系統的綜合要求 ， 并提出這些需求的實現條件，以及需求應該達到的標準 。這些需求包括功能需求、性能需求、環境需求、可靠性需求、安全保密需求、用戶界面需求、資源使用需求、軟件成本消耗與開發進度需求 。
2、分析與綜合： 逐步細化所有的軟件功能 ， 找出系統各元素間的聯系，接口特性和設計上的限制 ， 分析他們是否滿足需求，剔除不合理部分，增加需要部分 。最后綜合成系統的解決方案，給出要開發的系統的詳細邏輯模型(做什么的模型) 。
3、制訂規格說明書： 編制文檔，描述需求 。需求分析階段的成果是需求規格說明書，向下一階段提交 。
4、評審： 對功能的正確性 ， 完整性和清晰性，以及其它需求給予評價 。評審通過才可進行下一階段的工作,否則重新進行需求分析 。
參考資料來源：百度百科-需求分析軟件開發過程中的需求分析與開發框架的區別需求分析奠定了軟件工程和項目管理的基礎 。我們在建造軟件系統這座大廈的時候 ， 如果需求分析的基礎不夠堅實和牢固，那么往往會導致軟件系統問題百出，甚至被馬上丟棄 。在建造軟件系統的過程中，如果我們經常習慣地沿用一些不規范的方法，其后果便是產生一條鴻溝──開發者開發的與用戶所想得到的軟件存在著巨大的“期望差異” 。因此“需求”這個名詞的定義不僅僅是從用戶角度對系統外部行為的描述，以及從開發人員角度對系統內部特性的描述，其關鍵的一點是“需求”必須文檔化 。
需求的類型
軟件需求包括三個不同的層次──業務需求、用戶需求和功能需求 。除此之外，每個系統還有各種非功能需求 。
業務需求（BusinessRequirement）表示組織或客戶高層次的目標 。業務需求通常來自項目投資人、購買產品的客戶、實際用戶的管理者、市場營銷部門或產品策劃部門 。業務需求描述了組織為什么要開發一個系統，即組織希望達到的目標 。使用前景和范圍（vision and scope）文檔來記錄業務需求，這份文檔有時也被稱作項目輪廓圖或市場需求（project charter 或 market requirement）文檔 。用戶需求（UserRequirement）描述的是用戶的目標，或用戶要求系統必須能完成的任務 。用例、場景描述和事件響應表都是表達用戶需求的有效途徑 。也就是說用戶需求描述了用戶能使用系統來做些什么 。
功能需求（Functional Requirement）規定開發人員必須在產品中實現的軟件功能 ， 用戶利用這些功能來完成任務，滿足業務需求 。功能需求有時也被稱作行為需求（behavioral requirement），因為習慣上總是用“應該”對其進行描述：“系統應該發送電子郵件來通知用戶已接受其預定” 。功能需求描述是開發人員需要實現什么 。
非功能需求（Non-functional Requirement） 定義了軟件產品為滿足用戶業務需求而必須具有的除功能需求以外的特性 。包括系統的完整性（聯機幫助、 數據管理、用戶管理、軟件發布管理、在線升級等）、性能、可靠性、可維護性、可擴充性、對技術和業務的適應性等 。
需求分析的任務
1 解決的問題
1) 齊全、準確地找出目標系統全部的功能、性能、限制； 2) 找出全部的輸入流、輸出流； 3) 找出所有的加工；
4) 產生完整的分層的DFD、數據字典、加工的描述； 5) 補充的意見 。
2 綜合要求
確定對系統的綜合要求，系統功能要求，系統性能要求 ， 運行要求，將來可能提出的要求 。
3 任務
圖1為需求分析任務圖，需求分析階段要完成的具體明確的最終任務就是形成一份經開發方和用戶認可或達成共識的軟件需求分析文檔（需求規格說明書、修改后的項目開發計劃、初步的用戶手冊、確認測試計劃、數據要求說明書） 。這個文檔能清晰準確地說明系統將要開發什么，能夠規定出詳細的技術需求，包括所有面向用戶、面向機器和其它軟件系統的接口 。可以說需求文檔在開發過程中一直起指導作用 。
為了更好地完成軟件開發第一階段的需求分析任務，提高質量，需求管理是必不可少的 。
需求管理的目的是在客戶與開發方之間建立對需求的共同理解，維護需求與其他工作成果的一致性，并控制需求的變更，主要體現在跟蹤和控制需求變更管理 。需求管理是開發工作有效進行的保證，是一種很高層次的系統行為，涉及整個開發過程和產品本身 。
需求分析的方法
需求分析方法由對軟件問題的信息域和功能域的系統分析過程及其表示方法組成，大多數的需求分析方法是由信息驅動的 。信息域具有三種屬性： 信息流、信息內容和信息結構 。
常用的需求分析方法有：面向數據流的結構化分析方法（SA），面向數據結構的Jackson方法（JSD），面向數據結構的結構化數據系統開發方法（DSSD），面向對象的分析方法（OOA）等 。選擇那種方法要根據哪些資源在什么時間對開發人員有效，不能盲目套用 。這里著重闡述面向數據流的結構化分析方法（SA） 。
面向數據流的結構化分析方法
面向數據流的結構化分析方法（Structured Analysis，簡稱SA），是面向數據流進行需求分析的方法，是需求分析使用最多的方法之一 。SA也是一種建?；顒樱摲椒ㄊ褂煤唵我鬃x符號，根據軟件內部數據傳遞、變換的關系 ， 自頂向下逐層分解，描繪出滿足功能要求的軟件模型 。適用于數據處理類型軟件的需求分析 ， 這一方法除了簡單，容易掌握之外 ， 還能和設計階段的結構化設計（SD）銜接，從而取得良好的設計結果 。
自頂向下逐層分解的分析策略
SA方法的基本手段：“分解”和“抽象” 。這是系統開發技術中控制復雜性的兩種手段 。它先將系統“抽象”成一個模型，此模型是有輸入和輸出并有系統名稱的盒子，然后打開這個盒子，對它進行逐層分解 ， 直到能被理解，可以實現為止 。因此分析的策略是自頂向下，逐層加細 ， 由抽象到具體的過程 。如圖2 。
結構化分析方法使用工具
SA方法利用圖形等半形式化的描述方式表達需求，簡明易懂，用它們形成需求規格說明書中的主要部分 。描述工具是
1) 數據流圖：描述系統由哪幾部分組成，各部分之間有什么聯系等等 。2) 數據字典：定義了數據流圖中每一個圖形元素 。
3) 描述加工邏輯的結構化語言、判定表、判定樹：詳細描述數據流圖中不能被再分解的每一個加工 。
由于分析中的主要依據是數據傳遞及數據變換所形成的數據流，所以結構化分析一般采用的方法是使用數據流圖的分析方法，最終結果是產生需求規格說明書 ， 該文檔包括一套數據流圖，對數據流圖中的成分進行定義的一本數據字典及對加工邏輯的描述 。
結構化分析步驟
用結構化分析方法進行系統需求分析的具體步驟是：1) 了解當前系統的工作流程，獲得當前系統的物理模型 。通過對當前系統的詳細調查，了解當前系統的工作過程，同時收集資料、文件、數據、報表等，將看到的、聽到的、收集到的信息和情況用圖形描述出來 。也就是用一個模型來反映自己對當前系統的理解 ， 如畫系統流程圖 。
2) 抽象出當前系統的邏輯模型 。物理模型反映了系統“怎么做”的具體實現 ， 去掉物理模型中非本質的因素，抽取出本質的因素，構造出當前系統的邏輯模型，反映了當前系統“做什么”的功能 。
3) 建立目標系統的邏輯模型 。分析、比較目標系統與當前系統邏輯上的差別，明確目標系統到底要“做什么”，從而從當前系統的邏輯模型導出目標系統的邏輯模型 。
4) 作進一步補充和優化 。為了對目標系統做完整的描述，還需要對得到的邏輯模型做一些補充 。
說明目標系統的人機界面 。
說明至今尚未詳細考慮的細節（包括出錯處理、系統的啟動與結束、系統的輸入/輸出和系統性能方面的需求等） 。
其他（系統特有的其他必須滿足的性能和限制 ， 也需要用適當的形式做出書面記錄 。分析階段結束時，系統分析員必須和用戶再次認真地審查系統文件，爭取在系統開始設計之前，盡可能地發現其中存在的一些錯誤并及時糾正，直至用戶確認這個模型表達了他們的要求后，系統文件（軟件需求規格說明書等）才作為用戶和軟件開發人員之間的“合同”而最后得到確定 。
結構化分析方法的優缺點
1) 優點： 結構化分析方法是軟件需求分析中公認的、有成效的、技術成熟的、使用廣泛的一種方法，它較適合于開發數據處理類型軟件的需求分析，該方法利用圖形等半形式化工具表達需求，簡明易讀，也易于使用，為后一階段的設計、測試、評價提供了有利條件 。2) 缺點：① 傳統的SA方法主要用于數據處理方面的問題，主要工具DFD體現了系統“做什么”的功能，但它僅是一個靜態模型，沒有反映處理的順序，即控制流程 。因此，不適合描述實時控制系統 。② 上世紀60年代末出現的數據庫技術，使許多大型數據處理系統中的數據都組織成數據庫的形式，SA方法使用DFD在分析與描述“數據要求”方面是有局限的 ， DFD應與數據庫技術中的實體聯系圖(ER圖)結合起來(如同IDEF0功能模型與IDEF1信息模型相結合一樣) 。ER圖能增加對數據存儲的細節以及數據與數據之間，數據與處理過程之間關系的理解，還解決了在DD中所包含的數據內容表示問題，這樣才能較完整的描述用戶對系統的需求 。③ 對于一些頻繁的人機交互的軟件系統，如飛機訂票、銀行管理等系統，用戶最關系的是如何使用它，輸入命令、操作方式、系統響應方式、輸出格式等都是用戶需求的重要方面，DFD不適合描述人機界面系統的需求，SA方法往往對這一部分用自然語言作補充 。④ 描述軟件需求的精確性有待提高 。5 需求的變更
在開發項目過程中，用戶隨時會提出一些新的需求，要求開發方解決 ， 這些需求的提出，有時在開發階段中有時在開發階段后 。這種在需求分析的兩個相鄰子階段中，或者在迭代周期的需求分析中，后一段或周期的需求分析結果與前一次不一致，我們把這種不一致稱為需求變更 。產生需求變更的原因主要有以下幾個方面：1) 在需求分析階段，開發方與用戶的溝通不夠 。在需求分析階段，開發方與用戶沒有很好的交流 ， 開發方就根據用戶提供的大概信息 ， 自己推導出用戶的需求 。通過這種需求分析得出的需求往往會和用戶的實際需求相差甚遠，導致用戶提出更改需求 。2) 項目的實施周期過長 。隨著時間的推移，用戶對整個系統的了解也越來越深入 。他們會對模塊的界面、功能和性能方面提出更高更多的要求 。3) 技術更新過快 。由于技術的快速更新， 企業可能引進一些新的設備，而這些設備可能就會與我們的目標系統有直接的關系，由于這一變化可能發生在解決用戶原先問題之前或者之中，那么開發方不得不加入這一新的需求 。[3]
為了盡可能地避免發生需求變更 ， 以及保證需求分析的高穩定性，可以采用以下方法：1) 分工明確，系統分析員和程序員各有不同的職責 。系統分析員處在用戶和程序員之間，溝通用戶和開發人員的認識和見解 。系統分析員一方面要協助用戶對所開發的軟件提出需求，另一方面還要和程序員充分交換意見，探討其合理性和實現的可能性 。如圖3所示，系統分析員在需求分析階段起著重要的作用 。
2) 開發方與用戶進行協作和交流 。在用戶提出需求變更時系統分析員應該認真聽取用戶的要求并加以整理和分析 。分析需求變更的原因并提出可行的替代方案；同時向用戶說明這些需求變更會對整個項目的開發帶來的不良后果 。3) 合同約束 。由于需求變更可能會對整個項目產生影響，所以，開發方和用戶在簽定項目合同時，可以對需求變更增加一些相關的合同條款 。4) 建立需求文檔并進行版本控制 。需求分析的最終成果是一份客戶和開發方對所開發的產品達成共識的系統文檔 。有了這份文檔，即使開發方人員的角色有所變動 ， 也不會對需求分析的前期工作有所影響 。對每次的需求變更都用一個新的版本來標識 。5) 需求評審和設立需求基線 。為了讓開發方詳細了解用戶的需求，讓不同人員從不同的角度對需求進行驗證，作為需求的提出者（用戶方），在需求評審過程中，往往能提出許多有價值的意見，同時，也是對需求進行最后確認的機會，可以有效減少需求變更的發生 。需求在通過正式評審和批準之后，應該確定需求基線 ， 進一步的需求變更將在此基線的基礎上，依照項目定義的變更過程進行 。設置需求基線可以將變更引起的麻煩減至最小 。
軟件架構（software
architecture）是一系列相關的抽象模式，用于指導大型軟件系統各個方面的設計 。軟件架構是一個系統的草圖 。軟件架構描述的對象是直接構成系
統的抽象組件 。各個組件之間的連接則明確和相對細致地描述組件之間的通訊 。在實現階段 ， 這些抽象組件被細化為實際的組件，比如具體某個類或者對象 。在面向
對象領域中，組件之間的連接通常用接口_(計算機科學)來實現 。
軟件體系結構是構建計算機軟件實踐的基礎 。與建筑師設定建筑項目的設計原則和目標，作為繪圖員畫圖的基礎一樣，一個軟件架構師或者系統架構師陳述軟件構架以作為滿足不同客戶需求的實際系統設計方案的基礎 。
軟件構架是一個容易理解的概念，多數工程師（尤其是經驗不多的工程師）會從直覺上來認識它，但要給出精確的定義很困難 。特別是 ， 很難明確地區分設計和構架：構架屬于設計的一方面，它集中于某些具體的特征 。
在“軟件構架簡介”中，David Garlan 和 Mary Shaw
認為軟件構架是有關如下問題的設計層次：“在計算的算法和數據結構之外 ， 設計并確定系統整體結構成為了新的問題 。結構問題包括總體組織結構和全局控制結
構；通信、同步和數據訪問的協議；設計元素的功能分配；物理分布；設計元素的組成；定標與性能；備選設計的選擇 。
但構架不僅是結構；IEEE Working Group
on Architecture 把其定義為“系統在其環境中的最高層概念” 。構架還包括“符合”系統完整性、經濟約束條件、審美需求和樣式 。它并不僅注
重對內部的考慮，而且還在系統的用戶環境和開發環境中對系統進行整體考慮 ， 即同時注重對外部的考慮 。
在Rational Unified Process 中，軟件系統的構架（在某一給定點）是指系統重要構件的組織或結構，這些重要構件通過接口與不斷減小的構件與接口所組成的構件進行交互 。
從和目的、主題、材料和結構的聯系上來說，軟件架構可以和建筑物的架構相比擬 。一個軟件架構師需要有廣泛的軟件理論知識和相應的經驗來事實和管
理軟件產品的高級設計 。軟件架構師定義和設計軟件的模塊化 ， 模塊之間的交互，用戶界面風格，對外接口方法，創新的設計特性，以及高層事物的對象操作、邏輯
和流程 。
一般而言，軟件系統的架構（Architecture）有兩個要素：
它是一個軟件系統從整體到部分的最高層次的劃分 。
一個系統通常是由元件組成的 ， 而這些元件如何形成、相互之間如何發生作用，則是關于這個系統本身結構的重要信息 。
詳細地說，就是要包括架構元件（Architecture Component）、聯結器（Connector）、任務流（Task-flow） 。
所謂架構元素，也就是組成系統的核心"磚瓦"，而聯結器則描述這些元件之間通訊的路徑、通訊的機制、通訊的預期結果，任務流則描述系統如何使用這些元件和
聯結器完成某一項需求 。
建造一個系統所作出的最高層次的、以后難以更改的，商業的和技術的決定 。
建造一個系統之前會有很多的重要決定需要事先作出 ， 而一旦系統開始進行詳細設計甚至建造，這些決定就很難更改甚至無法更改 。顯然，這樣的決定必定是有關系統設計成敗的最重要決定，必須經過非常慎重的研究和考察 。
對于較大的通常應用應該使用框架，可能節省不少時間. 。能使你很輕松的開發出一款軟件來 。
（軟件開發一般比較會關注設計模式而不是架構設計）
軟件的需求分析怎么寫?。?/h3>【軟件需求分析_軟件的需求分析怎么寫??？】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. 其他需求
可使用性:要求容易使用,界面友好
安全保密性:因本數據屬于公司內部管理用關鍵數據,因此除公司管理人員外,其他人員不得訪問.要求設有登錄密碼檢驗功能,并且此密碼可以在以后進行修改
可維護性:要求本軟件的維護文檔齊全,便于維護