【正文】
。要達(dá)到這個(gè)要求,應(yīng)當(dāng)將需求的說(shuō)明編號(hào),從而使 SQL 能夠在隨后的階段中跟蹤它們。 因此,在快速原型開(kāi)發(fā)階段,軟件質(zhì)量保證小組的任務(wù)是確??蛻艚M織中的有關(guān)人 8 員有機(jī)會(huì)與快速原型交互,并且保證讓他們的建議確實(shí)送達(dá)負(fù)責(zé)分析用戶建議的客戶(也可能是一個(gè)客戶管理者委員會(huì) )。 公平地說(shuō),盡管快速原型開(kāi)發(fā)的事例強(qiáng)有說(shuō)服力,但還沒(méi)有證明他是無(wú)懈可擊的。在使用快速原型開(kāi)發(fā)之前,負(fù)責(zé)開(kāi)發(fā)該產(chǎn)品的管理者與客戶討論這些相關(guān)問(wèn)題是必須的。進(jìn)一步地 ,客戶可能期望實(shí)現(xiàn)的改變盡可能與對(duì)快速原型的改變一樣快??焖僭偷囊鈭D是使客戶和開(kāi)發(fā)者能夠在該產(chǎn)品做哪些事情方面盡可能快速地達(dá)成一致意見(jiàn),因此,快速原型中的任何不完美之處都可以忽略不計(jì),前提是它們沒(méi)有嚴(yán)重?fù)p害快速原型的功能并讓人對(duì)產(chǎn)品的行為產(chǎn)生誤解。說(shuō)到底,快速原型的目的是向客戶提供對(duì)軟件產(chǎn)品的理解,并且是盡可能快、盡可能好的理解。隨后,開(kāi)發(fā)人員改進(jìn)快速原型,直至雙方確認(rèn)客戶的要求已準(zhǔn)確地包含在快速原型中,然后快速原型就作為擬訂規(guī)格說(shuō)明的基礎(chǔ)。客戶和該產(chǎn)品預(yù)定的用戶對(duì)快速原型進(jìn)行實(shí)驗(yàn)的同時(shí),開(kāi)發(fā)小組成員觀察并做記錄。 需求小組成員與各個(gè)受訪者討論需求清 單,決定是否忽略了什么;然后因?yàn)樽罹_和有力的需求分析技術(shù)是快速原型開(kāi)發(fā),因此,要建立快速原型。在引入攝像機(jī)或者采用任何其他有可能激怒雇員的行動(dòng)前,可能的危險(xiǎn)必須仔細(xì)考慮到。這個(gè)時(shí)間對(duì)于評(píng)估所觀察到的東西而言是額外增加的,更嚴(yán)重的是,這一技術(shù)據(jù)說(shuō)已經(jīng)產(chǎn)生了嚴(yán)重的適得其反的結(jié)果,因?yàn)楣蛦T可能將攝像機(jī)看做是對(duì)他們個(gè)人隱私的一種不當(dāng)?shù)娜肭帧? 7 這項(xiàng)技術(shù)的難點(diǎn)之一是它可能花費(fèi)很長(zhǎng)時(shí)間去分析錄像帶。因此,認(rèn)真研讀 客戶文檔絕不應(yīng)當(dāng)僅僅被小看為一個(gè)信息源,它能夠?qū)е聹?zhǔn)確地把握客戶的要求。這個(gè)表格中的各種域顯示了印刷工作的流程以及印刷過(guò)程,它也可以是準(zhǔn)確找出“已做了什么”和“是如何做的”等的強(qiáng)有力工具。 4. 檢查客戶所使用的各種表格 (form)。然而,有一個(gè)很有辦法的訪談人進(jìn)行的非程式化的訪談,由于他能夠認(rèn)真傾聽(tīng)受訪者的意見(jiàn)并提出進(jìn)一步的問(wèn)題,從而將起初得到的響應(yīng)大大擴(kuò)展了,這樣的比一個(gè)經(jīng)過(guò)深思熟慮的紙面上的問(wèn)卷調(diào)查表通常揭示出更多的信息。 這個(gè)技術(shù)在需要考慮比如說(shuō)幾百個(gè)個(gè)體的需求意見(jiàn)時(shí)很有用。 情景(或更精確地說(shuō)是用例( user case))在面向?qū)ο蟮姆治鲋邪l(fā)揮著重要作用。因?yàn)?情景能夠被用戶所理解,情景的 使用可以確保客戶和用戶在整個(gè)需求分析過(guò)程中自始至終發(fā)揮積極作用。另一種技術(shù)是建立情景板( story board),它是描述事件序列的一系列圖表。 可以用多中方式描述情景。 2. 情景 。首先,訪談?wù)弑仨毷煜?yīng)用領(lǐng)域;其二,如果訪談?wù)咭呀?jīng)決意尊重客戶需求的話,訪談客戶組織的成員時(shí)是沒(méi)有訪談要點(diǎn)的。 因此,應(yīng)當(dāng)以一種這樣的方式提出問(wèn)題:他能夠鼓 勵(lì)受訪者給出范圍廣泛的回答,但該回答又不要超出訪談?wù)咚栊畔⒌姆秶?。要是訪談過(guò)于程式化了,有些事實(shí)可能就發(fā)現(xiàn)不了。 在一個(gè)程式化的訪談中,提出特定的、預(yù)先計(jì)劃好的、受限回答的( closeended)問(wèn)題。 需求 小組成員會(huì)見(jiàn)客戶組織的成員,直到他們確信已經(jīng)從客戶和該產(chǎn)品未來(lái)的用戶處獲取了所有相關(guān)信息。 一旦需求分析小組成員熟悉了該應(yīng)用領(lǐng)域之后,下一步就是由他們來(lái)開(kāi)始確定客戶的要求,即進(jìn)行需求獲取。 解決術(shù)語(yǔ)問(wèn)題的一個(gè)辦法是建立術(shù)語(yǔ)表,當(dāng)需求分析小組成員開(kāi)始學(xué)習(xí)應(yīng)用領(lǐng)域知識(shí)時(shí),將初始的詞條插入到術(shù)語(yǔ)表中,然后,每當(dāng)需求分析小組成員遇到新的術(shù)語(yǔ)時(shí)就更新該術(shù)語(yǔ)表。更重要的是,使用一個(gè)不合適的術(shù)語(yǔ)可能會(huì) 導(dǎo)致曲解,甚至?xí)斐砂l(fā)行一個(gè)有錯(cuò)誤的軟件產(chǎn)品的結(jié)果。 當(dāng)與客戶和目標(biāo)軟件的可能用戶交流時(shí),特別重要的一點(diǎn)是使用正確的術(shù)語(yǔ)。 例如,如果沒(méi)有首先對(duì)銀行業(yè)或護(hù)理專業(yè)有某種程度的熟悉,就不太容易向一個(gè)銀行家或護(hù)士問(wèn)出有意義的問(wèn)題。問(wèn)題在于許多客戶不知道他們需要什么,更進(jìn)一步說(shuō),即使一個(gè)客戶對(duì)什么是他們所需要的有一個(gè)好的想法,他也可能難于準(zhǔn)確地將這些想法傳達(dá)給開(kāi)發(fā)者,因?yàn)榇蠖鄶?shù)客戶的計(jì)算機(jī) 知識(shí)比起軟件開(kāi)發(fā)小組成員來(lái)講要少得多。 人們通常持有的一個(gè)錯(cuò)誤概念是,在需求分析階段,開(kāi)發(fā)者必須客戶想要什么樣的軟件。同樣,如果 一個(gè)個(gè)人計(jì)算機(jī)制造商正打算開(kāi)發(fā)一個(gè)新的操作系統(tǒng),第一步是評(píng)價(jià)企業(yè)單前的操作系統(tǒng),并認(rèn)真準(zhǔn)確地分析為什么它 不能令人滿意。 要達(dá)到這種全體一致首先是盡可能精確地分析客戶當(dāng)前的狀態(tài)形勢(shì),例如,這樣說(shuō)是不合適的:“因?yàn)樗麄儽г顾麄兊娜斯ぴO(shè)計(jì)系統(tǒng)很糟 ,所以他們需要一個(gè)計(jì)算機(jī)輔助設(shè)計(jì)系統(tǒng)。 1 Requirements Phase The chances of a product being developed on time and within budget are somewhat slim unless the members of the software development team agree on what the software product will do. The first step in achieving this unanimity is to analyze the client’s current situation as precisely as possible. For example, it is inadequate to say, “ They need a puteraided design system because they claim their manual design system, there is lousy. “ Unless the development team knows exactly what is wrong with the current manual system, there is a high probability that aspects of the new puterized system will be equally “l(fā)ousy. “ Similarly, if a personal puter manufacturer is contemplating development of a new operating system, the first step is to evaluate the firm’s current operating system and analyze carefully exactly why it is unsatisfactory. To take an extreme example, it is vital to know whether the problem exists only in the mind of the sales manager, who blames the operating system for poor sales, or whether users of the operating system are thoroughly disenchanted with its functionality and reliability. Only after a clear picture of the present situation has been gained can the team attempt to answer the critical question, What must the new product be able to do? The process