368财神捕鱼

書名：項目實踐精解：IT項目的面向對象分析設計、開發及管理
作者名：梁立新雷玉廣編著
本章字數： 9字
更新時間： 2019-03-02 01:48:07

第3章軟件需求分析

3.1 軟件需求分析概述

需求分析是整個項目開發流程的第一個環節，它是在用戶和軟件開發組之間建立對用戶的共同理解，由軟件開發組進行分析、精化并詳細描述后，按文檔規范編寫出《軟件需求規格說明書》（Software Requirement Specification，SRS）的過程。

軟件需求分析特別重要。在軟件工程的歷史中，很長時間里人們一直認為需求分析是整個軟件工程中的一個簡單步驟，但在過去十多年中，越來越多的人認識到它是整個過程中最關鍵的一個過程。只有通過軟件需求分析，才能把軟件功能和性能的總體情況描述為具體的軟件需求規格說明，從而奠定軟件開發的基礎。許多大型應用系統的失敗，最后均歸結為需求分析的失敗：要么獲取需求的方法不當，使得需求分析不到位或不徹底，導致開發者反復多次地進行需求分析，致使設計、編碼、測試無法順利進行；要么客戶配合不好，導致客戶對需求不確認，或客戶需求不斷變化，同樣致使設計、編碼、測試無法順利進行。

需求分析是一項重要的工作，也是一項極為困難的工作。該階段的工作具有以下幾個特點。

（1）用戶與開發人員很難進行交流

在軟件生命周期中，其他4個階段都是面向軟件技術方面的，只有本階段是面向用戶的。需求分析是指對用戶的業務活動進行分析，以便明確在用戶的業務環境中軟件系統應該“做什么”。但是在開始時，開發人員和用戶雙方都不能準確地提出系統要“做什么”，因為軟件開發人員不是用戶問題領域的專家，不熟悉用戶的業務活動和業務環境，又不可能在短期內搞清楚；而用戶不熟悉計算機應用的有關問題。由于雙方互相不了解對方的工作，又缺乏共同語言，所以在交流時存在著隔閡。

（2）用戶的需求是動態變化的

對于一個大型而復雜的軟件系統，用戶很難精確、完整地提出它的功能和性能要求。一開始只能提出一個大概、模糊的功能，只有經過長時間的反復認識才逐步明確。有時進入到設計、編程階段才能明確，更有甚者，到開發后期還在提新的要求。這無疑給軟件開發帶來了許多困難。

（3）系統變更的代價呈非線性增長

需求分析是軟件開發的基礎。假定在該階段發現一個錯誤，解決它需要用一個小時的時間，到設計、編程、測試和維護階段解決，則要花費2.5、5、25甚至100倍的時間。

3.2 軟件需求分析過程

3.2.1 什么是軟件需求

從根本上講，軟件需求就是為了解決現實世界中的特定問題，軟件必須展現的屬性。

軟件需求包括兩部分：功能性需求和非功能性需求。雖然功能性需求是對軟件系統的一項基本需求，但卻并不是唯一的需求。除功能性需求外，軟件質量屬性的特性，稱為系統的非功能性需求。這些特性包括：系統的易用性、執行速度、可靠性，處理異常情況的能力與方式等。在決定系統的成功或失敗的因素中，滿足非功能性需求往往比滿足功能性需求更為重要。軟件需求的組成關系見圖3-1。

圖3-1 軟件需求的組成關系

軟件需求的屬性包括可驗證性、優先級、唯一性和定量化。

（1）可驗證性

可驗證性是軟件需求的基本屬性。軟件需求必須是可驗證的，否則軟件的評審和測試就沒有相應的依據。

（2）優先級

軟件需求具有優先級，應該能夠在資源有限（資金、人員、技術）的情況下進行取舍。

（3）唯一性

軟件需求應唯一地標識出來，以便在軟件配置管理和整個軟件生命周期中進行管理。

（4）定量化

軟件需求應盡可能地表述清楚，沒有二義性，并進行適當的量化，應避免含糊、無法測試、無法驗證的需求出現。軟件質量的可靠性和用戶界面的友好性等非功能性需求的量化尤為重要。例如，系統應支持2000個并發用戶，系統回應時間應低于10秒，這就是需求的量化。

3.2.2 需求過程中的角色

需求過程涉及各種角色的人員。需求分析人員應協調軟件開發人員和各領域內的專家共同完成需求過程。軟件的涉眾（牽涉到的角色）隨項目的不同而不同，但至少包括用戶（操作人員）和客戶。典型的需求過程中的角色如表3-1所示。

表3-1 需求過程中的角色

對于涉眾的各種需求通常很難完全滿足，系統分析師應根據預算、技術等條件進行取舍。

3.2.3 需求過程的迭代

軟件需求分析是一個不斷認識和逐步細化的過程。該過程將軟件計劃階段所確定的軟件范圍（工作范圍）逐步細化到可詳細定義的程度，并分析出各種不同的軟件元素，然后為這些元素找到可行的解決辦法。需求過程要適應客戶和項目的環境，并作為配置項納入配置管理。

當前的軟件業面臨著巨大的競爭壓力，要求軟件企業有更低的構建成本和更短的開發周期。有些項目受環境的影響很大，有些項目是對原有項目的升級，有些項目客戶要求在指定的架構下完成。在項目初期，客戶不能完全確定需要什么，對計算機的能力和限制不甚了解，所以需求過程很難是一步到位的過程。隨著項目的深入，需求將隨時間的推移而發生變化。

因此，需求過程是一個迭代的過程，每次迭代都提供更高質量和更詳細的軟件需求。這種迭代會給項目帶來一定的風險，上一次迭代的設計實現可能會因為需求不足而被推翻。但是，系統分析師應根據項目計劃，在給定的資源條件下得到盡可能高質量的需求。

在很多情況下，對需求的理解會隨著設計和實現的進行而不斷深入，這也會導致在軟件生命周期的后期重新修訂軟件需求。原因可能來自于錯誤的分析、客戶環境和業務流程的改變、市場趨勢的變化等。無論什么原因，系統分析師應認識到需求變化的必然性，并采取相應的措施減少需求變更對軟件系統的影響。需求的變更必須經過仔細的需求評審、需求跟蹤和比較分析后才能實施。

3.2.4 需求來源

理解問題域的第一步是提取需求，即確定需求的來源，識別軟件的涉眾，確立開發團隊與客戶間的關系。提取需求時，要求用戶與開發人員之間保持良好的溝通。

軟件的需求來源很多，我們要盡可能多地識別顯式的來源和潛在的來源，并評估這些來源對系統的影響。典型的來源包括以下5種。

（1）系統目的

系統目的是指軟件的整體目的或高層的目標。這是進行軟件開發的動機，但它們通常表達得比較模糊。系統分析師需要仔細地評估這些目標的價值和成本，對系統的整體目標進行可行性研究。

（2）行業知識

系統分析師需要獲取業務領域內的相關知識。因為涉眾對于通用的行業知識會一概而過，一些行業慣例需要系統分析師根據環境進行推斷。當需求發生矛盾時，系統分析師可以利用行業知識對各種需求進行權衡。

（3）軟件涉眾

應充分考慮不同軟件涉眾的需求，如果只強調某一角色的需求，忽略其他角色的需求，往往將導致軟件系統的失敗。系統分析師應從不同涉眾的角度去識別、表述他們的需求。用戶的文化差異、客戶的組織結構，常常會是系統難以正常實施的原因。

（4）運行環境

軟件的運行環境包括地域限制、實時性要求和網絡性能等。系統的可行性和軟件架構都依賴于這些環境需求。

（5）組織環境

軟件作為一個組織的業務流程支持工具，受到組織結構、企業文化和內部政策的影響。軟件的需求也與組織結構、企業文化和內部政策有關。

3.2.5 需求獲取方法

常用的需求獲取方法有：

（1）實地參加

通過親自參加業務工作來了解業務活動的情況。這種方法可以比較準確地理解用戶的需求，但比較耗費時間。

（2）開調查會

通過與用戶座談來了解業務活動情況及用戶需求。座談時，參加者之間可以相互啟發。

（3）請專人介紹

（4）面談

對于某些調查中的問題，可以找專人詢問。

（5）設計調查表請用戶填寫

如果調查表設計得合理，這種方法是很有效的，也很易于被用戶接受。

（6）查閱記錄

查閱與原系統有關的數據記錄，包括原始單據、賬簿、報表等。

通過調查了解獲取了用戶需求后，還需要進一步分析和表達用戶的需求。

3.2.6 軟件需求表達

如何有效地表達軟件需求？我們這里建議使用用例建模技術。用例建模技術是十多年來最重要的需求分析技術，在保障全球各類軟件的成功開發中發揮了極其重要的作用。實踐證明，用例技術是迄今為止最為深刻、準確和有效的系統功能需求描述方法。功能需求是指系統輸入到輸出的映射，以及它們的不同組合，任何功能必然要通過外部環境與系統之間的交互才能完成，因此，我們可以在內容和形式上把用例和系統的功能需求等同起來。

用例建模技術不同于結構化功能分解的特點有：

（1）顯式地表達用戶的任務目標層次，突出系統行為與用戶利益間的關系。

（2）通過描述執行實例情節（交互行為序列、正常/非正常事件流），能夠完整地反映軟件系統用以支持特定功能的行為。

（3）以契約（前/后置條件等）的形式突出了用戶和系統之間常常被忽略的背后關系。

（4）部署約束等非功能需求與系統行為直接綁定，能夠更準確地表達此類需求。

基于用例的需求表達體系如圖3-2所示。

圖3-2 基于用例的需求表達體系

1.用例圖

（1）用例圖概述

用例建模技術離不開用例圖。在UML中，用例圖又叫做用況圖，有時又稱為Use Case圖。它用于定義系統的行為、展示角色（系統的外部實體，即參入者）與用例（系統執行的服務）之間的相互作用。用例圖是需求和系統行為設計的高層模型，它以圖形化的方式描述外部實體對系統功能的感知。用例圖從用戶的角度來組織需求，每個用例描述一個特定的任務，如表3-2所示。

表3-2 用例圖概述

用例模型可以在不同層次上建立，具有不同的粒度。

（2）用例層次

我們把用例劃分為3個目標層次：概要層、用戶目標層和子功能層，并通過引入巧妙的Why/How技術幫助分析者找到合適的目標層次，從而可以有效地把握用例的粒度（真正的用例最終應落實到用戶目標層）。

值得注意的是，我們在實踐中應該尤其關注用戶目標層用例。引入概要層用例的主要目的是為了包含一個或多個用戶目標層用例，為系統提供全局功能視圖；提出子功能層用例，則是為了表達用戶目標層用例的具體實現步驟。

（3）用例范圍

根據范圍的不同，用例可分為業務用例和系統用例兩種。

① 業務用例

● 在業務中執行的一系列動作，這些動作為業務的個體主角產生具有可見價值的結果。

● 實質是業務流程。

● 可以分為核心業務用例，支持業務用例和管理業務用例。

● 主要包括業務角色、業務活動、業務實體、業務規則。

② 系統用例

● 是系統執行的一系列動作，這些動作將生產特定主角可觀測的結果值。

● 主要包括系統角色和系統的一系列交互過程。

當前的討論邊界（the System under Discussion，SuD）一般比較容易確定，那么如何從用例的范圍上判斷一個用例是系統用例還是業務用例呢？如果某個SuD或者用例的范圍包含了人及由人組成的團隊、部門、組織的活動，那么針對這個SuD寫出的用例必然是業務用例；如果該SuD僅僅是一些軟件、硬件、機電設備或由它們組成的系統，并不涉及人的業務活動，那么根據這個SuD寫出來的用例就是系統用例。

（4）用例關系

① 角色和角色之間

繼承關系：表示子類角色將繼承父類角色在用例中所能擔任的角色。

② 角色和用例之間

使用關系：表示角色將使用用例提供的服務。

③ 用例和用例之間

包含關系：通常是指一個大的用例包含了幾個小的用例，幾個小的用例組成一個大的用例。

擴展關系：基于擴展點之上的兩個獨立用例，擴展用例為基本用例的實例增添新的行為，其實質是擴展事件流的延伸，兩個用例本身都是獨立的。

繼承關系：父用例可以通過特化形成一個或多個子用例，這些子用例代表了父用例比較特殊的形式。子用例繼承父用例的所有結構、行為和關系。

表現用例關系的實例如圖3-3所示。

圖3-3 用例關系實例

2.用例描述

用例模型除了繪制用例圖外，還要對用例進行描述，也就是詳細展開每個用例的內容。用例描述可以是文字性的，也可以用活動圖進行說明。文字性的用例描述模板如表3-3 所示。以“借書登記”為例，其具體的用例描述如表3-4所示。

表3-3 用例描述模板

表3-4 借書登記用例描述

3.用例優先級

（1）為什么要設定需求的優先級

每一個具有有限資源的軟件項目必須理解所要求的特性、使用實例和功能需求的相對優先級。設定優先級意味著權衡每個需求的業務利益和它的費用，以及它所牽涉到的結構基礎和對產品的未來評價。項目經理必須權衡合理的項目范圍和進度安排，以及預算、人力資源及質量目標的約束。

設定優先級有助于項目經理解決沖突、安排階段性交付，并且做出必要的取舍。

● 當客戶的期望很高、開發時間短并且資源有限時，必須盡早確定所交付的產品應具備的最重要的功能。

● 建立每個功能的相對重要性有助于規劃軟件的構造，以最少的費用提供產品的最大功能。

● 當采用漸增式開發方式時，設定優先級就特別重要。因為在開發過程中，交付進度安排很緊，并且日期不可改變，必須排除或推遲一些不重要的功能。

（2）系統分析員的態度和做法

● 在需求分析階段，分析人員應該明確地提出需求的優先級和處理策略，并在《軟件需求規格說明書》中明確說明。

● 應當在項目的早期階段設定優先級，這有助于逐步做出相互協調的決策，而不是在最后階段匆忙決定。

● 評價優先級時，應該看到不同需求之間的內在聯系，以及它們與項目業務需求的一致性。

● 在判斷出需求的低優先級之前，如果開發人員已經實現了將近一半的特性和功能，那么這將是一種浪費，這個責任應該由分析人員承擔。

（3）設定優先級的方法

與在客觀世界中人們對事務的分類習慣與方法一致，系統需求的優先級設定分成3類。例如：高、中、低；基本的、條件的、可選的；3、2、1……

具體描述如表3-5所示。

表3-5 系統需求的優先級分類

3.2.7 需求評審

1.需求評審概述

需求評審是一項精益求精的技術，它主要由非軟件開發人員來進行。通過評審發現二義性的或不確定的需求，還有那些實際上是設計規格說明的所謂的“需求”，這些“需求”是不能作為設計基礎和依據的。需求評審也為風險承擔者們提供了在特定問題上達成共識的方法。

需求評審可以分為非正式評審和正式評審。

● 非正式評審：可以根據個人愛好的方式進行評審，包括在任何場合的交流、征求意見。它是非系統化的、不徹底的，或者在實施過程中具有不一致性。非正式評審不需要記錄備案，沒有人對提出的意見負責。

● 正式評審：正式技術評審的最好類型叫做審查，它遵循預先定義好的一系列步驟、過程及規定的方法和要求進行，評審內容需要記錄在案，正式評審小組的成員對評審的質量負責。

2.需求評審過程

（1）確定參與者

① 審查參與者必須代表3個方面的觀點：

● 需求提出人員和產品代表者的觀點。

● 需求分析、開發、管理人員的觀點。

● 軟件設計、開發、測試、管理人員的觀點。

② 審查組中的審查人員應限制在7個人左右或者更少。

③ 審查的工作基礎是《軟件需求規格說明書》。

（2）參與者扮演的角色

① 作者：創建或維護正在被審查的產品。作者在審查中卻起著被動的作用，作者經常可以發現其他審查員沒有覺察到的錯誤。

② 協調者：與作者一起為審查制訂計劃，組織與協調各種活動，并且推進審查會的進行。督促作者對需求文檔做出建議性的更改，以保證向執行者明確說明在審查過程中提出的問題和缺陷。

③ 讀者：扮演審查員的角色。在審查會進行期間，讀者一次審查規格說明中的一塊內容，并做出解釋，而且允許其他審查員在審查時提出問題。對于一份需求規格說明，審查員每次必須對需求給出注解或一個簡短評論。通過用自己的話來陳述，讀者可能做出與其他審查員不同的解釋，這將有利于發現二義性或可能的錯誤。

④ 記錄員：用標準化的形式記錄在審查會中提出的問題和缺陷。

（3）審查階段流程（見圖3-4）

圖3-4 審查階段流程

（4）進入和退出審查的標準

① 文檔進入審查的標準：

● 文檔符合標準模板。

● 文檔已經做過拼寫檢查和語法檢查。

● 作者已經檢查了文檔在版面上所存在的錯誤。

● 已經獲得了審查員所需要的先前系統的運行資料或確認所需要的參考文檔，例如系統需求規格說明。

● 在文檔中打印了行序號以方便對特定位置的查閱和標記。

● 所有未解決的問題都被標記為TBD（待確定）。

● 文檔中使用到的術語詞匯表已全部進行了說明。

② 文檔退出審查的標準：

● 已經明確闡述了審查員提出的所有問題。

● 已經正確修改了文檔。

● 修訂過的文檔已經進行了拼寫檢查和語法檢查。

● 所有TBD的問題已經全部解決，或者已經記錄下每個待確定問題的解決過程、目標日期和提出問題的人。

● 文檔已經錄入項目的配置管理系統。

● 已將審查過的資料送到有關歸檔部門。

（5）需求審查清單

① 《軟件需求規格說明書》審查清單：

● 組織和完整性。

● 正確性。

● 質量屬性。

● 可跟蹤性。

● 特殊的問題。

② 使用實例審查清單：

● Use Case是否是獨立的分散任務。

● Use Case的目標或價值度量是否明確。

● Use Case給操作者帶來的益處是否明確。

● Use Case是否處于抽象級別上，而不具有詳細的情節。

● Use Case中是否不包含設計和實現的細節。

● 是否記錄了所有可能的可選過程。

● 是否記錄了所有可能的例外條件。

● 是否存在一些普通的動作序列可以分解成獨立的Use Case。

● 是否簡明書寫、無二義性和完整地記錄了每個過程的對話。

● Use Case中的每個操作和步驟是否都與所執行的任務相關。

● Use Case中定義的每個過程是否都可行。

● Use Case中定義的每個過程是否都可確認。

3.3 軟件需求文檔及ERP系統需求規格說明書

接下來我們需要將上面的需求分析過程通過文檔記錄下來。軟件需求文檔雖然可以有各種不同的格式，但它的主要內容包括用例描述和界面導航圖。關于用例描述，前面已經做了詳細講解，接下來簡單介紹一下界面導航圖。

● 系統的界面導航關系，體現了系統對外的宏觀交互行為，實際上是系統外在行為最表層實現的一種全局視圖，因此也可以看做是系統典型協作的總體概貌描述。

● 可以在項目的較早階段，規劃系統的界面導航圖，描述用戶的操作將如何觸發系統從一個界面轉向其他界面的導航過程。

● 界面導航圖將靜態的界面原型連接成一體，在某種意義上是對需求的一種總體刻畫和闡釋，用戶往往可以從界面導航圖領會到系統功能的大體結構。

用戶界面的設計編入《軟件需求規格說明書》中既有好處也有壞處：

● 由于屏幕圖像和用戶界面構架是系統設計，而不是用戶需求，所以對它的關注可能使需求誤入歧途，也限制了開發人員的發揮。

● 但是探討屏幕圖像和用戶界面有助于精化需求，并使用戶對系統有親和感和現實感，有助于用戶需求的表述和交流。

● 一個合理的權衡點是，在《軟件需求規格說明書》中加入用戶界面組件的概念草圖，而在實現時并不一定要精確地遵循這些草圖模型。

ERP系統需求規格說明書

1 引言

1.1 編寫目的

此需求規格說明書對項目的背景、范圍、驗收標準和需求等信息進行說明，包括功能性需求和非功能性需求，確保對用戶需求的理解一致。

預期的讀者有（甲方）需求提供者、項目負責人、相關技術人員等，北京亞思晟商務科技有限公司（乙方）的項目組成員，包括項目經理、客戶經理、分析/設計/開發/測試等人員。

1.2 背景

本ERP系統是基于互聯網的應用軟件，是為東北某城市一大型工業生產企業提供的全面企業管理解決方案。其組成包括采購、銷售、生產、質量、人事、考勤、財務、檔案、設備、新品、基礎數據等模塊。此處將與生產相關的模塊功能進行詳細介紹。

1.3 定義

● 成品入庫分為兩種：一種為生產中的成品入庫，另一種為采購中的成品入庫。

● 凡是出庫須判斷現有庫存量，要審核的須審核后才能確認出庫。

● 半成品庫中，材料名稱指的是原材料庫中的“材質”，材質+規格可唯一判定該材料。

● 材料進廠指的是：“原材料在外加工后形成的半成品”進廠入庫。

● 轉序卡中的數量指的是：根據材料而得出投放數量，一批材料可對應多個轉序卡。

● 轉序卡中的成品入庫數量指的是：投放后該產品的實際入庫數量。當第一張轉序卡的剩余數量為零時，入庫的產品數量轉入下一張轉序卡。

● 轉序卡中的報廢數量指的是：投放后該產品的實際報廢或核銷數量。當第一張轉序卡的剩余數量為零時，報廢或核銷的產品數量轉入下一張轉序卡。

● 每張轉序卡中的剩余數量=投放數量-入庫數量-報廢或核銷數量。

● 材料請領是有計劃的一個投放。

● 成品庫中的零件號與其總承號同義，半成品庫中分為零件總承號、零件號。

● 返修品出庫與入庫要有對應關系，一次出庫可能多次入庫，總數量有對應關系。

● 廢品是有原因的報廢，須追究相關責任人；核銷是定期有針對性、有正當原因的處理。核銷必須有申請與審核，原因如銹蝕、產品件下線等多種。

● 實現盤點：只要單擊盤點，所有庫房同時凍結，接著所有庫房的期末數都凍結，時間點之后的所有單子不參加邏輯運算；然后生成一個所有庫房的期末數的盤點單，也就是期末數的匯總報表，然后打印。根據賬面的期末數（也就是盤點時的期末數）到各個庫房對實物數量進行核對，核對后出盤盈盤虧，查出原因及調整庫存數量后，才可以重新解凍，進行后面所有入出單子的邏輯運算。

● 所有的成品不一定都有半成品。

● 一個零件名稱可能有多個零件號。

● 盤盈數量加上現有庫存修改庫存數量。

● 現有庫存減去盤虧數量修改庫存數量。

1.4 參考資料

ERP系統理論和實踐

2 任務概述

2.1 目標

本ERP系統是基于互聯網的應用軟件，通過此系統可以實現采購、銷售、生產、質量、人事、考勤、財務、檔案、設備、新品管理等核心業務，實現企業各部門工作流程的優化重組，超越時間、空間和部門分隔的限制，建成一個精簡、高效、廉潔、公平的運作模式，以便全方位地實現企業優質、規范、透明、符合國際水準的管理。該軟件系統是一項獨立的軟件，整個項目外包給北京亞思晟商務科技有限公司來開發、維護。

2.2 用戶的特點

本軟件的最終用戶為企業內的日常使用者，操作人員和維護人員有較高的教育水平和技術專長，同時使用的用戶數量初步估計為100人左右。

2.3 假定和約束

假定此系統為自包含的，不過分依賴其他外部系統。本項目的開發期限為6個月。

3 需求規定

整體功能用例圖（Use Case Diagram），見圖1。

圖1

4 用例規格

4.1 公共信息管理

用例描述：

（1）角色：系統管理員

（2）前提條件：登錄

（3）主事件流

1. 單擊進入公共信息管理模塊

2. 單擊部門維護（S1）

3. 單擊員工基本信息（S2）

（4）分支事件流

S1: 部門維護（E1）

1. 添加部門

2. 修改部門

3. 刪除部門

4. 返回部門列表頁面

S2: 員工基本信息（E2）

1. 添加員工基本信息

2. 修改員工基本信息

3. 刪除員工基本信息

4. 返回員工列表頁面

（5）異常事件流

E1: 無法添加、修改、刪除部門

E2: 無法添加、修改、刪除員工

4.1.1 “部門維護”用戶界面

進入界面：單擊左側菜單欄中的“公共信息管理”，打開后單擊“部門維護”，進入“部門維護”界面，如圖2所示。

圖2

選中左側樹圖中的結點，如“總部”，然后單擊“添加部門”按鈕，將生成新的編號，在下面各輸入框內輸入相應信息，如圖3所示。

圖3

單擊“添加”按鈕，將在選中的部門下生成新的子部門。操作成功的界面如圖4所示。

圖4

注意：類別應填2、3等，指的是所在樹形結構中的級別，如2為在總部下面。

選中左側樹圖中的部門（如“總部”），然后單擊“操作”按鈕，可在右側修改或刪除此部門的信息，如圖5所示。

圖5

修改或刪除成功后的效果如圖6所示。

圖6

4.1.2 用戶界面

單擊左側的“公共信息管理”，打開菜單后單擊“員工基本信息”，進入“員工基本信息”界面，如圖7所示。

在“部門”下拉列表框中選中員工所在的部門，在輸入框內輸入員工姓名，然后單擊“保存”按鈕，如圖8所示。

保存成功后的界面如圖9所示。

圖7

圖8

圖9

4.2 基礎信息管理

用例描述：

（1）角色：庫房管理員

（2）前提條件：登錄

（3）主事件流

1. 單擊進入基本信息管理模塊

2. 單擊半成品庫（S1）

3. 單擊成品庫（S2）

4.單擊原材料庫（S3）

5. 單擊輔助材料庫（S4）

6. 單擊標準價庫（S5）

7. 單擊工具庫（S6）

8. 單擊工裝備件庫（S7）

9. 單擊工序基礎信息（S8）

10. 單擊定額基礎信息（S9）

（4）分支事件流

S1: 半成品庫（E1）

1. 添加半成品庫

2. 修改半成品庫

3. 刪除半成品庫

4. 返回半成品庫列表頁面

S2: 成品庫（E2）

1. 添加成品庫

2. 修改成品庫

3. 刪除成品庫

4. 返回成品庫列表頁面

S3: 原材料庫（E3）

1. 添加原材料庫

2. 修改原材料庫

3. 刪除原材料庫

4. 返回原材料庫列表頁面

S4: 輔助材料庫（E4）

1. 添加輔助材料庫

2. 修改輔助材料庫

3. 刪除輔助材料庫

4. 返回輔助材料庫列表信息

S5: 標準件庫（E5）

1. 添加標準件庫

2. 修改標準件庫

3. 刪除標準件庫

4. 返回標準件庫列表信息

S6: 工具庫（E6）

1. 添加工具庫

2. 修改工具庫

3. 刪除工具庫

4. 返回工具庫列表信息

S7: 工裝備件庫（E7）

1. 添加工裝備件庫

2. 修改工裝備件庫

3. 刪除工裝備件庫

4. 返回工裝備件庫列表信息

S8: 工序基礎信息（E8）

1. 添加工序基礎信息

2. 修改工序基礎信息

3. 刪除工序基礎信息

4. 返回工序列表頁面

S9: 定額基礎信息（E9）

1. 添加定額基礎信息

2. 修改定額基礎信息

3. 刪除定額基礎信息

4. 返回定額列表頁面

（5）異常事件流

E1: 無法添加、修改、刪除半成品庫

E2: 無法添加、修改、刪除成品庫

E3: 無法添加、修改、刪除原材料庫

E4: 無法添加、修改、刪除輔助材料庫

E5: 無法添加、修改、刪除標準件庫

E6: 無法添加、修改、刪除工具庫

E7: 無法添加、修改、刪除工裝備件庫

E8: 無法添加、修改、刪除工序基礎信息

E9: 無法添加、修改、刪除定額基礎信息

4.2.1 “半成品庫”用戶界面

單擊左側的“基礎信息管理”菜單，找到“半成品庫”，單擊后進入“半成品庫”維護界面，如圖10所示。

單擊“添加”按鈕，進入添加新半成品的界面，如圖11所示。

圖10

圖11

首先選擇公司，根據公司選擇零件總承號，然后添加對應的各項基本信息，如圖12所示。

圖12

說明：公司名稱與零件總承號可在基礎信息管理的“成品庫”中先維護，詳見4.2.2。

單擊“添加”按鈕，正確添加后，則在“提示”處顯示“1”，如圖13所示。

圖13

單擊“返回”，返回到“半成品庫”主界面。

單擊主界面中的“查看”按鈕，可查看當前記錄的詳細信息，同時也可修改當前記錄。

單擊主界面中的“新增廠家”，打開添加后，公司名稱不可改變，新增半成品信息。

單擊主界面中的“新增零件”，打開添加后，公司名稱與零件總承號不可改變，在此基礎上添加新的半成品信息，操作界面同“添加”。

選中主界面中的復選框后，單擊“刪除”按鈕，可直接刪除選中的記錄。

4.2.2 “成品庫”用戶界面

單擊左側“基礎信息管理”中的“成品庫”，進入成品庫管理界面，如圖14所示。

圖14

選中某個復選框，然后單擊“刪除”按鈕，即可刪除對應的記錄如圖15所示。

圖15

刪除成功后，界面如圖16所示。

圖16

單擊“添加”按鈕，進入添加界面，添加信息，如圖17所示。

圖17

注意：此處的查詢功能，是為查詢已有的公司而設的。在公司輸入框內輸入要查詢的公司名稱或某一部分，便可在“查詢”下拉列表框內查出相應的公司名稱，查出后需填寫到公司名稱處，才可保存。

查詢功能如圖18所示。

圖18

選擇時間控件時的界面如圖19所示。

添加成功后，“提示”處為“1”，界面如圖20所示。

圖19

圖20

單擊主界面中的“查看/修改”，進入“查看/修改”界面，如圖21所示。

圖21

單擊“修改”按鈕，可修改當前記錄，成功后，“提示”處為“1”，如圖22所示。

圖22

單擊“返回”按鈕返回主界面。單擊“新增公司”按鈕，進入的界面如圖23所示。

公司名稱不改變，新增產品信息。

圖23

單擊主界面上的“新增零件”按鈕，進入的界面如圖24所示。