如何做軟件項(xiàng)目的需求分析

求分析 (KPAs)的框架(KPA的概念在討論CMM的書中有詳細(xì)的概念說(shuō)明)。關(guān)鍵過(guò)程區(qū)域構(gòu)了自動(dòng)和半自動(dòng)的支持。這些輔助工具就稱為CASE。需求分析都包括了哪些方法呢？這里列舉出在《需求分析》一書中推薦的一些方法，1)繪制系統(tǒng)關(guān)聯(lián)圖，這種關(guān)聯(lián)圖是用于定義系統(tǒng)與系統(tǒng)外部實(shí)體間的界限和接口的簡(jiǎn)單模型。同時(shí)它也明確了通過(guò)接口的信息流和物質(zhì)流。2)創(chuàng)建用戶接口原型，當(dāng)開發(fā)人員或用戶不能確定需求時(shí)，開發(fā)一個(gè)用戶接口原型—沖突之處。3)分析需求可行性，在允許的成本、性能要求下，分析每項(xiàng)需求實(shí)施的可行性，明確與每項(xiàng)需求實(shí)現(xiàn)相聯(lián)系的風(fēng)險(xiǎn)，包括與其它需求的沖突，對(duì)外界因素的依賴和技術(shù)障礙。4)確定需求的優(yōu)先級(jí)別，應(yīng)用分析方法來(lái)確定使用實(shí)例、產(chǎn)品特性或單項(xiàng)需求實(shí)現(xiàn)的優(yōu)先定的版本中加入每一項(xiàng)變更，并在那個(gè)版本計(jì)劃中作出需要的變更。5)為需求建立模型，需求的圖形分析模型是軟件需求規(guī)格說(shuō)明極好的補(bǔ)充說(shuō)明。它們模型包括數(shù)據(jù)流圖、實(shí)體關(guān)系圖、狀態(tài)變換圖、對(duì)話框圖、對(duì)象類及交互作用圖。6)創(chuàng)建數(shù)據(jù)字典，數(shù)據(jù)字典是對(duì)系統(tǒng)用到的所有數(shù)據(jù)項(xiàng)和結(jié)構(gòu)的定義，以確保開發(fā)人組是使用一致的定義和術(shù)語(yǔ)。分析和設(shè)計(jì)工具通常包括數(shù)據(jù)字典組件。7)使用質(zhì)量功能調(diào)配，(QFD)是一種高級(jí)系統(tǒng)技術(shù)，它將產(chǎn)品特性、屬性與對(duì)客戶的重要性聯(lián)系起來(lái)。該技術(shù)提供了一種分析方法以明確那些是客戶最為關(guān)注的特性。QFD將1996)。如，采用SRS模板、指明需求的來(lái)源、為每項(xiàng)需求注上標(biāo)號(hào)、記錄業(yè)務(wù)規(guī)范、創(chuàng)建需求跟模過(guò)業(yè)務(wù)建模，比如你了解企業(yè)的運(yùn)作模式就?是一種你腦海中的業(yè)務(wù)建模。但是大多數(shù)人都沒(méi)有科學(xué)的、系統(tǒng)的、文檔化的做過(guò)業(yè)務(wù)建模。業(yè)務(wù)建模的目的在于：了解目標(biāo)組織(將要在其中部署系統(tǒng)的組織)的結(jié)構(gòu)及機(jī)制。了解目標(biāo)組織中當(dāng)前存在的問(wèn)題并確定改進(jìn)的可能性。確?？蛻簟⒆罱K用戶和開發(fā)人員就目標(biāo)組織達(dá)成共識(shí)。導(dǎo)出支持目標(biāo)組織所需的業(yè)務(wù)需求。上面的話是不是很抽象呢，其實(shí)沒(méi)有什么復(fù)雜的：人和電腦是完全不同的思想(思維方式)。所以，原先適合人的業(yè)務(wù)流程對(duì)于計(jì)算機(jī)來(lái)說(shuō)可不一定合適的，為了最大限度的利用計(jì)算機(jī)，必須要了解原先的業(yè)務(wù)流程并對(duì)此加易改造(流程自動(dòng)化)，當(dāng)然這些動(dòng)作需要得到用戶的許可。有些人認(rèn)為說(shuō)只有ERP這種大系統(tǒng)才需要對(duì)業(yè)務(wù)流程進(jìn)行重組，但是實(shí)際所不同的只是改造的程度。業(yè)務(wù)建模很重要的一點(diǎn)是在分析企業(yè)流程的同時(shí)分析出基礎(chǔ)企業(yè)對(duì)象(CommonBusinessObject)(這個(gè)詞我翻譯的不好，如果大家有更好的翻譯，請(qǐng)告訴我)。任何企業(yè)都有最基礎(chǔ)的一些元素，例如銀行的CBO就有帳戶，制造業(yè)的CBO就有訂單等。有一次我研究多年的朋友告訴我一個(gè)秘訣，他說(shuō)，企業(yè)的CBO無(wú)非是4個(gè)：客戶、員工、產(chǎn)品和供應(yīng)商(銀行的供應(yīng)商應(yīng)該稱為同業(yè))。其他的所有CBO都是在這四個(gè)CBO的基礎(chǔ)上發(fā)展起來(lái)的。比如說(shuō)CBO中客戶和產(chǎn)品是多對(duì)多的關(guān)系，根據(jù)關(guān)系數(shù)據(jù)CBO的組合，不同的關(guān)系，能夠形成企業(yè)運(yùn)作的許許多多的CBO。CBO是做業(yè)務(wù)建模的基礎(chǔ)，在此基礎(chǔ)上，通過(guò)評(píng)估業(yè)務(wù)狀態(tài)，說(shuō)明當(dāng)前業(yè)務(wù)，確定業(yè)發(fā)領(lǐng)域模型等一系列在RUP中定義的工作流程實(shí)現(xiàn)業(yè)務(wù)建模的目標(biāo)。ation集中在用戶任務(wù)上—而不是集中在用戶接口上—有助于防止開發(fā)組由于草率處理設(shè)計(jì)問(wèn)題提供的信息(需求獲取)。同時(shí)，你將處理這些信息以理解它們，并把它們分成不同的類別，還要把客戶需求同可能的軟件需求相聯(lián)系(分析)。然后，你可以使客戶信息結(jié)構(gòu)化，并編寫成文檔和示意圖(說(shuō)明)。下一步，就可以讓客戶代表評(píng)審文檔并糾正存在的錯(cuò)誤(驗(yàn)集中處理并設(shè)定優(yōu)先級(jí)?，以避免一個(gè)不能帶來(lái)任何益處的無(wú)限大的項(xiàng)目。 (open-ended)的問(wèn)題有助于你更好地理解用戶目前的業(yè)務(wù)過(guò)程并且知道新系統(tǒng)如何幫助或改進(jìn)他們的工作。調(diào)查用戶任務(wù)可能遇到的變更，或者用戶需要使用系統(tǒng)其它可能的方式。求的開發(fā)和利用。是如何想的？詢問(wèn)問(wèn)題時(shí)，以“還有什么能”,”當(dāng)?時(shí)，將會(huì)發(fā)生什么”“你有沒(méi)有曾經(jīng)想過(guò)”,“有沒(méi)有人曾經(jīng)”為開頭。記下每一個(gè)需求的來(lái)源，這樣向下跟蹤直到發(fā)現(xiàn)特定的客戶?？蛻舻拈_始談?wù)摌I(yè)務(wù)，而你，就在一邊仔細(xì)的聆聽(tīng)吧。這一招就叫做“拋磚引玉”。item談?dòng)懻撌切枨蠹头治鲆韵魏螞_突或不一致性。確客戶沒(méi)有表達(dá)清楚但又想加入的特性或特征。Gause和Weinberg(1989)提出使用“上下客戶對(duì)這些問(wèn)題的回答諸如“產(chǎn)品要求怎樣的精確度”或“你能幫我解釋一下你為什么不同意某人的回答嗎？”這些回答可以更直接地認(rèn)識(shí)問(wèn)題，而這是封閉(close-end)問(wèn)題所不能做到的。多的交流方式(KielandCarmel1995)。與單個(gè)客戶或潛在的用戶組一起座談，對(duì)于業(yè)務(wù)軟件包或信息管理系統(tǒng)(MIS)的應(yīng)用來(lái)說(shuō)是一種傳統(tǒng)的需求來(lái)源。直接聘請(qǐng)用戶進(jìn)行獲取需求的過(guò)程是為項(xiàng)目獲得支持和買入(buy-in)的一種方式。并提取出潛在的邏輯關(guān)系。流程圖和決策樹是描述這些邏輯決策途徑的好方法。在需求獲取的過(guò)程中，你可能會(huì)發(fā)現(xiàn)對(duì)項(xiàng)目范圍的定義存在誤差，不是太大就是太小。需求主要是關(guān)于系統(tǒng)做什么，而解決方案如何實(shí)現(xiàn)是屬于設(shè)計(jì)的范圍。這樣說(shuō)雖然很簡(jiǎn)潔，不能代表絕大多數(shù)用戶的需要。最?好的權(quán)衡在于選擇一些授權(quán)為他們的用戶類發(fā)言的產(chǎn)品提示將會(huì)暗示你在需求獲取的過(guò)程中的返回點(diǎn)。1.如果用戶不能想出更多的使用實(shí)例，也許你就完成了收集需求的工作。用戶總是按其重要性的順序來(lái)確定使用實(shí)例的。2.如果用戶提出新的使用實(shí)例，但你可以從其它使用實(shí)例的相關(guān)功能需求中獲得這些復(fù)原先討論過(guò)的問(wèn)題，此時(shí)，也許你就完成了收集需求的工作。4.如果所提出的新需求比你已確定的需求的優(yōu)先級(jí)都低時(shí)，也許你就完成了收集需求的工作。5.如果用戶提出對(duì)將來(lái)產(chǎn)品的要求，而不是現(xiàn)在我們討論的特定產(chǎn)品，也許你就完成了收集需求的工作。成功的。化原型法進(jìn)行軟件項(xiàng)目需求分析前言：需求分析階段是管理信息系統(tǒng)(MIS)開發(fā)最重要的階段。MIS開發(fā)的需求階段首先Jackson向別MIS力MIS開發(fā)的公司。但作者在長(zhǎng)期的MIS需求分析過(guò)程中，發(fā)現(xiàn)原型法有以下缺陷：1)原型的設(shè)計(jì)和修改工作量大，增加了系統(tǒng)的開發(fā)成本；2)由于用戶不關(guān)心或不理解原型的概念和實(shí)現(xiàn)，而且存在較大期望，使得與實(shí)際系統(tǒng)不能反映實(shí)際系統(tǒng)的全貌；3)軟件需求主要包括：功能需求、界面需求、性能需求、環(huán)境需求、可靠性需求、安型難以表達(dá)軟件的后七項(xiàng)需求；4)原型法強(qiáng)調(diào)用戶和開發(fā)人員不斷對(duì)原型進(jìn)行不斷修改和補(bǔ)充，直到用戶感到滿意為MIS項(xiàng)目中，這種情況實(shí)際難以保證，特別是在用戶單位和開發(fā)單位距離較遠(yuǎn)時(shí)。管理信息系統(tǒng)項(xiàng)目實(shí)施的實(shí)踐，提出一種新的需求分析方法-簡(jiǎn)化原型法。這統(tǒng)原型。管理信息系統(tǒng)屬于數(shù)據(jù)庫(kù)應(yīng)用。數(shù)據(jù)庫(kù)應(yīng)用需求分析應(yīng)該圍繞數(shù)據(jù)，而不是功能展開，即5培訓(xùn)安排協(xié)議培訓(xùn)安排和技術(shù)服務(wù)承諾。系統(tǒng)的邊界規(guī)定系統(tǒng)覆蓋的作業(yè)范圍，主要有地理邊界(規(guī)定系統(tǒng)運(yùn)行的部門、分支單位等)、操作員范圍(規(guī)定操作系統(tǒng)的所有操作員身份、分布和大致權(quán)限)和業(yè)務(wù)范圍(規(guī)定系統(tǒng)處理的業(yè)務(wù)，對(duì)于不處理的邊沿業(yè)務(wù)特別明確指出)。細(xì)，可以對(duì)應(yīng)實(shí)際系統(tǒng)中的一個(gè)模塊。如：電力MIS中輸電設(shè)施管理子系統(tǒng)中的線路設(shè)備管理，不詳細(xì)描述線路設(shè)備管理中的所有功能。由開發(fā)方完成，還是由開發(fā)方協(xié)助第三方完成。工程的進(jìn)度控制規(guī)定工程的開始、結(jié)束日期和具體工程項(xiàng)目的名稱、完成時(shí)間、地點(diǎn)、備具體項(xiàng)目完成提供的文件名稱和要求，如：網(wǎng)絡(luò)布線驗(yàn)收?qǐng)?bào)告和硬件設(shè)備驗(yàn)收?qǐng)?bào)告等。需求調(diào)查分析訓(xùn)包括操作員和系統(tǒng)維護(hù)人員的培訓(xùn)。培訓(xùn)安排包括每種培訓(xùn)的人員數(shù)量、培訓(xùn)內(nèi)容、平。階段解決"做什么"的問(wèn)題。主要工作有需求調(diào)查準(zhǔn)備、到用戶單位進(jìn)行需求調(diào)查分析和進(jìn)行需求評(píng)審。需求調(diào)查準(zhǔn)備據(jù)和詳細(xì)流程(處理崗位、處理方式和審核細(xì)節(jié)等)。需求分析文檔原型是根據(jù)技術(shù)協(xié)議編計(jì)。owerBuilderPBDelphi型的主要設(shè)計(jì)要求有：1)充分考慮系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)，不得與實(shí)際系統(tǒng)脫節(jié)；2)盡量仿真實(shí)際系統(tǒng)的操作界面，與實(shí)際系統(tǒng)的操作過(guò)程完全相同；3)可以單機(jī)安裝運(yùn)行，不與實(shí)際數(shù)據(jù)庫(kù)連接；4)演示數(shù)據(jù)的存儲(chǔ)可以通過(guò)文本文件、單機(jī)的數(shù)據(jù)庫(kù)或PB外部數(shù)據(jù)源的數(shù)據(jù)窗口；5)對(duì)于界面中容易誤解或難以理解的操作，在功能幫助按鈕中給出說(shuō)明；6)界面中難以實(shí)現(xiàn)或工作量很大的功能，以標(biāo)注方式詳細(xì)說(shuō)明；7)運(yùn)行穩(wěn)定，并比實(shí)際系統(tǒng)對(duì)硬件要求低。書上簽字。最終系統(tǒng)簡(jiǎn)化原型和源代碼留在用戶現(xiàn)場(chǎng)，便于系統(tǒng)的操作員進(jìn)一步理解分析，于開發(fā)人員及時(shí)修改系統(tǒng)的設(shè)計(jì)和編碼。進(jìn)行需求評(píng)審方負(fù)責(zé)人簽字，以需求分析說(shuō)明書附件的形式存在，同樣指導(dǎo)下一步的系統(tǒng)設(shè)計(jì)工作。1)、此方法適合各種MIS工程的需求分析，特別適合致力于某一領(lǐng)域MIS開發(fā)的軟件公司。采用此方法，開發(fā)同類項(xiàng)目越多，需求分析工作的效率越高。2)、在需求分析過(guò)程中，由于需要設(shè)計(jì)系統(tǒng)簡(jiǎn)化原型和文檔原型，并充分考慮到系統(tǒng)中，一般由資深的軟件分析和設(shè)計(jì)人員進(jìn)行。3)、此方法不僅適合MIS軟件工程，同樣適合其它大型軟件工程。4)、由于需求分析工作本身的難度和重要性，此方法同樣要求用戶單位和需求分析人時(shí)進(jìn)行；所有工作步驟不得應(yīng)負(fù)或疏忽。MIS大提高了需求分析的工作效率。實(shí)踐證明，簡(jiǎn)化原型