一、簡 介
在進行本單位辦公自動化系統(tǒng)需求分析時創(chuàng)建了基于用戶、組織的部門結構、實際工作角色、權限種類、資源樹的五要素全排列需求分析方法，并進行了軟件的功能需求分析，以及授權本身的管理，該方法是對五個關鍵要素的重新抽象；我把它命名為五要素全排列需求分析方法，該方法可以較好地避免需求分析時考慮不周全，較多地避免問題隱藏于目標軟件中。
二、背景情況
目前煙草行業(yè)面臨我國加入WTO后國外煙草巨頭的沖擊，宏觀方面，行業(yè)內正在以驚人的速度進行全國范圍內的機構調整，為此導致工業(yè)企業(yè)的合并重組步伐加大，企業(yè)內部的機構調整頻度提高。同時，微觀方面，由于是在一個變動的時期，企業(yè)內部員工，特別是管理人員的工作分工調整十分頻繁，因此我們設計的軟件系統(tǒng)與組織機構的無關性顯得尤為重要，為了較為徹底地解決這個問題，近幾年通過“業(yè)務流程重組” 實現(xiàn)了企業(yè)內部經(jīng)營流程與組織機構設置低耦合的問題，在此基礎上設計的軟件系統(tǒng)的生命周期的到較好得延長，同時提高了軟件的可用性。這種方法理論上通是在部分企業(yè)實踐中起到了較好的效果，但是在很多企業(yè)因為經(jīng)營緊迫性等方面的問題，沒有時間來進行徹底的業(yè)務流程重組，進而許多項目匆匆上馬，最后導致項目失敗，然后更多企業(yè)看到其它企業(yè)的失敗后干脆進入長期等待。能不能讓設計的系統(tǒng)與企業(yè)的組織機構，與業(yè)務流程耦合度盡可能減少，進而提高軟件項目的成功率呢？
運用本文介紹的方法進行了單位的辦公自動化系統(tǒng)的需求分析，并設計施了該系統(tǒng)，進行實踐時系統(tǒng)采用了B/S體系結構，和J2EE平臺，從而適用于多種操作系統(tǒng)及多種數(shù)據(jù)庫系統(tǒng)。實施過程中經(jīng)歷了企業(yè)內部兩次全廠性的組織結構調整，經(jīng)歷了一次與其它企業(yè)的合并，三次變革不僅沒有造成系統(tǒng)停用，反而對三次變革起到了積極的作用，在三場變革中用該方法設計的軟件具有的強勁生命力得到了充分體現(xiàn)。
三、需求分析及其方法發(fā)展水平回顧
需求分析階段是信息系統(tǒng)開發(fā)最重要的階段?？蛻粜枨蠓治龅哪康氖擒浖a(chǎn)品的用戶要求，用戶需求包括顯性的需求和隱性的需求，顯性需求是指用戶能明確地表達出來的需求，隱性需求是指用戶不能明確表達出來的需求，這是因為用戶不很明白軟件系統(tǒng)的特點。雖然用戶有時不知道他要的軟件是什么樣，但是用戶知道什么樣的軟件不是他所要的，所以軟件開發(fā)商或供應商應該為澄清他的隱含需求，并滿足它。概括起來，需求分析有以下幾個目的：
1． 準確地理解和描述客戶提出的對軟件系統(tǒng)的顯性需求，并設法滿足之；
2． 挖掘客戶對軟件系統(tǒng)的隱性需求，并主動滿足之；
3． 為軟件系統(tǒng)的客戶化調整提供依據(jù)。
需求分析的任務：
1. 調查研究：了解系統(tǒng)需求、訪問用戶、考察現(xiàn)場；
2. 確定需求：功能需求、性能需求、可靠性需求、系統(tǒng)費用需求、安全和保密需求等；
3. 描述需求：已經(jīng)確定的需求應該得到清晰、準確的描述，以便建立起軟件開發(fā)商或供應商與用戶間的溝通平臺，通常都要在客戶需求調查與分析后用《客戶需求規(guī)格說明書》的形式將客戶的需求描述出來；
需求分析審核：作為需求分析的確認手段，在需求分析的最后對功能的正確性、完整性、系統(tǒng)性和清晰性給予評估。一般是檢查所確定的各項需求是否恰當，是否有相矛盾的情況，或是有多余重復的地方。
需求分析階段首先是了解和澄清用戶的需求，然后嚴格地定義被開發(fā)的軟件系統(tǒng)的需求規(guī)格說明書。一個組織進行信息系統(tǒng)更新或者重新建立一個信息系統(tǒng)的時候，系統(tǒng)需求分析奠定了整個項目的基礎。組織要保證信息系統(tǒng)項目的成功，準確的把握系統(tǒng)需求分析是關鍵的第一步。系統(tǒng)需求分析是一連串的處理過程。要一套有組織的方法來收集信息，找出使用者的需求。經(jīng)過提煉，將需求（資料的、功能的以及行為需求）模式化，最后得出一份需求報告。在這一過程中，系統(tǒng)開發(fā)者扮演的角色就是利用高度的溝通技巧、采取各種不同的形式，將潛在的需求發(fā)掘出來，將可能被誤解的或是模糊不清的信息加以澄清。
常用的軟件需求分析方法有面向數(shù)據(jù)流的結構化分析方法、面向數(shù)據(jù)結構的Jackson方法、面向對象的方法、原型法、已有文檔表格和文件抽樣法，訪問組織站點法，觀察工作環(huán)境法，問卷調查法，面談法， JRP(Joint Requirements Planning)法等。
這里僅列舉常用的需求分析方法，不再詳細介紹。
四、五要素全排列需求分析方法主要解決的問題
設計一個較大型的軟件常常會碰到這樣的問題：系統(tǒng)中的數(shù)據(jù)授權和功能的授權往往與應用該軟件的組織機構設置不盡相同，如果在軟件中將這些授權與組織機構設置成緊耦合關系，經(jīng)常造成因為組織機構頻繁調整導致軟件不能推廣運行，或者因為使用了某系統(tǒng)讓決策者變得更加難下決心去變更經(jīng)營管理的流程。
其它方面，如：權限管理方面存在的難題；受組織結構調整影響軟件猝死（停用）；現(xiàn)實中部分管理權限沒有規(guī)律或交叉授權；不能方便地實現(xiàn)權限管理的集中方式和分散方式切換；個別部門的撤銷使資源失去使用者造成信息丟失等。為了解決這些問題，很多人做出了研究和實踐，例如基于角色的模型，基于分組的模型等，均沒有較好得解決這些問題。
從五個經(jīng)過抽象的要素：用戶、組織、角色、權限、資源入手進行系統(tǒng)需求調研，經(jīng)過實踐證明還是比較成功的；角色、權限和資源三個要素不會有大的變動，人員和機構兩個要素的變動隨時發(fā)生，如何避免發(fā)生因為這兩個要素的變動給系統(tǒng)造成的停用危機是本方法要解決的問題，同時上述其它方面的問題也得到較好地改善。
五、五要素全排列需求分析方法介紹
核心思想：使用該方法在需求分析階段將用戶和組織兩個與系統(tǒng)緊耦合的要素解耦，使系統(tǒng)針對的資源與資源在系統(tǒng)中的流轉過程（權限）在目標系統(tǒng)中高度內聚，最終設計出能夠承受更大限度人員機構變動的系統(tǒng)，同時有效防止用戶隱含需求不被發(fā)現(xiàn)。
方法簡述：因為人員在系統(tǒng)中總是扮演某種角色的，同時業(yè)務邏輯希望面對的是系統(tǒng)中的角色，而非扮演角色的具體的人或組織，因此調研初期引入角色這一關鍵要素，調研過程中用這一要素盡可能疊代用戶和組織兩個要素，從而來削弱或解調耦合關系，使得用戶和組織通過角色與系統(tǒng)之間保持一種松散的關系。
本方法分如下步驟：
1．識別主要要素
本方法的核心是用戶、部門、角色、權限、資源五個基本要素，分別用U、D、R、P、M （User,Department，Role，Permission， Material）表示。首先要識別這些要素，亦即首先解決“有什么”的問題，可以通過向客戶代表詢問，象做判斷題一樣的方式對下列條目確認，然后幫助用戶列舉出五要素盡可能多的一些實例，最后幫助用戶加以抽象，確定目標系統(tǒng)的五個基本要素的內容。
1). 用戶U
a.系統(tǒng)管理員：負責分配由軟件開發(fā)人員開發(fā)的權限的管理權限給權限管理員。
b. 權限管理員：負責將分配給自己的管理權限分配給管理員。
c. 管理員：使用權限管理員分給自己的權限將該權限對應的資源授權普通用戶使用。
d. 普通用戶：在自己擁有的權限范圍內使用相應的資源。
e. 軟件開發(fā)人員：按照已有的資源，開發(fā)相應的權限模塊，包括分配權限的管理權限給權限管理員；權限管理員 分配權限給管理員；管理員分配資源使用權給普通用戶等權限模塊。
f.每個用戶都隸屬于一個部門，是一個或多個角色的成員。
g. 用戶對資源的權限表現(xiàn)為擁有一個權限記錄的集合，每個記錄表示了用戶對某范圍資源的操作。此權限集合是 由系統(tǒng)管理員、權限管理員或者管理員在行使權限時產(chǎn)生、修改或刪除，由用戶擁有。
2).部門D
a. 部門在組織內是樹形結構。
b. 有且只有一個根部門，根部門就是使用該軟件系統(tǒng)的組織。
c. 每個部門都有名稱、上級部門（根部門除外）、上級主管、部門負責人（可以是多個）、一定的成員，一般會 有僅隸屬于本部門的資源。
e. 部門可以有多個子部門，子部門還可以有多個子部門。
3).角色R
a. 每個角色有一個固定的名稱。
b. 每個角色至少有一個用戶。
c. 每個角色至少對一種資源有某種權限。
d.每個用戶分類[1).a至1).f]是一個角色。
e. 角色常常對應了一個權限集合。用戶可以通過加入角色，成為角色的成員，進而擁有權限集合。
4).權限P
a. 每個權限有一個名稱，有一個具體的意義，可以表示出誰（角色|部門|具體用戶）對什么資源可以進行哪些操 作。
b. 每個權限可以在至少一個資源上使用。
c. 每個權限可以授給某個部門的某個角色，不可以授給單獨的一個部門或一個角色，一般不直接授給某一個用戶 。如果需要授給單獨的一個部門或一個角色某個權限，可以使用“授給根部門的某個角色”，或“授給某個部門的 所有角色”的方式實現(xiàn)。
d. 授權時不指定具體的資源，則此授權是權限管理員授權給管理員
e. 授權時指定具體的資源，則此授權是管理員授權給普通用戶。
f. 授權可以擬向執(zhí)行，即收回授權。
g. 權限記錄。
1.權限記錄一般是正向權限，這樣可以降低權限記錄的復雜性。
2.權限記錄中確定了資源范圍，用戶如果擁有該權限記錄，則有對該權限記錄指定范圍內的所有資源的權限,同 時包括對資源進行哪些操作。
3.權限記錄能判斷包含關系，即一個權限記錄是否包含另外一個。
4.為了組織好權限記錄，建議采用權限集合的形式。
h. 權限有不同的類型，依據(jù)資源類型的種類，權限可以是數(shù)據(jù)權限，也可以是功能權限，特別地，對數(shù)據(jù)的管理 權限是一種功能權限，數(shù)據(jù)權限包括：讀、寫、添加、刪除等，功能權限主要指是否可以使用某功能。
5). 資源m
a. 資源包括數(shù)據(jù)資源和功能資源。
b. 資源使用樹狀管理，不同的資源在不同的樹上，資源在系統(tǒng)中以森林的形式存在
(在這里引入樹叢的概念，管理方式相似的樹稱為樹叢，森林可以由很多樹叢構成，也可以由一個樹叢構成)。
c. 每種資源對應有一個或多個權限。
e. 在資源樹上某一節(jié)點授權可以指定是對該節(jié)點還是對該節(jié)點下的所有分枝。
2．按照5)識別出的每個樹叢，按下面的方法進行全排列，分析步驟1中識別出的各要素之間的關系，形成一個列表。
如果說第一個階段解決"有什么"的問題，那么第二個階段解決"做什么"的問題。
要素之間的直接和間接關系全排列共有P51+P52+P53+P54=205種,每種排列對應未來軟件中的一個可能存在的功能模塊或用戶界面，這些排列表示的意義通過其它的需求分析方法調研，有些用戶是可以能明確地表達出來的，例如P51 +P52表示的是如下表的25類功能需求，如下表：
表1 p51+p52表示的功能需求
U
D
R
P
M
U
用戶管理需求分析
用戶與隸屬部門
用戶擁有的角色
用戶擁有的權限
用戶可使用的資源
D
部門擁有的用戶
部門管理需求分析
部門中有那些角色
部門擁有的權限
某部門擁有的資源
R
角色成員
某角色的部門分布
角色管理需求分析
某角色擁有的權限
某角色擁有的資源
P
某權限的管理者
有某權限的部門
擁有某權限的角色
權限管理需求分析
某權限針對的資源
M
資源擁有者
擁有資源的部門
擁有資源的角色
資源的權限
資源管理
表中的內容多數(shù)用戶是可以提出來的，這些排列在具體的系統(tǒng)中對應不同的功能及界面。然而P53，P54表示的是什么需求？在對用戶進行調研時用戶多數(shù)是不能明確提出來的，這一部分往往就是用戶的隱含需求，因為其它的需求分析方法多數(shù)是挖掘式的，所以很難保證用戶這些隱含需求能被調研出來，而本方法是先排列出來這些或許存在的功能，再進行調研，請用戶判斷是否需要，因此是不容易被忽略的。
例如：1. (d,p,m)的排列表示“以某部門擁有所有權限對應的所有資源的列表的形式的操作”一類的功能模塊，而(p,d,m)的排列則表示：對某權限分布在的部門擁有的相關資源進行操作” 2. (d,r,p,m)的排列表示的是“某部門的某角色擁有的權限對應那些資源”一類的功能模塊，而(m,p,r,d)表示的是“某資源的某權限在某角色中對應那些部門”一類的功能模塊。
事實上，如果把每種排列全部列出是沒有必要的，分析某類有共性的排列對應的現(xiàn)實意義如果不存在，可以用剪枝法直接忽略，進而降低調研的規(guī)模，但是使用剪枝法時一定要防止誤剪。
3. 進行疊代解耦
將步驟2產(chǎn)生的結果中包含部門的項盡可能使用該部門中的相應角色代換，將有關用戶的項盡可能使用該用戶所屬的某一角色代換，最終使得包含部門或包含用戶的項盡可能少，實際上最后包含部門的項僅剩下有關該部門的屬性項，最后包含用戶的項只剩下該用戶的屬性項，這一步起到了將用戶和組織兩個與系統(tǒng)緊耦合的要素解耦的作用。
4. 轉換成自然語言征求用戶意見
將步驟3形成的列表轉換成容易理解的自然語言與客戶溝通，讓客戶選擇是否需要該功能，如果用戶需要，請用戶描述并記錄。這一步驟起到了主動挖掘客戶對軟件系統(tǒng)的隱性需求作用。
5. 形成需求分析報告
根據(jù)步驟4用戶確認后的列表，編制出清晰、準確的描述，最終建立起軟件開發(fā)商或供應商與用戶間的一致意見，用《客戶需求規(guī)格說明書》的形式將客戶的需求描述出來。
6. 進行需求評審
六、結 論
1． 使用本方法解決了標題四中的主要問題，其它方面的問題得到了明顯改善。
2． 本方法適合多種信息工程的需求分析，特別適合致力于某一領域信息系統(tǒng)開發(fā)的軟件公司。采用此方法，開發(fā)同類項目越多，需求分析工作的效率越高。
3． 本方法最后形成的是一個高度靈活的權限模型，這樣的模型可以適用于非常多的系統(tǒng)，同樣適合其它大型軟件工程。
4． 在需求分析過程中，由于充分考慮到系統(tǒng)的設計與現(xiàn)實之間的聯(lián)系，因此與其它需求分析方法向比，提高了對需求分析人員的要求。在實際工作中，一般由資深的軟件分析和設計人員進行。
5． 由于需求分析工作本身的難度和重要性，此方法同樣要求用戶單位和需求分析人員對需求分析所有工作內容，引起足夠重視；科學安排需求分析工作步驟，某些步驟可以同時進行；所有工作步驟不得應付或疏忽。
七、需要進一步研究的問題
1．在一些系統(tǒng)中，除“對什么資源”進行“什么操作”之外，需要很多地使用工作流程，本能否適合有很多工作流程的系統(tǒng)需要進一步研究。
2. 是否可以將用戶、組織、角色三個要素作為一個要素，與權限、資源合在一起按照上述方法，形成三要素全排列法進行需求分析更有意義，尚需進一步研究。
3．使用本方法設計的系統(tǒng)會出現(xiàn)授權鏈的問題，而且鏈的層次深度不易控制，需要使用其它方法防止。
4．在使用本方法進行實踐過程中，發(fā)現(xiàn)該方法可以設計出相應的權限管理模型相當靈活，包括數(shù)據(jù)授權和功能授權等，應該進一步研究。
5．除使用剪枝法外，如果能夠有其它方法更有效降低全排列的規(guī)模，尚需探討。
八、參考資料
1． 馮玉琳 趙保華 軟件工程（第二版）；
2． 鄭人杰、殷人昆、陶永雷等《實用軟件工程》（第二版）；
3． Roger S.Pressman 《軟件工程：實踐者的研究方法》（第5版）；
4． 盧琳生 管理信息系統(tǒng)需求調研分析指南 www.51cmm.com （軟件工程專家網(wǎng)）；
5． 唐曉輝 編譯 系統(tǒng)需求分析方法－JRP法 www.ie56.com (浙江工業(yè)大學)。
