第二章 軟件需求計算機教學課件PPT_第1頁
第二章 軟件需求計算機教學課件PPT_第2頁
第二章 軟件需求計算機教學課件PPT_第3頁
已閱讀5頁,還剩73頁未讀 繼續(xù)免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內容提供方,若內容存在侵權,請進行舉報或認領

文檔簡介

1、第2章軟件需求教學內容w 引言w 什么是需求w 了解客戶、最終用戶、間接用戶w 需求工程基本概念w 需求開發(fā)的主要困難與對策w 如何開展需求調查w 如何進行需求分析w 什么是好的需求規(guī)格說明書w 如何定義產品需求w 需求管理:確認、跟蹤、變更控制引言引言w抽象性w缺陷檢測的困難性w高度的復雜性w缺乏統(tǒng)一規(guī)則引言canceled before completionOver budget, late, or without needed features引言w 需求不明確!(現實:軟件項目中40%-60%的問題都是在需求分析階段埋下的禍根,需求錯誤消耗整個項目預算的30%-50%)w 不充分的計劃

2、和過于樂觀的評估w 采用新技術w 管理方法缺乏或不恰當w 性能問題w 團隊組織不當w 人際因素引言引言引言引言1. The Requirements Statement2. Emerging Requirements3. Redesign4. Six Months Later什么是需求什么是需求w 需求的基本概念需求的基本概念寬泛地講,需求來源于用戶的一些“需要”,這些“需要”被分析、確認后形成完整的文檔,該文檔詳細地說明了產品“必須或應當”做什么。 所以如果只有一些零碎的對話、資料或郵件,你就以為自己已經掌握了需求,那是自欺欺人。什么是需求w 需求的重要性 Frederick Brooks在

3、他1987年經典文章“No Silver Bullet”中闡述了需求的重要性: 開發(fā)軟件系統(tǒng)最困難的部分就是準確說明開發(fā)什么。最困難的概念性工作是編寫出詳細的需求,包括所有面向用戶、面向機器和其它軟件系統(tǒng)的接口。此工作一旦做錯,將會給系統(tǒng)帶來極大的損害,并且以后對它修改也極為困難。 需求是產品的根源,需求工作的優(yōu)劣對產品影響最大。就像一條河流,如果源頭被污染了,那么整條河流也就被污染了。 國內軟件業(yè)的痼疾:人們并不清楚究竟該做什么,但卻一直忙碌不停地開發(fā)。了解客戶、最終用戶、間接用戶w 基本概念“用戶”(user)是一種泛稱,它可細分為“客戶”(customer)、“最終用戶”(the end

4、 user)和“間接用戶”(或稱為關系人)。掏錢買軟件的用戶稱為客戶,而真正操作軟件的用戶叫最終用戶??蛻襞c最終用戶可能是同一個人也可能不是同一個人。了解客戶、最終用戶、間接用戶w 客戶是掏錢買軟件的人,所以他是“上帝” 某飯店經理在解釋“先有雞還是先有蛋”這個哲學問題時,精辟地闡述了客戶的地位: 如果顧客先點雞,那么就先有雞;如果顧客先點蛋,那么就先有蛋。 “現代營銷學之父”菲利普.科特勒所著的市場營銷導論是這樣描述客戶的:客戶永遠是本公司的座上客??蛻舨⒉灰蕾囄覀?,而我們卻依賴客戶??蛻舨皇俏覀児ぷ鞯恼系K,而是我們工作的目標。我們并不因為服務于他而對他有恩,他卻因為給予我們服務于他的機會而

5、有恩于我們??蛻舨皇俏覀円c之爭辯和斗智的人。從未有人曾在與客戶的爭辯中獲勝。客戶是把他的欲望帶給我們的人,因此我們的工作就是滿足這些欲望,從而使客戶和我們共同獲益。 與客戶打交道的主要目的是:一是獲取需求,二是簽合同一是獲取需求,二是簽合同。不要把錢扔到水里。了解客戶、最終用戶、間接用戶w 即使最終用戶不是上帝,也算是“上帝”的“親戚”,同樣怠慢不得 如果項目規(guī)模比較大,那么開發(fā)方與最終用戶的來往就比較多。如從最終用戶那里獲取詳細的需求,請最終用戶試驗軟件,對最終用戶進行培訓等等。 公司新員工上產品培訓課,有位小領導匆匆趕來作指示:“隔壁班正在給電信局的員工們進行培訓,他們都是上帝派來的,大

6、家要注意形象。由于休息室空間有限,請大家自覺讓位。午休時他們可以躺著睡,我們只能坐在位置上打個盹兒.?!绷私饪蛻簟⒆罱K用戶、間接用戶w 重視“間接用戶”,千萬別“大意失荊州” 間接用戶既不掏錢買該軟件產品,也不使用該軟件,但是它可能對軟件產品有很大的影響。 例如,財務軟件開發(fā)商在把“財務軟件”賣給客戶之前,這個“財務軟件”必須得到國家財政部的批準。否則即使該軟件的功能是完美的,但卻被政府認為是非法的。所以國家財政部就是所有財務軟件的間接用戶,它不僅不付錢給財務軟件開發(fā)商,反而要收取鑒定費、手續(xù)費等。 同理,市面上流通的信息安全軟件、殺病毒軟件必須得到國家公安部的批準,否則軟件開發(fā)商被逮住后戴上

7、“非法經營”的帽子就慘了。 需求工程基本概念w 什么是需求工程把所有與需求直接相關的活動通稱為需求工程。所有與需求直接相關的活動通稱為需求工程。需求工程中的活動可分為兩大類,一類屬于需求開發(fā),另一類屬于需求管理。 需求工程的結構圖 需求工程基本概念w 需求開發(fā)過程域 需求開發(fā)的目的是通過調查與分析,獲取用戶需求并定義產品需求 需求調查的目的是通過各種途徑獲取用戶的需求信息(原始材料),產生用戶需求說明書。 需求分析的目的是對各種需求信息進行分析,消除錯誤,刻畫細節(jié)等。常見的需求分析方法有“問答分析法”和“建模分析法”兩類。 需求定義的目的是根據需求調查和需求分析的結果,進一步定義準確無誤的產品

8、需求,產生產品需求規(guī)格說明書。系統(tǒng)設計人員將依據產品需求規(guī)格說明書開展系統(tǒng)設計工作。需求工程基本概念w 需求管理過程域 需求管理的目的是在客戶與開發(fā)方之間建立對需求的共同理解,維護需求與其它工作成果的一致性,并控制需求的變更。 需求確認是指開發(fā)方和客戶共同對需求文檔進行評審,雙方對需求達成共識后作出書面承諾,使需求文檔具有商業(yè)合同效果。 需求跟蹤是指通過比較需求文檔與后續(xù)工作成果之間的對應關系,建立與維護“需求跟蹤矩陣”,確保產品依據需求文檔進行開發(fā)。 需求變更控制是指依據“變更申請審批更改重新確認”的流程處理需求的變更,防止需求變更失去控制而導致項目發(fā)生混亂。 需求工程基本概念w 需求工程的

9、一些感悟 不論是合同項目還是自主研發(fā)的產品,都必須開展需求開發(fā)和需求管理活動。開發(fā)者對待需求工程的態(tài)度可分“被動型”、“主動型”和“領先型”三種,只有后兩種才有可能開發(fā)出成功的產品。 “被動型”是指開發(fā)者被動地對待需求工程中的各項活動,能少干則少干,能偷懶則偷懶。他們認為需求是用戶的事情而不是自己的事情。開發(fā)過程中經常發(fā)生需求變更,導致產品迷失方向,不是半途而廢就是陷入半死不活的狀態(tài)。 “主動型”是指開發(fā)者積極地開展需求工程中的各項活動。他們把獲取準確的需求當作自己的職責,會想盡一切辦法克服需求開發(fā)和需求管理過程中的困難,而不是找借口推卸責任。俗話說“良好的開端是成功的一半”,“主動型”需求工

10、程是開發(fā)成功產品的必備條件。 “領先型”是需求工程的最高境界。開發(fā)者發(fā)掘了連用戶自己都沒有意識到的需求,導致用戶跟著新產品跑而不是新產品圍著用戶轉,這叫引導消費。需求工程做到這個份上,才能使產品立于不敗之地,長盛不衰。需求開發(fā)的主要困難與對策需求工程基本概念w 知識技能問題知識技能問題應用域的知識是無邊無際的,任何人都不可能是“萬事通”。俗話說“隔行如隔山”,需求分析員可能是某一領域的專家,但當他接手陌生的業(yè)務時,他可能是個“無知”者。一個企業(yè)要謀求發(fā)展,不能總在做老的業(yè)務。人一生中會有許多充滿挫折的“第一次”,不可以逃避。需求工程基本概念w 知識技能問題(續(xù))知識技能問題(續(xù))當需求分析員缺

11、乏應用域知識時,他該怎么辦? 首先他要有勇氣做事,否則連實踐的機會都沒有。 其次他應當趕緊補習應用域知識,不論是通過自學還是培訓的方式,否則他很難與用戶交流。如果可能的話,開發(fā)方最好請既懂軟件又懂應用域知識的行家來幫忙。需求工程基本概念w 態(tài)度問題態(tài)度問題相當多的開發(fā)人員習慣于被動地對待需求開發(fā)。每當遇到麻煩、挫折時,他們會發(fā)牢騷,找出一堆用戶的毛病。很多開發(fā)人員錯誤地以為: 需求是用戶的事情,不是我們的事情。我們?yōu)橛脩糸_發(fā)軟件,難道用 戶不該告訴我們應當開發(fā)什么嗎?如果用戶說不清楚需求,或者經常 變更需求,這類問題是用戶產生的,應當由他們自己負責。需求工程基本概念w 態(tài)度問題(續(xù))態(tài)度問題(

12、續(xù))用戶說不清楚需求或者需求發(fā)生變更,這些都是常見的問題,并不是絕癥,是人們可以設法解決的。可悲的是開發(fā)人員把這些問題當成了借口,不愿主動攻克問題,導致需求問題擴散到整個軟件開發(fā)過程,產生太多的后患。 需求分析員的天職就是在有限的時間內獲取準確而細致的用戶需求,如果做不到就是失職,不要找借口。 需求工程基本概念w 合作關系合作關系如果需求分析員不能與用戶建立良好的合作關系,那么他們在需求開發(fā)過程中會很疲憊。 倘若用戶不能很好地配合需求分析員,那并不表示他是個壞蛋。因為用戶有他自己的想法: 我回答了你們的問題,講了該講的。我們付錢給你們,難道還要我伺候你們不成?我還要干自己的事情,別打擾我了。你

13、們自己想辦法把活干好吧 。需求工程基本概念w 合作關系(續(xù))合作關系(續(xù))對于一些競標項目,在合同未簽訂之前的需求開發(fā)工作尤為困難。用戶未必會買你的產品,他不會投入很多精力來協(xié)助你搞需求開發(fā)。需求分析員不是銷售人員,他們不可能象銷售人員那樣通過某些手段籠絡住用戶就能成功。出色的需求分析員不僅要有過硬的專業(yè)知識,還要具備較強的交流、溝通能力。需求工程基本概念w 合作關系(續(xù))合作關系(續(xù)) 開發(fā)方與用戶的合作關系對需求開發(fā)而言是至關重要的。對于重大的、復雜的項目,我們不能完全期望雙方能夠自發(fā)地建立起良好地合作關系,這樣風險太大。 開發(fā)方和用戶方在開展需求開發(fā)之前,雙方協(xié)商并撰寫“用戶在需求工程中

14、的權利與義務”,即以協(xié)議的方式確定合作關系。“好話”和“丑話”都說在前頭,這樣能減少今后的摩擦。如果條件允許的話,開發(fā)方最好為用戶舉辦關于需求工程的培訓,這樣的培訓將使用戶明白需求的重要性以及忽視需求的危害性,從而促使他們積極友善地參加需求工程中的各項活動。需求工程基本概念w 合作關系(續(xù))合作關系(續(xù))用戶在需求工程中的“權利” 1. 有權要求開發(fā)方派遣資質合格的需求分析員和相關人員。 2. 有權要求開發(fā)方采用用戶熟悉的語言來描述需求,即開發(fā)方必須提供用戶看得懂得需求文檔。 3. 有權審查需求文檔,并對有爭議的需求作出決策。如果認為需求文檔不能準確地反映用戶真實的意愿,可以拒絕在需求文檔上簽

15、字。 4. 如果用戶想要變更需求,有權要求開發(fā)方對該變更將產生的影響作出真實可信的評估,以便用戶決定是否變更需求。需求工程基本概念w 合作關系(續(xù))合作關系(續(xù))在需求工程中的“義務” 1. 以積極友善的態(tài)度與開發(fā)方人員交流、協(xié)作,盡可能地為開發(fā)方人員提供工作和生活上的便利。 2. 樂意接受需求分析員的采訪,在不泄漏機密的前提下盡可能地回答需求分析員的問題。 3. 在不泄漏機密的前提下,盡可能地向需求分析員提供與需求相關的材料。 4. 與需求分析員共同評審需求文檔,確保需求文檔準確地反映用戶真實的意愿。 需求工程基本概念w 用戶說不清楚需求用戶說不清楚需求 用戶說不清楚需求是普遍現象,這是讓開

16、發(fā)人員頭痛的用戶說不清楚需求是普遍現象,這是讓開發(fā)人員頭痛的大問題。大問題。 有些用戶真的不知道需求是什么,或者對需求只有朦朧的感覺,他當然說不清楚需求。 例如開發(fā)方的營銷人員水平比較高,他能夠在用戶不清楚自己要什么的情況下引導用戶“消費”。 例如前些年全國各地的很多政府機構大搞網絡建設。這些機構的領導和辦公人員大多數不清楚網絡干什么用,就讓開發(fā)人員替他們設想需求吧,反正是花公家的錢。需求工程基本概念w 用戶說不清楚需求(續(xù))用戶說不清楚需求(續(xù)) 有些用戶雖然心里明白想要什么,但卻說不清楚需求。 比如說買鞋子。我們非常了解自已的腳,但很難用語言說清楚腳的大小和形狀。通常拿鞋子去試,試穿時感覺

17、到舒服才會買鞋。需求分析員絕不能以用戶說不清楚需求為借口而草率地對待需求開發(fā)工作,否則會連累整個開發(fā)團隊。無論是什么原因導致用戶說不清楚需求,需求分析員必須設法搞清楚用戶真正的需求,這是需求分析員的職責,也是職業(yè)的挑戰(zhàn)。需求工程基本概念w 雙方誤解需求雙方誤解需求 人們在交流的時候,經常會發(fā)生“問非所求,答非所問”的事情。 有時用戶會把開發(fā)人員的建議或答復給想歪了: 有一個軟件開發(fā)人員滔滔不絕地向用戶講解在“信息高速公路上做廣告”的種種好處,用戶聽得津津有味。最后,心動的用戶對軟件開發(fā)人員說:“好得很,就讓我們馬上行動起來吧。請您決定廣告牌的尺寸和放在哪條高速公路上,我立即派人去做?!毙枨蠊こ?/p>

18、基本概念w 雙方誤解需求(續(xù))雙方誤解需求(續(xù)) 而用戶表達的需求,不同的開發(fā)人員可能有不同的理解。如果需求分析員誤解了需求,那會導致后續(xù)的不少開發(fā)人員將錯就錯、白干活。就像作文寫跑題了,寫得再好也白搭。這類錯誤連高智商的外星人都不能避免: 有個外星人間諜潛伏到地球刺探情報,它給上司寫了一份報告:“主宰地球的是車。它們喝汽油,靠四個輪子滾動前進。嗓門極大,在夜里雙眼能射出強光。有趣的是,車里住著一種叫作人的寄生蟲,這些寄生蟲完全控制了車。” 不論是復雜的項目還是簡單的項目,需求分析員和用戶都有可能誤解需求。所以需求確認工作(屬于需求管理)必不可少。 需求工程基本概念w 開發(fā)人員寫不好需求文檔開

19、發(fā)人員寫不好需求文檔 需求調查工作不充分,獲取的需求信息太少或者太亂,以至于寫不成需求文檔。 要想寫出好的需求文檔,前提條件是把需求調查工作做好。 開發(fā)人員寫作能力比較差,雖然在調查過程中已經獲得了不少需求信息,卻寫不出好的需求文檔來。 可以毫不夸張地說,國內可以毫不夸張地說,國內90以上的軟件開發(fā)人員,他們的寫作以上的軟件開發(fā)人員,他們的寫作能力遠不及開發(fā)能力。能力遠不及開發(fā)能力。 提高開發(fā)人員寫作能力的根本辦法就是讓他們多練習寫文檔,熟能生巧。另外,企業(yè)應當提供合適的文檔模板以及比較好的示例文檔,盡可能地降低寫作難度。需求工程基本概念w 用戶經常變更需求用戶經常變更需求 需求變更通常會對項

20、目的進度、人力資源、經費產生很大的影響,需求變更通常會對項目的進度、人力資源、經費產生很大的影響,這是開發(fā)商非常畏懼的問題。這是開發(fā)商非常畏懼的問題。 如果在項目開發(fā)的初始階段,開發(fā)人員和用戶沒有搞清楚需求或者搞錯了需求,到了項目開發(fā)后期才將需求糾正過來,導致產品的部分內容需要重新開發(fā)。毫無疑問,這種需求變更將使項目付出額外的代價。這種損失是由于雙方工作失誤造成的,雙方應當好好反省,認真學習需求開發(fā)和管理的方法,避免再犯相似的錯誤。需求工程基本概念w 用戶經常變更需求(續(xù))用戶經常變更需求(續(xù)) 如果由于市場變化而導致產品需求發(fā)生變更,開發(fā)商大可不必為此煩惱,應當高興才對。倘若市場靜如死水,那

21、么開發(fā)商吃了“上一頓”就沒有“下一頓”。正因為市場在變化,才會產生更多商機,聰明的開發(fā)商才會有活干,有錢賺。 其實需求變更并不可怕,可怕的是需求變更失去控制,導致項目混其實需求變更并不可怕,可怕的是需求變更失去控制,導致項目混亂。所以需求變更控制是需求工程的重要活動。亂。所以需求變更控制是需求工程的重要活動。如何開展需求調查w 準備調查準備調查 首先,需求分析員應當起草需求調查問題表,將調查重點鎖定在該問題表內,否則調查工作將變得漫無邊際。 問題表可以有多份,隨著調查的深入,問題表將不斷地被細化。根據經驗,用戶通常沒有耐心回答復雜的論述題,所以問題表應當以“選擇題”和“是非題”為主。 制定問題

22、表最簡便的方法就是從用戶需求說明書的模板中提取需求問題。 如何開展需求調查w 準備調查(續(xù))準備調查(續(xù))其次,需求分析員應當確定需求調查的方式,例如: 與用戶交談,向用戶提問題。向用戶群體發(fā)調查問卷。 參觀用戶的工作流程,觀察用戶的操作。 與同行、專家交談,聽取他們的意見。 分析已經存在的同類軟件產品,提取需求。 從行業(yè)標準、規(guī)則中提取需求。 從Internet上搜查相關資料。 如何開展需求調查w 準備調查(續(xù))準備調查(續(xù))最后,需求分析員與被調查者建立聯系,確定調查的時間、地點、人員等,撰寫需求調查計劃。要特別留意的是不要漏掉典型的用戶。 如何開展需求調查w 執(zhí)行調查執(zhí)行調查 準備工作完

23、畢后,需求分析員按照計劃執(zhí)行調查。在調查過程中隨時記錄(或存儲)需求信息 。 需求分析員與用戶面談時應當注意以下事項: 如果與用戶約好了時間,切勿遲到或早退。要注意禮節(jié),盡可能獲得用戶的好感,并為下次打擾他們埋下伏筆。 需求分析員應事先了解用戶的身份、背景,以便隨機應變。IT人士不可貌相,有些大企業(yè)的領導其外表很土氣,象農民。如果你路上碰到他,以為是個勤雜工,說:“喂,老師傅,來幫我拎東西?!币苍S這筆生意就泡湯了。 如何開展需求調查w 執(zhí)行調查(續(xù))執(zhí)行調查(續(xù)) 需求調查不象偵探推理那樣從蛛絲馬跡著手,應該先了解宏觀問題,再了解細節(jié)問題。 如果雙方氣氛融洽,可以采用靈活的訪談形式,輕易不要打

24、斷用戶的談話。當雙方對某些問題的交流合乎邏輯地結束后,即可繼續(xù)討論問題表中的其它問題。 盡可能避免為用戶添麻煩,但也不能怕給用戶添麻煩而降低需求調查的力度。 避免片面地聽取某些用戶的需求而忽視其它用戶的需求。 如何開展需求調查w 用戶需求說明書用戶需求說明書與與產品需求規(guī)格說明書產品需求規(guī)格說明書的主要區(qū)的主要區(qū)別與聯系別與聯系 前者主要采用自然語言(和應用域術語)來表達用戶需求,其內容相對于后者而言比較粗略,不夠詳細。 后者是前者的細化,更多地采用計算機語言和圖形符號來刻畫需求,產品需求是軟件系統(tǒng)設計的直接依據。 兩者之間可能并不存在一一影射關系,因為軟件開發(fā)商會根據產品發(fā)展戰(zhàn)略、企業(yè)當前狀

25、況適當地調整產品需求,例如用戶需求可能被分配到軟件的數個版本中。軟件開發(fā)人員應當依據產品需求規(guī)格說明書來開發(fā)當前產品。 如何開展需求調查w 撰寫用戶需求說明書撰寫用戶需求說明書用用戶戶需需求求說說明明書書的的參參考考模模板板如何開展需求調查w 白板原型的制作白板原型的制作 B/S系統(tǒng)的白板(靜態(tài)網頁)系統(tǒng)的白板(靜態(tài)網頁) C/S系統(tǒng)的白板(系統(tǒng)的白板(Visio繪制)繪制)如何進行需求分析w 基本概念基本概念 為了得到用戶的金錢,企業(yè)不得不鼓吹:用戶就是上帝,用戶永遠是正確的。 誰都知道這不是真的。事實上,很多時候用戶說不清楚需求、會說錯需求或者提出一些無法實現的需求。 需求分析是指在需求開

26、發(fā)過程中,對所獲取的需求信息進行分析,及時排除錯誤和彌補不足,確保需求文檔正確地反映用戶的真實意圖。 如何進行需求分析w 基本概念基本概念(續(xù)續(xù))需求分析是需求開發(fā)過程中最費腦子的工作。分析方法大體有兩類:“問答分析法”和“建模分析法”。后者技術性比較強,寫出來有學術味,故大多數軟件工程書籍都有論述。前者就是一些常識而已,雖然寫不成文章,但是簡單易用(保你一學就會),很有實用價值。 “問答分析法”比較適合于用戶需求調查階段“建模分析法”比較適合于產品需求定義階段如何進行需求分析w 問答分析方法問答分析方法 問答分析方法很簡單:刨根究底地問,如果問題都被解答了,那么需求也就分析清楚了。一個人可以

27、“自問自答”地分析需求,幾個人分析需求則稱為“研討”。 問答分析最重要的問題是:“是什么”和“為什么”。 每個需求都應當用陳述句說明“是什么”,如果“是什么”的內涵不夠清晰,則應補充說明“不是什么”。 如果“是什么”和“不是什么”并不是“理所當然”的,那么應當解釋“為什么”,以便加深讀者的理解。 追究“是什么”和“為什么”的目的是獲得正確、清楚的需求。如何進行需求分析w 問答分析方法(續(xù))問答分析方法(續(xù))其它常見的問題有: 需求存在二義性嗎? 需求文檔的上下文有矛盾嗎? 需求完備嗎? 需求是必要的嗎? 需求可實現嗎? 需求可驗證嗎? 需求的優(yōu)先級確定了嗎?如何進行需求分析w 建模分析法建模分

28、析法人們都有這樣地感受:有些時候用語言描述某個問題特別費勁,而采用圖形則使人一目了然,所謂“一圖低千言”就是這個道理。 在需求開發(fā)過程中,對于某些類型的信息,用圖形表示要比文本表示更加有效。所以將圖形與文本結合起來描述需求是很自然的方法。需求建模就是指用圖形符號來表示、刻畫需求。建模分析方法主要有兩大類:“結構化分析法”和“面向對象分析法”。如何進行需求分析w 建模分析法建模分析法(續(xù))(續(xù))恰當地使用圖形符號:恰當地使用圖形符號:現代建模工具如Rose有非常豐富的圖形符號和文字標注,能很好地表達模型的細節(jié)。要注意的是:在建模時使用花樣過多的圖形符號或文字意味著模型表示的復雜化,將使開發(fā)人員更

29、難掌握,而且使圖形文檔更加雜亂。 世上不存在一個包羅萬象的圖它能完整地描述需求。需求建模不可能取代文字描述。在需求文檔中,文字描述是第一重要的,建模主要是起分析、解釋作用。建議將模型存放在需求文檔的附錄中,便于正文引用。 如何進行需求分析w 作出決策作出決策當需求從四面八方收集來后,需求的沖突在所難免。對于那些難以達成共識的需求而言,經常會發(fā)生“公說公有理,婆說婆有理”的現象。那么需求分析員究竟應該聽誰的呢? 如果一群人對需求有爭議,并不是誰聲音最響就聽誰的。根據生活經驗,最保險的辦法是:先聽官兒大的或者威望高的,如果大家的職位和威望都差不多,那么采用“少數服從大多數”的原則。如何進行需求分析

30、w 作出決策(續(xù))作出決策(續(xù)) 如果一個產品可以賣給幾類客戶,但是各類客戶都要求產品按照他們的喜好來開發(fā)。此時對需求的決策應當以商業(yè)利益為導向, 即哪一類客戶出錢最多就先滿足他們的需求,以后再做那些獲利相對較少的需求。 當開發(fā)者想象中的產品與客戶所提的需求有沖突時,一般應當尊重客戶的觀點。但是不要陷入“客戶總是對的”陷阱里,需求分析員應當糾正明顯不合理的客戶需求。如果產品很復雜,雙方都不太明白需求,此時最好請開發(fā)人員快速構造軟件的原型,雙方看著軟件原型再分析需求。什么是好的需求規(guī)格說明書w 正確正確需求規(guī)格說明書應當正確地反映用戶的真實意圖,“正確”是產品需求規(guī)格說明書最重要的屬性。如果“不

31、正確”僅僅是由于錯別字造成的,那么多檢查幾遍文檔就能解決問題。真正的困難是開發(fā)者和用戶自己都不明白用戶究竟“想要什么”和“不要什么”。為確保需求是正確的,開發(fā)方和用戶必須對需求規(guī)格說明書進行確認。什么是好的需求規(guī)格說明書w 清楚清楚清楚的需求讓人易讀易懂,不在于文檔的厚度。清楚的反義詞是“難讀”、“難理解”。你可以采用反問的方式來判斷需求文檔是否清楚:文檔的結構、段落是否亂七八糟?上下文是否不連貫? 文檔的語句是否含糊其詞、羅里羅嗦? 每句話都是對的,但是看了半天是否還不明白需求究竟是什么。什么是好的需求規(guī)格說明書w 無二義性無二義性“無二義性” 是指每個需求只有唯一的含義。如果一個人說的話,

32、不同的人可能有不同的理解,那么這句話就有二義性。如果需求存在二義性,將會導致人們誤解需求而開發(fā)出偏離需求的產品。為了使需求無二義性,人們在寫產品需求規(guī)格說明書時措詞應當準確,切勿模棱兩可。什么是好的需求規(guī)格說明書w 一致一致“一致”(Consistent)是指產品需求規(guī)格說明書中各個需求之間不會發(fā)生矛盾。矛盾常常潛伏在需求文檔的上下文中。什么是好的需求規(guī)格說明書w 必要必要 產品需求規(guī)格說明書中的各項需求對用戶而言應當都是必要的。 可以把“必要”比喻為“雪中送炭”。“必要”往前一步,要么是“畫蛇添足”要么是“錦上添花”。 “畫蛇添足”顯然是壞事,會導致開發(fā)人員多干一些吃力不討好的工作。所以要盡

33、量剔除需求規(guī)格說明書中“畫蛇添足”的那些需求。 “錦上添花”是好事,可能會讓用戶獲得比期望更多的喜悅,但是眼前用戶不會為此多付錢。開發(fā)者應當集中精力先完成必要的需求,如果條件允許則再做“錦上添花”的需求。為了避免主次顛倒,應當在產品需求規(guī)格說明書中將那些“錦上添花”的需求設置為較低的優(yōu)先級。什么是好的需求規(guī)格說明書w 完備完備“完備”(Complete)是指產品需求規(guī)格說明書中沒有遺漏一些必要的需求。人們往往傾向于關注系統(tǒng)的特色功能,而忽視了其它一些不起眼的但卻是必需的功能。 不完備的產品需求規(guī)格說明書將導致產生功能不完整的軟件,用戶在使用該軟件時可能無法完成預期的任務。 什么是好的需求規(guī)格說

34、明書w 可實現可實現 產品需求規(guī)格說明書中的各項需求對開發(fā)方開發(fā)方而言應當都是可實現的(Attainable)。 “可實現”意味著在技術上是可行的,并且滿足時間、費用、質量等約束。營銷人員和用戶談生意時,為了能拿到“單子”,他們往往對用戶提出的需求“來者不拒”。吹牛皮雖然不犯法,但是產品需求規(guī)格說明書可是白紙黑字啊。經過雙方確認的產品需求規(guī)格說明書相當于商業(yè)合同,如果開發(fā)方不能夠實現產品需求規(guī)格說明書中的內容,那就是違約,可能會被罰款的。 對于合同項目,如果開發(fā)方不能確信某些需求是否可實現,則應事先與用戶協(xié)商,達成一致的處理意見,避免將來發(fā)生商業(yè)糾紛。 什么是好的需求規(guī)格說明書w 可驗證可驗證

35、 產品需求規(guī)格說明書中的各項需求對用戶方用戶方而言應當都是可驗證的(Verifiable)。如果需求是不可驗證的,那么用戶就無法驗收軟件,可能會發(fā)生商業(yè)糾紛。 例如,摩天大樓的一項需求是“抗十二級臺風”,這個需求看起來堂而皇之,但是如何驗證呢?當摩天大樓完工后驗收時,用戶又不是巫師,他怎能造個十二級臺風來試驗?如果雙方都認可“采用計算機模擬十二級臺風”等效于實際測試,那么這項需求就是“可驗證”的。什么是好的需求規(guī)格說明書w 確定優(yōu)先級確定優(yōu)先級 為什么要確定需求的“優(yōu)先級”? 理論上講,軟件的所有需求都應當被實現。但是在現實之中,項目存在“進度、費用、人力資源”等限制。在項目剛開始的時候,開發(fā)

36、方和客戶比較樂觀,什么都要做,可是做著做著,人們常常會面臨“進度延誤、費用超支、人員不足”等問題,這時就亂套了。 人們想出了“取舍”辦法:先做優(yōu)先級高的需求,后做(甚至放棄)優(yōu)先級低的需求,這樣可以將風險降到最低。 需求的優(yōu)先級其實就是需求“輕重緩急”的分級表述,例如劃分為“高、中、低”三級。一般地,由用戶和開發(fā)方共同確定需求的優(yōu)先級。什么是好的需求規(guī)格說明書w 闡述闡述“做什么做什么”而不是而不是“怎么做怎么做” 產品需求規(guī)格說明書的重點是闡述“做什么”,而不是闡述“怎么做”。“怎么做”是系統(tǒng)設計和實現階段的事情。 國內的很多軟件公司里,開發(fā)人員常常身兼數職,可能把需求開發(fā)、系統(tǒng)設計、編程等

37、工作從頭做到尾。所以他們在調查、分析、定義需求時,自然會想到“怎么做”,這并沒有什么過錯。如果在調查、定義需求時想好了“怎么做”,當然應該寫下來,否則豈不浪費!關鍵是不要將“怎么做”寫到需求規(guī)格說明書里面,記錄在其它文檔里就行了。 什么是好的需求規(guī)格說明書什么是好的需求規(guī)格說明書w 軟件需求規(guī)格說明書實例軟件需求規(guī)格說明書實例長沙移動項目管理系統(tǒng)軟件需求規(guī)格說明書長沙移動項目管理系統(tǒng)軟件需求規(guī)格說明書湖南移動湖南移動24小時自助營業(yè)廳銀行卡交費軟件需求規(guī)格說小時自助營業(yè)廳銀行卡交費軟件需求規(guī)格說明書明書長沙縣委辦局(部門、鄉(xiāng)鎮(zhèn))協(xié)同辦公系統(tǒng)需求規(guī)格說長沙縣委辦局(部門、鄉(xiāng)鎮(zhèn))協(xié)同辦公系統(tǒng)需求規(guī)

38、格說明書明書需求管理w 需求確認(評審和承諾)需求確認(評審和承諾)需求確認是指開發(fā)方和客戶方共同對產品需求規(guī)格說明書進行評審,雙方對需求達成共識后作出承諾。需求確認包含兩個重要工作:“需求評審”和“需求承諾”。需求管理w 需求評審面臨的困難需求評審面臨的困難需求評審的一個通病是“虎頭蛇尾”。需求評審的確乏味,也比較費腦子。剛開始評審時,大家都比較認真,越到后頭越馬虎。 需求評審涉及的人員可能比較多,有些時候讓這么多人聚在一起花費比較長的時間開會并不容易(例如有些人可能出差在外,有些人可能事務纏身)。沒有必要把所有事情擠在一塊做,需求開發(fā)是循序漸進的過程,需求評審也可以分段進行。這樣每次評審的

39、時間比較短,參加評審的人員也少一些,組織會議就比較容易。需求管理w 需求評審面臨的困難(續(xù))需求評審面臨的困難(續(xù)) 開評審會議時經常會“跑題”,導致評審效率很低。有時話匣子一打開后關不上,大家越扯越遠,結果評審會議變成了聊天會議。主持人應當控制話題,避免大家討論與主題無關的東西。 開評審會議時經常會發(fā)生爭議。適當的爭議有利于澄清問題,比什么東西都一致贊成要好。然而當爭議變?yōu)闋幊硶r就壞事了,爭吵不爭吵不僅對評審工作沒有好處,而且會無意中傷害同事們的感情。僅對評審工作沒有好處,而且會無意中傷害同事們的感情。 人們在很多時候分不清楚自己究竟是“堅持真理”還是“固執(zhí)己見”。毫不妥協(xié)或者輕易妥協(xié)都不是

40、好辦法。我們應當養(yǎng)成良好的習慣:不要一棍子打死異己的觀點,嘗試著讓自己站在他人的立場思考問題,這樣你會找到比較滿意的答案。 需求管理w 需求承諾需求承諾 需求承諾是指開發(fā)方和客戶方的責任人對通過了正式技術評審的產品需求規(guī)格說明書作出承諾,該承諾具有商業(yè)合同的效果。 需求承諾的“八股文”如下: 本本產品需求規(guī)格說明書產品需求規(guī)格說明書建立在雙方對需求的共同理解基礎之上,建立在雙方對需求的共同理解基礎之上,我同意后續(xù)的開發(fā)工作根據該我同意后續(xù)的開發(fā)工作根據該產品需求規(guī)格說明書產品需求規(guī)格說明書開展。如果需開展。如果需求發(fā)生變化,我們將按照求發(fā)生變化,我們將按照“變更控制規(guī)程變更控制規(guī)程”執(zhí)行。我明白需求的變更執(zhí)行。我明白需求的變更將導致雙方重新協(xié)商成本、資源和進度等。將導致雙方重新協(xié)商成本、資源和進度等。 甲方簽字 乙方簽字 人們

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網頁內容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經權益所有人同意不得將文件中的內容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網僅提供信息存儲空間,僅對用戶上傳內容的表現方式做保護處理,對用戶上傳分享的文檔內容本身不做任何修改或編輯,并不能對任何下載內容負責。
  • 6. 下載文件中如有侵權或不適當內容,請與我們聯系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論