• <wbr id="xevta"><center id="xevta"></center></wbr>
    <wbr id="xevta"><center id="xevta"></center></wbr>
    1. <table id="xevta"><button id="xevta"></button></table>
    2. <i id="xevta"></i>

      軟件開發需求文檔需要畫用例圖嗎(軟件工程需求文檔怎么寫)

      軟件開發 921
      今天給各位分享軟件開發需求文檔需要畫用例圖嗎的知識,其中也會對軟件工程需求文檔怎么寫進行解釋,如果能碰巧解決你現在面臨的問題,別忘了關注本站,現在開始吧!本文目錄一覽: 1、我們應當怎樣做需求分析:功能角色分析與用例圖

      今天給各位分享軟件開發需求文檔需要畫用例圖嗎的知識,其中也會對軟件工程需求文檔怎么寫進行解釋,如果能碰巧解決你現在面臨的問題,別忘了關注本站,現在開始吧!

      本文目錄一覽:

      我們應當怎樣做需求分析:功能角色分析與用例圖

      在我們進行一系列需求調研工作的同時,我們的需求分析工作也開始啟動了。需求調研與需求分析工作應當是相輔相伴共同進行的。每次參加完需求調研回到公司,我們就應當對需求調研的成果進行一次需求分析。當下一次開始進行需求調研時,我們應當首先將上次需求分析的結果與客戶進行確認,同時對需求分析中提出的疑問交給客戶予以解答。這就是一個需求捕獲-需求整理-需求驗證-再需求捕獲的過程。

      但是,當我們經過一番忙碌,將需求中的第一手資料從調研現場捕獲回來以后,我們應當怎樣進行分析呢?不少團隊對此都比較迷茫,沒有一個統一和有效的方法,往往采用想到哪里做到哪里的方式。一些問題想到了就做了,沒有想到則忽略掉了。實際上,需求分析不應當是太公釣魚,而應當是拉網排查。任何一個疏忽都可能對項目研發帶來風險。因此,我們應當采用一套成熟而完整的分析方法,穩步而有序地完成這部分工作。不同類型的軟件項目其分析方法可能存在差異,但一般來說,信息化管理類軟件項目通常從這幾個方面著手分析:功能角色分析、業務流程分析與業務領域分析。?

      需求分析不是一項一蹴而就就可以完成的工作,它需要一個長期的過程,而這個過程是一個由粗到細的過程,它體現了人類認識事物的客觀規律。在需求分析的初期,我們對需求的認識往往是整體的、宏觀的,隨著分析工作的逐漸深入,一步步細化。按照這個思路,我們對需求的分析,首先應當從功能角色分析開始。所謂功能角色分析,就是從一個外部用戶的視角分析整個軟件系統能夠提供的功能,以及這些功能到底是提供給哪些角色使用。?

      對一個系統進行功能和角色方面的梳理和分析,可以采用的比較主流的方法之一就是繪制用例圖。用例圖是UML的4+1視圖中的一種,準確地說就是那個“+1”。用例圖是貫穿整個面向對象分析/設計(OOA/D)的核心視圖,它描述的是系統到底為用戶提供了哪些功能,以及到底是哪些用戶在使用這些功能,是溝通用戶與技術人員的橋梁。運用用例視圖對業務需求進行分析、抽象、整理、提煉,進而形成抽象模型的過程稱之為用例建模,而這個模型就是用例模型。?

      一般地,在一個用例圖中通常有三種元素:參與者(Actor)、用例(Use Case)與系統邊界(Boundary)。用例描述的是系統為用戶提供的功能,也就是系統能為用戶做什么,通常被繪制成一個橢圓;參與者,我認為稱為角色更加合適,也就是系統為哪些類型的用戶提供服務,他們都各自承擔哪些不同的職責,通常被繪制成一個小人兒;最后是系統邊界,也就是系統是對現實世界哪個范圍的內容進行的模擬,它涉及到軟件設計的工作范圍與工作量,通常被繪制成一個方框。但是,通常情況下系統邊界只是一個概念而不用真正繪制出來,因為被繪制成用例的必然是系統內部的功能,被繪制成參與者的必然是系統外部事物。從這個意義上講,用例圖中的參與者不僅包括人,還包括那些外部系統和自動觸發器。根據這樣一個思路,我以往常常將外部系統和自動觸發器繪制成一個小人,這常常令客戶感到困惑。隨后我改變了思路,將外部系統和自動觸發器繪制成另一種表達形式——類元符號表示法,并在構造型上標注為Actor。?

      上圖是一個考核系統中一個子模塊的用例圖。圖中的用例就是這個系統提供給用戶的各項功能。注意,這里僅僅是在羅列功能而不表示它們之間諸如流程調用等相互關系,這是一些初學者常常犯的毛病。參與者與用例通過實線關聯起來,代表的是一種使用關系。箭頭代表的是一種導航,即動作施與的方向。在這個用例圖中,普通用戶執行查詢操作,查詢系統提供的“預警監控單項查詢”、“預警監控匯總查詢”等查詢報表;每日自動觸發器觸發自動考核功能,自動考核功能從“稅收征管系統”這樣一個外部系統中采集數據。?

      在繪制用例圖時一個值得思考的細節是,用例是怎樣通過分析獲得的。這個問題,在一些客戶對信息化管理比較有經驗的項目中不存在問題,因為在客戶提供給我們的需求文檔中就清晰地劃分出了一項一項的功能。這些功能可能會在日后的需求分析工作中有所調整,但它從整體上形成了一個雛形,成為我們進行用例分析進而形成用例的依據。?

      有人說,我們繪制的用例圖拿給客戶看不懂。這樣一個清晰明了的用例圖,輔之以我們對圖形的描述,客戶怎么會看不懂呢?關鍵問題在于,我們沒有將用例圖的精髓弄明白,再加上出現一些常見問題,使得用例圖畫得不倫不類,客戶當然就看不明白了?,F在我們看看用例繪制都有些什么常見問題。?

      1. 沒有正確理解用例圖的視角。前面我反復強調了,用例圖的視角是用戶,也就是說,站在用戶的角度來觀察的我們需要設計的系統。從這個視角,用戶看到的系統是什么呢?當然是一項一項的功能,這些功能是客戶能夠理解的、具體的、對客戶存在價值的功能。從這個意義上說,那些技術性的功能不應當出現在這里,或者應當描述為用戶可以理解的文字,比如“自動考核”。而那些應當繪制的用例,在取名時也應當站在用戶角度去取名。舉個簡單的例子,一個員工檔案信息系統,以往我們總愛將用例取名為“添加員工信息”、“更新員工信息”、“刪除員工信息”,這就是典型的技術人員編寫的用例?!疤砑訂T工信息”對于用戶來講應當是做什么呢——填寫新員工資料;“更新員工信息”對于用戶來講又是做什么呢——更改員工資料;“刪除員工信息”又是什么呢——員工注銷。不論是“填寫新員工資料”、“更改員工資料”,還是“員工注銷”,對于客戶都是日常工作中需要完成的操作,將用例命名為這些名字必然為用戶所理解。同時,每一個用例對于用戶來說應當是有價值的,也就是說,用戶使用這個功能是要完成一項操作,或獲得什么信息。比如上圖的“自動考核”會產生一批考核結果,執行“預警監控單項查詢”可以獲得預警監控結果數據。?

      2. 圖形繪制雜亂無章。一個系統,特別是一個大型系統,提供給用戶的功能是繁雜的。如果你想將所有的功能,不管粗的細的,都試圖繪制在一個用例圖中,幾乎沒人看得懂。我們之所以將分析設計圖形化,是因為圖形能給人形象立體的感官,使人立即就明白了其中的意思,但前提是,這個圖形是主題清晰的、形象生動的。因此,我們繪制用例圖要學會拆分,由粗到細地一個一個繪制。先整體的繪制,再劃分成各個模塊一個一個詳細繪制,再進一步細化。所以,描述一個系統應當有許許多多的用例圖。?

      3. 用例是一個場景。在現實世界中,我們常常面對的是一個個長而復雜的操作流程,但在軟件世界里,我們要將它們拆分成一個個的用例,怎樣拆分?一個用例必須有一個場景,也就是時間相近、地點單一的一系列操作,并且這些操作最終應當有一個明確的結果。?

      如上所示這個用例圖,“申辯申請”就是過錯責任人填寫了一張申辯申請單,最終的結果是將申辯申請單提交給考核管理員;“申辯受理”就是考核管理員接收了過錯責任人的申辯申請單并予以受理,當然另一個結果是對其不予受理,該申請單被退回給過錯責任人。每個用例都有確定的場景,明確的目的和結果。?

      功能角色分析是對系統宏觀的、整體的需求分析,它用簡短的圖形繪制出了一個系統的整體輪廓。但僅僅進行功能角色分析是遠遠不夠的,我們還需要在它的基礎上做更加詳盡的分析。

      需求中如何畫用例圖

      UML用例圖用例圖主要用來圖示化系統的主事件流程,它主要用來描述客戶的需求,即用戶希望系統具備的完成一定功能的動作,通俗地理解用例就是軟件的功能模塊,所以是設計系統分析階段的起點,設計人員根據客戶的需求來創建和解釋用例圖,用來描述軟件應具備哪些功能模塊以及這些模塊之間的調用關系,用例圖包含了用例和參與者,用例之間用關聯來連接以求把系統的整個結構和功能反映給非技術人員(通常是軟件的用戶),對應的是軟件的結構和功能分解。 用例是從系統外部可見的行為,是系統為某一個或幾個參與者(Actor)提供的一段完整的服務。從原則上來講,用例之間都是獨立、并列的,它們之間并不存在著包含從屬關系。但是為了體現一些用例之間的業務關系,提高可維護性和一致性,用例之間可以抽象出包含(include)、擴展(extend)和泛(generalization)幾種關系。共性:都是從現有的用例中抽取出公共的那部分信息,作為一個單獨的用例,然后通后過不同的方法來重用這個公共的用例,以減少模型維護的工作量。 1、包含(include) 包含關系:使用包含(Inclusion)用例來封裝一組跨越多個用例的相似動作(行為片斷),以便多個基(Base)用例復用?;美刂婆c包含用例的關系,以及被包含用例的事件流是否會插入到基用例的事件流中?;美梢砸蕾嚢美龍绦械慕Y果,但是雙方都不能訪問對方的屬性。 包含關系對典型的應用就是復用,也就是定義中說的情景。但是有時當某用例的事件流過于復雜時,為了簡化用例的描述,我們也可以把某一段事件流抽象成為一個被包含的用例;相反,用例劃分太細時,也可以抽象出一個基用例,來包含這些細顆粒的用例。這種情況類似于在過程設計語言中,將程序的某一段算法封裝成一個子過程,然后再從主程序中調用這一子過程。 例如:業務中,總是存在著維護某某信息的功能,如果將它作為一個用例,那新建、編輯以及修改都要在用例詳述中描述,過于復雜;如果分成新建用例、編輯用例和刪除用例,則劃分太細。這時包含關系可以用來理清關系。 2、擴展(extend)擴展關系:將基用例中一段相對獨立并且可選的動作,用擴展(Extension)用例加以封裝,再讓它從基用例中聲明的擴展點(Extension Point)上進行擴展,從而使基用例行為更簡練和目標更集中。擴展用例為基用例添加新的行為。擴展用例可以訪問基用例的屬性,因此它能根據基用例中擴展點的當前狀態來判斷是否執行自己。但是擴展用例對基用例不可見。對于一個擴展用例,可以在基用例上有幾個擴展點。 例如,系統中允許用戶對查詢的結果進行導出、打印。對于查詢而言,能不能導出、打印查詢都是一樣的,導出、打印是不可見的。導入、打印和查詢相對獨立,而且為查詢添加了新行為。因此可以采用擴展關系來描述: 4、泛化(generalization) 泛化關系:子用例和父用例相似,但表現出更特別的行為;子用例將繼承父用例的所有結構、行為和關系。子用例可以使用父用例的一段行為,也可以重載它。父用例通常是抽象的。在實際應用中很少使用泛化關系,子用例中的特殊行為都可以作為父用例中的備選流存在。例如,業務中可能存在許多需要部門領導審批的事情,但是領導審批的流程是很相似的,這時可以做成泛化關系表示: 上面是我參考的一篇文章,覺得將三種關系的區別講得很清晰,在此基礎上結合自己的系統,對項目(在線購物系統)的用例做了整體的描繪。 ***************************************************************** (1)系統整體用例圖 (商品用例圖) (購買信息用例) (用戶資料用例) 按照先整體用例,后子系統用例來進行描繪的,歡迎大家提出好的建議! 轉:UML中擴展和泛化的區別 泛化表示類似于OO術語“繼承”或“多態”。UML中的Use Case泛化過程是將不同Use Case之間的可合并部分抽象成獨立的父Use Case,并將不可合并部分單獨成各自的子Use Case;包含以及擴展過程與泛化過程類似,但三者對用例關系的優化側重點是不同的。如下: ●泛化側重表示子用例間的互斥性; ●包含側重表示被包含用例對Actor提供服務的間接性; ●擴展側重表示擴展用例的觸發不定性;詳述如下: 既然用例是系統提供服務的UML表述,那么服務這個過程在所有用例場景中是必然發生的,但發生按照發生條件可分為如下兩種情況: ⒈無條件發生:肯定發生的; ⒉有條件發生:未必發生,發生與否取決于系統狀態; 因此,針對用例的三種關系結合系統狀態考慮,泛化與包含用例屬于無條件發生的用例,而擴展屬于有條件發生的用例。進一步,用例的存在是為Actor提供服務,但用例提供服務的方式可分為間接和直接兩種,依據于此,泛化中的子用例提供的是直接服務,而包含中的被包含用例提供的是間接服務。同樣,擴展用例提供的也是直接服務,但擴展用例的發生是有條件的。 另外一點需要提及的是:泛化中的子用例和擴展中的擴展用例均可以作為基本用例事件的備選擇流而存在。

      軟件開發流程過程中有很多圖分別都什么時候話

      軟件開發中都是使用UML圖來畫的,一共有9種。以下是使用Edraw億圖圖示畫的圖例。

      用例圖(user-case diagram):用來定義系統的功能需求。

      圖例:

      2.類圖(class diagram):對靜態結構的描述,用來定義系統中類和類之間的關系。

      圖例:

      3.對象圖:表示類的對象實例。通常用來示例一個復雜的類圖,通過對象圖反映真正的實例是什么,它們之間可能具有什么樣的關系,幫助對類的理解。

      圖例:

      4.狀態圖:類所描述事物的補充說明,類所有對象可能具有的狀態,以及引起狀態變化的事物。

      圖例:

      5.序列圖:反映若干對象之間的動態協作關系,在時間軸上,對象之間是如何交互的。

      圖例:

      6.協作圖:和序列圖作用相同,比序列圖多顯示了對象和它們之間的關系(上下文關系)。

      強調時間和序列則選擇序列圖;強調上下文相關則選擇協作圖。

      圖例:

      7.活動圖(activity diagram):反映一個連續的活動流,用于描述某個操作執行時的活動狀況。

      圖例:

      8.組件圖(component diagram):反映代碼的物理結構。

      圖例:

      9.展開圖(deployment diagram):用來顯示系統中軟件和硬件的物理構架。

      我在進行文檔管理系統的設計與開發,我現在進行到需求分析階段,如果用UML的話,應該畫些什么圖?謝謝

      簡單地了解一下UML設計中有的圖例及基本作用。首先對UML中的各個圖的功用做一個簡單介紹: 1、用例圖 描述角色以及角色與用例之間的連接關系。說明的是誰要使用系統,以及他們使用該系統可以做些什么。一個用例圖包含了多個模型元素,如系統、參與者和用例,并且顯示了這些元素之間的各種關系,如泛化、關聯和依賴。

      2、類圖 類圖是描述系統中的類,以及各個類之間的關系的靜態視圖。能夠讓我們在正確編寫代碼以前對系統有一個全面的認識。類圖是一種模型類型,確切的說,是一種靜態模型類型。 3、對象圖 與類圖極為相似,它是類圖的實例,對象圖顯示類的多個對象實例,而不是實際的類。它描述的不是類之間的關系,而是對象之間的關系。  

       4、活動圖 描述用例要求所要進行的活動,以及活動間的約束關系,有利于識別并行活動。能夠演示出系統中哪些地方存在功能,以及這些功能和系統中其他組件的功能如何共同滿足前面使用用例圖建模的商務需求。  

       5、狀態圖 描述類的對象所有可能的狀態,以及事件發生時狀態的轉移條件??梢圆东@對象、子系統和系統的生命周期。他們可以告知一個對象可以擁有的狀態,并且事件(如消息的接收、時間的流逝、錯誤、條件變為真等)會怎么隨著時間的推移來影響這些狀態。一個狀態圖應該連接到所有具有清晰的可標識狀態和復雜行為的類;該圖可以確定類的行為,以及該行為如何根據當前的狀態變化,也可以展示哪些事件將會改變類的對象的狀態。狀態圖是對類圖的補充。 6、序列圖 (順序圖) 序列圖是用來顯示你的參與者如何以一系列順序的步驟與系統的對象交互的模型。順序圖可以用來展示對象之間是如何進行交互的。順序圖將顯示的重點放在消息序列上,即強調消息是如何在對象之間被發送和接收的。

      7、協作圖 和序列圖相似,顯示對象間的動態合作關系??梢钥闯墒穷悎D和順序圖的交集,協作圖建模對象或者角色,以及它們彼此之間是如何通信的。如果強調時間和順序,則使用序列圖;如果強調上下級關系,則選擇協作圖;這兩種圖合稱為交互圖。

      8、構件圖 (組件圖) 描述代碼構件的物理結構以及各種構建之間的依賴關系。用來建模軟件的組件及其相互之間的關系,這些圖由構件標記符和構件之間的關系構成。在組件圖中,構件時軟件單個組成部分,它可以是一個文件,產品、可執行文件和腳本等。  

       9、部署圖 (配置圖) 是用來建模系統的物理部署。例如計算機和設備,以及它們之間是如何連接的。部署圖的使用者是開發人員、系統集成人員和測試人員。 一:這九種模型圖各有側重, 1:用例圖側重描述用戶需求, 2:類圖側重描述系統具體實現; 二:描述的方面都不相同, 1:類圖描述的是系統的結構, 2:序列圖描述的是系統的行為; 三:抽象的層次也不同, 1:構件圖描述系統的模塊結構,抽象層次較高, 2:類圖是描述具體模塊的結構,抽象層次一般, 3:對象圖描述了具體的模塊實現,抽象層次較低。 在有的文獻書籍中,將這九種模型圖分為三大類: 結構分類、動態行為和模型管理: 1:結構分類包括用例圖、類圖、對象圖、構件圖和部署圖, 2:動態行為包括狀態圖、活動圖、順序圖和協作圖, 3:模型管理則包含類圖。

      UML用例圖

      UML(Unified Modeling Language),統一建模語言,又稱標準建模語言,是為軟件系統建立可視化模型。主要包括用例圖、時序圖、協作圖、活動圖、部署圖、構件圖、類圖、狀態圖等等。

      之前有寫過UML時序圖: 產品經理必備之UML時序圖

      用例圖(Use Case Diagrame)是UML的一種,主要用來描述用戶、需求、系統功能之間的關系,能夠充分展示一個外部用戶能夠觀察的系統功能模型圖,以一種可視化的直觀方式理解系統的功能需求,以便使系統用戶更容易理解這些元素的用途,也便于開發人員最終實現這些元素。

      用例圖是跳出當前系統,站在用戶的角度去看系統,思考系統功能,這樣我們能更加理解業務,表達清楚需求。從用戶的視角,我們不會使用專業術語去進行業務的溝通,可以做到真正以用戶為中心去獲取需求,轉化為產品服務。

      用例圖可以幫助我們更全面的考慮系統內事物之間的互相影響,關注整體的運行規律,而不是只考慮個別事物的情況。

      1、參與者 :是系統外部的一個實體,它以某種方式參與了用例的執行過程。參與者不一定是人,也可以是部門,也可以是外部系統,也可以是其他事物。通常用人形圖標表示。

      2、用例 :是對系統的用戶需求(主要是功能需求)的描述,用例表達了系統的功能和所提供的服務,說明了系統是如何與最終用戶或其它系統互動,也就是誰可以用系統做什么,從而獲得一個明確的業務目標。通常用橢圓表示。

      用例注意事項:

      ? ?? 用例粒度的確定,沒有標準,只能根據實際情況分析。一個大型系統,可能會有上百個用例,一個小產品,也許只有幾個用例。

      ? ?? 一個用例是一個完整的使用場景,不是零散的動作步驟。比如,拿起手機打電話是個完整的場景,拿起手機只是一個步驟。

      ? ?? 一個用例有一個明確、獨立的目標,如果一個用例包括多個目標,則可再逐層細化出子用例。

      3、系統邊界 :將系統內外分開,參與者在外面,用例在里面。邊界內的用例,就是系統要實現的事情。通常用矩形框表示。

      4、關系:

      (1)關聯關系:用一條實線表示,這條實線一般有三種形式:無箭頭、有指向用例的箭頭、有指向執行者的箭頭。箭頭的方向代表了數據流向或誰啟動誰。

      (2)歸納(泛化)關系:表示參與者與參與者之間、用例與用例之間的關系。一個用例可以被特別列舉為一個或多個子用例,這被稱為用例泛化。

      ? ? ? ? 用帶空心箭頭的實線表示,箭頭指向被泛化的用例,即子用例指向父用例,泛化是從下到上的過程。(子用例繼承父用例所有的結構、行為和關系,是父用例的一種特殊形式。)

      (3)包含關系:表示用例與用例之間的關系,其中一個用例(父用例)的行為包含了另一個用例(子用例)的行為。

      ? ? ?用虛線箭頭+表示,箭頭指向被包含的用例。一般是父用例包含很大的范圍,專門抽出子用例來著重表達,又或者是復用用例。

      (4)擴展關系:表示用例與用例之間的關系,是在特定條件下,由擴展用例指向被擴展用例。

      ? ? ? 用虛線箭頭+extend字樣,箭頭指向被擴展的用例。拓展用例是在特定條件出現時,才會被執行的用例。

      1、不是每個需求都要畫用例圖,要視情況而定,簡單的需求完全可以不用畫。

      2、畫圖是為了表達、傳遞信息,當我們畫用例圖時,不管畫的多么酷炫,本質都是在分析業務場景、系統功能性需求,并描述出來。

      閱讀原文

      對產品經理感興趣的朋友,可以移步“ 需求管理 ”,期待共同交流。

      軟件開發需要編寫哪些文檔?

      這個問題沒有一定的,因為這里有多種因素

      如,開發階段、文檔化要求程度等,若是通過CMM評估的,文檔就較多

      一般的是按項目開發過程來分,基本的有

      可行性研究報告(若是一個新項目且未確定的或應客戶要求時需要,實際上大部份公司很少有這文檔)

      用戶需求說明書(用戶+開發人員共同確認)

      軟件需求規格說明書

      設計說明書(體系結構、詳細設計)

      測試用例

      用戶手冊

      實現代碼

      這些文檔中,包括一定的分析與設計圖形,如用例圖、數據庫結構、ER圖等

      當然項目計劃、測試計劃也應算在內

      其它的(如CMM要求的)

      風險、估算方面的,質量保證方面的、配置管理方面、定義的模板、度量數據庫等

      具體需要多少文檔就是要看項目實際

      這方面的東西,可參考一些軟件工程類的書

      關于軟件開發需求文檔需要畫用例圖嗎和軟件工程需求文檔怎么寫的介紹到此就結束了,不知道你從中找到你需要的信息了嗎 ?如果你還想了解更多這方面的信息,記得收藏關注本站。

      掃碼二維碼
      天天日天天爽_亚洲AV无码再现_男同高潮无码大尺度视频在线_国产私拍精品福利
    3. <wbr id="xevta"><center id="xevta"></center></wbr>
      <wbr id="xevta"><center id="xevta"></center></wbr>
      1. <table id="xevta"><button id="xevta"></button></table>
      2. <i id="xevta"></i>