2011軟件設計師知識點：簡易應用規(guī)格說明技術
使用傳統(tǒng)的訪談技術定義需求時，用戶和開發(fā)者往往有意無意地區(qū)分“我們和他們”。由于不能做到像同一個團隊的人那樣同心協(xié)力地識別和精化需求。這種方法的效果有時并不理想(經(jīng)常發(fā)生誤解，還可能遺漏重要的信息)。
為了解決上述問題，人們研究出了一種面向團隊的需求收集法，稱為簡易的應用規(guī)格說明技術。這種方法提倡用戶與開發(fā)者密切合作，共同標識問題，提出解決方案的要素，商討不同的方法并指定基本的需求。今天，簡易的應用規(guī)格說明技術已經(jīng)成為信息系統(tǒng)界使用的主流技術。
盡管存在許多不同的簡易應用規(guī)格說明方法，但是它們遵循的基本準則是相同的。
在中立地點舉行由開發(fā)者和用戶雙方出席的會議。
制定準備會議和參加會議的規(guī)則。
提出一個議事日程，這個日程應該足夠正式以便能夠涵蓋所有要點，同時這個日程又應該足夠非正式，以便鼓勱自由思維。
由一個“協(xié)調(diào)人”來主持會議，他既可以是用戶也可以是開發(fā)者還可以是從外面請來的人。
使用一種“定義機制”(例如，工作表、圖表等)。
目標是標識問題、提出解決方案要素、商討不同的方法以及在有利于實現(xiàn)目標的氛圍中指定初步的需求。
通常，首先進行初步的訪談，通過用戶對基本問題的回答，對待解決的問題的范圍和解決方案有了總體認識，然后開發(fā)者和用戶都寫出“產(chǎn)品需求”。選定會議地點、日期和時間，并選舉一個協(xié)調(diào)人。邀請開發(fā)者和用戶雙方組織的代表出席會議，在會議日期之前把寫好的產(chǎn)品需求分發(fā)給每位與會者。
要求每位與會者在開會的前幾天認真復審產(chǎn)品需求，并且列出作為系統(tǒng)環(huán)境組成部分的對象、系統(tǒng)將產(chǎn)生的對象以及系統(tǒng)為了完成自己的功能將使用的對象。此外，還要求每位與會者列出操作這些對象或與這些對象交互的服務(即處理或功能)。***，還應該列出約束條件(例如成本、規(guī)模、完成日期)和性能標準(例如速度、精度)。并不期望每位與會者列出的內(nèi)容都是毫無遺漏的，但是，希望能準確表達出每個人對目標系統(tǒng)的認識。
會議開始之后，討論的***個議題是是否需要這個新產(chǎn)品，一旦大家都同意確實需要這個新產(chǎn)品，每位與會者就應該展示他們在會前準備好的列表供大家討論。可以把這些列表抄寫在大紙上釘在墻上，或者寫在白板上掛在墻上。理想的情況是，表中每一項都能單獨移動，這樣就能刪除或增添表項，或組合不同的列表。在這個階段，嚴格禁止批評與爭論。
在展示了每個人針對某個議題的列表之后，小組共同創(chuàng)建一張組合列表。在組合列表中消去了冗余項，加入了在展示過程中產(chǎn)生的新想法，但是并不刪除任何實質(zhì)性內(nèi)容。在針對每個議題的組合列表都建立起來之后，由協(xié)調(diào)人主持討論。組合列表將被縮短、加長或重新措辭，以便更恰當?shù)孛枋鰧⒈婚_發(fā)的產(chǎn)品。討論的目標是，針對每個議題(對象、服務、約束和性能)都創(chuàng)建出一張意見一致的列表。
一旦得出了意見一致的列表，就把與會者分成更小的小組，每個小組的工作目標是為每張列表中的一個或多個項目制定出小型規(guī)格說明。小型規(guī)格說明是對列表中包含的單詞或短語的準確說明。
然后，每個小組都向全體與會者展示他們制定出的小型規(guī)格說明供大家討論。通過討論可能會增加或刪除一些內(nèi)容，也可能做一螋進一步的精化工作。在討論過程中還可能提出一些無法在這次會議中解決的問題，應該保存問題清單，以便這些想法在以后的活動中起作用。
在完成了小型規(guī)格說明之后，每個與會者都制定出產(chǎn)品的一整套確認標準，并把自己制定的列表提交會議討論，以創(chuàng)建出意見…一致的確認標準列表。***，由一名或多名與會者根據(jù)會議成果起草完整的規(guī)格說明。
簡易的應用規(guī)格說明技術并不是解決需求分析階段遇到的所有問題的“***靈藥”，但是，這種面向團隊的需求收集方法確實有許多突出的優(yōu)點：開發(fā)者與用戶不分彼此，集思廣益，益密切合作;即時討論和求精;有能導出規(guī)格說明的具體步驟。
【編輯推薦】
