- 目錄
【第1篇 需求分析工作總結(jié)范文
需求分析是項目開發(fā)的基礎(chǔ),基礎(chǔ)打的牢不牢直接關(guān)系到后面所有的工作,是項目實施成敗的關(guān)鍵
項目經(jīng)理博客
總體上說,我們的需求分析是做了,但是做得很不夠,我們做的需求只解決了我們能做出這樣的項目,但是沒有解決這樣的項目是不是真就是客戶想要的。造成這種狀況的原因主要是下面幾個情況:
客戶本身說不清楚
文物網(wǎng)是這樣,中彰國際更是這樣,但是這不能怪客戶,畢竟客戶在軟件方面的知識要少的多,也沒有相關(guān)的經(jīng)驗,可能心里只有一個想要的軟件的輪廓,于是可能會要求我們?nèi)ヌ嫠麄儊硗暾@個輪廓的細節(jié),而我們的能力、我們能否真正站在客戶角度去搜集和整理這些需求,就決定了這個需求的完整性和有效性。
需求自身經(jīng)常變動
隨著客戶對這個項目越來越深刻的理解,那么可能他的需求也會隨之改變,這些變化的可能性越大項目風險就會越大,我們在需求分析的時候就要充分考慮到哪些需求是相對固定的需求,哪些可能會是產(chǎn)生變動的需求,考慮到他的可變性,這樣設(shè)計功能和數(shù)據(jù)庫的時候不致因為后面的變動而影響整個工程。
分析人員或客戶理解有誤
畢竟,不是每個分析人員都是專業(yè)而合格的,為避免這種情況的發(fā)生,需求分析必須要有審核制度,公司自己內(nèi)部要審核一遍,客戶再審一遍,提出意見,修改后雙方共同評審簽字,確認。
由此出現(xiàn)的問題:
a) 需求分析過于籠統(tǒng),只關(guān)注到面上,沒有關(guān)注到點上,開發(fā)出來的東西在具體的細節(jié)上和客戶的理解有誤差,并且無法嚴格界定是否屬于需求變更。中彰的方案就是這樣的。
b) 需求報告只求我們這方評審通過,不去關(guān)心客戶的評審,認為只要客戶簽字認可就行。雖然簽字認可能夠給日后出現(xiàn)問題時劃清我們的責任,但是不能保證使項目實施成功。
c) 需求分析中含有技術(shù)實施上有難度的功能,一味的求全和盲目按照客戶的設(shè)想,受客戶影響過大,畢竟,很多時候,客戶的想法在實際實施過程中是不現(xiàn)實的,或者可以有更為簡便的方法來替代的。如中彰國際的在線交易功能,后臺大批量郵件群發(fā)功能。
d) 對雙方已經(jīng)確定的需求,實現(xiàn)以后并不適合客戶使用,需要按照變更手續(xù)執(zhí)行的時候,客戶可能會糾纏,提出“你們是專業(yè)人士,你們應(yīng)該事先能提醒我們可能會出現(xiàn)這種問題”并以此來把責任推給我們,而我們又不好完全按照變更手續(xù)執(zhí)行,因為可能激化雙方的矛盾,比如508的批量處理功能,因為屬于人事管理比較專業(yè)的細節(jié)問題,需求分析師開始沒有對客戶業(yè)務(wù)熟悉到如此細致的地步,而客戶也沒有過多關(guān)注這些細節(jié),導致軟件的某些功能不合用,較為繁瑣,而重新按著客戶的意見修改的話工作量比較大,導致成本增加、工期延長。
e) 項目的成熟度受客戶預算的限制。大部分客戶在項目投入上都是有預算的,在成本有上限的前提下,項目的功能設(shè)計(軟件的成熟度)方面必然受一定影響,畢竟功能越多越完善,相應(yīng)的開發(fā)成本就越高。這種功能上的不完善需要事先告知客戶并得到理解。
f) 此項工作的反復造成思想上的倦怠,使需求分析最后虎頭蛇尾。需求分析是一項繁瑣枯燥的工作,需要和客戶之間不斷的商討、確認和反復,另外由于大部分的客戶雖然安排專人負責這項工作,但是該人并不只做這項工作,特別當他被很多其他的事情纏身的時候,而無心細看提交過去的需求報告的時候,他很可能會給你一個錯覺,讓你認為他已經(jīng)真正的理解并認可了你的設(shè)計。結(jié)論
a) 需求分析是整個項目管理中需要重點控制的幾個關(guān)鍵節(jié)點之一,首先思想上一定要重視。
b) 需求分析報告的編寫者要參與到需求的搜集工作中,準確領(lǐng)會客戶的意圖,并轉(zhuǎn)化成軟件能夠?qū)崿F(xiàn)的功能。對于說不清楚需求的客戶,要善于問關(guān)鍵問題,引導客戶提出自己的需求??梢圆扇〉拇胧┦鞘孪染幹埔粋€問卷調(diào)查之類的文檔,詳細列舉需要客戶回答的問題,以便防止遺漏。
c) 需求報告的編寫者要能夠?qū)蛻粜枨筮M行深入分析,區(qū)別出哪些需求存在日后變更的可能,哪些需求屬于相對固定的,哪些需求能夠?qū)崿F(xiàn),哪些需求需要變通才能實現(xiàn),以便于指導后面的功能設(shè)計。
d) 需求分析報告對功能細節(jié)的描述不能有歧義,描述一定要全面、準確,防止開發(fā)方和客戶只見對同一個問題有兩個截然不同的理解??梢酝ㄟ^評審,用大家的力量來避免這種情況發(fā)生
e) 需求報告的每個關(guān)乎功能的描述都要讓客戶明白和理解,客戶在理解之上的確認才能夠保證日后一旦出現(xiàn)問題不致出現(xiàn)雙方互相推托責任糾纏不清的情況。
f) 需求報告一定要經(jīng)過一個有技術(shù)人員和業(yè)務(wù)人員參加的評審,要充分發(fā)揮團隊的力量,重視每個人的才智,一個模塊一個功能的逐一的過,讓大家來共同找出需求報告里不合理的、有歧義的、不完善的、遺漏的等等問題
g) 幫助客戶去理解提交給他的需求分析報告而不是只等簽字,對于有能夠用好幾種方式實現(xiàn)的功能,盡量做到能讓客戶去比較和選擇。不要讓客戶對報告中的部分產(chǎn)生歧義。只有客戶對報告的完全的理解,才能在日后客戶提出的修改被認為是需求變更的時候能夠得到客戶的理解
h) 最后,需求分析報告一定要雙方共同簽字確認
【第2篇 需求分析師工作總結(jié)
需求分析師工作總結(jié)
工作總結(jié),以年終總結(jié)、半年總結(jié)和季度總結(jié)最為常見和多用。就其內(nèi)容而言,工作總結(jié)就是把一個時間段的工作進行一次全面系統(tǒng)的總檢查、總評價、總分析、總研究,并分析成績的不足,從而得出引以為戒的經(jīng)驗。以下是小編整理的需求分析師工作總結(jié),好一點!
我是一名專職教研員,__年3月在北京接受了項目辦的培訓,初步了解和理解了以導師為依托的教師支持服務(wù)體系項目的來歷、目的、愿景、實施計劃、實施方法等;首次接觸到全納理論,被深深震動;又學習了多元智能理論、時間管理理論等;通過國家級專家的引領(lǐng)和各省項目專家的幫助,自覺長進不小。
一、工作實踐
1.文字工作
__年3月底開始,在省級專家倪萬赤和原州區(qū)項目辦領(lǐng)導下進入導師制項目,開始扮演“縣級導師”角色,參與了原州區(qū)項目辦的基礎(chǔ)工作,如擬訂《寧夏固原市原州區(qū)教師支持服務(wù)體系項目(__--__)周期實施方案》和《中國—聯(lián)合國兒童基金會教師支持服務(wù)體系導師制試點項目第二階段工作計劃》;撰寫《“教師支持服務(wù)體系”導師制試點項目原州區(qū)__年工作總》;在國家項目辦“教師支持服務(wù)體系項目實施指南”《教師需求調(diào)查表》基礎(chǔ)上修改而成《關(guān)于教師生存狀態(tài)和專業(yè)需求的自我評價問卷》及“愛生學校校長教師須知考試題”,在《教師支持服務(wù)體系實施指南》中的“學校發(fā)展需求校長訪談提綱”基礎(chǔ)上修改完成了《學校發(fā)展需求校長訪談提綱》,撰寫了《“關(guān)于教師生存狀態(tài)和專業(yè)需求的自我評價問卷”高紅小學調(diào)查統(tǒng)計分析》;今年又開發(fā)了《__年原州區(qū)導師制試點工作導師真實需求調(diào)研問卷》、《原州區(qū)愛生學校示范校打造工程教師問卷》、《原州區(qū)愛生學校打造工程中小學學生問卷》等等。
2.參加原州區(qū)項目辦組織的培訓、研修活動。
如在__年4月3日的“教師支持服務(wù)體系”項目導師團隊首次集中培訓中主講“如何了解教師真實的需求”。__年5月7日,在省級專家倪萬赤的指導下開展了“教師支持服務(wù)體系”項目導師團隊第二次集中培訓。集中學習了《中國-聯(lián)合國兒童基金會師資培訓項目項目縣教師支持服務(wù)體系指導意見(試用稿)》。同時對原州區(qū)導師團隊為項目學開發(fā)的培訓內(nèi)容進行研修。
__年11月24日,在省級專家倪萬赤的倡導下開展了“教師支持服務(wù)體系”項目導師團隊第三次集中培訓。培訓的主要內(nèi)容是如何建立自己的博客和博客群。
3.撰寫導師制項目工作活動簡報(__年3期,__年5期)和日記,使更多的人了解項目,也為項目積累了許多寶貴的資料。
4.下校工作
__年在清河鎮(zhèn)高紅小學。工作實績有:
(1)幫助學校制定了《高紅小學__-__年三年發(fā)展規(guī)劃》,輔導教師完成了《教師個人年度發(fā)展規(guī)劃》。學校的三年發(fā)展規(guī)劃和教師的個人規(guī)劃都是反復修改,幾易其稿。通過多次修改教師個人發(fā)展規(guī)劃,使教師學會了撰寫規(guī)劃的環(huán)節(jié)和方法;通過學校發(fā)展規(guī)劃的反復修改,使教師、學生、家長參與,體現(xiàn)了參與意識,集中了眾人的智慧。
(2)以愛生理念指導工作,以兒童視角觀察學校和教師,在改善辦學條件,提高校園文化愛生氛圍上做了一些工作。
如建議校長為學生供應(yīng)開水,建議班主任開展以友愛為主題的班會。去年4月,經(jīng)我建議和策劃,學校對旗臺、大門、操場后墻(土墻)進行了維修,并硬化花園的走道,粉刷操場北墻,校園西花園中心制作水泥圓臺及配套的六個小石凳,柳樹下制作七個學生活動石桌及配套的小石凳,同時對校外周邊環(huán)境進行了治理,使校內(nèi)、校外環(huán)境得到徹底整治,創(chuàng)造了一個良好的育人環(huán)境和較濃的文化氛圍。還建議培訓中心為學校校調(diào)配電腦三臺,34英寸彩電一臺,dvd一臺,使學校的辦學條件得到進一步改善。經(jīng)我建議,學校接通了寬帶網(wǎng),為網(wǎng)絡(luò)教研工作的開展創(chuàng)造了良好的條件。(3)帶頭實踐愛生理念,實實在在幫助教師成長。
向教師大力灌輸愛生學校理念,全納、平等、民主、和諧教育思想和愛生如子、愛校如家、愛崗敬業(yè)的職業(yè)素養(yǎng)日益深入我校教師之心,并表現(xiàn)在實際的教育教學行為中。我自己在工作過程中以人為本,謙虛和藹,循循善誘,腳踏實地,親力親為,如為五年級學生上作文課,以兒童為主體,課堂民主和諧,評課時又很誠懇,虛心聽取老師的建議,使教師感到教學研究是實實在在的學術(shù)行為,村小完全可以進行有質(zhì)量的校本研修。通過對所有教師展開聽課、評課活動,合課例,有針對性的培訓,如“課堂教學中的師生互動交流”等,使學校進一步明確了校本教研的有效做法,也使教師明確了個人專業(yè)發(fā)展之路該如何走。我們的這些實實在在的行動,消除了教師抵觸情緒,使教師的上進心和從業(yè)愉快感有所增強。
針對實際情況,我在新浪網(wǎng)上為學校建立了“寧夏高紅小學的博客”,教會老師在博客上發(fā)表文章、圖片,并帶頭在博客上上與老師進行教學研討,引領(lǐng)他們走上了網(wǎng)絡(luò)教研之路。現(xiàn)在,郭桂紅、黃軍紅等老師將新浪網(wǎng)上和原州教育信息網(wǎng)上的學校博客和個人博客經(jīng)營得非常之好,頁面精致程度、文章數(shù)量、受到的關(guān)注度都超過了我。教師將自己的教學設(shè)計、反思在高紅小學的博客上發(fā)表,并與教研員和同事在網(wǎng)上進行溝通、交流,網(wǎng)絡(luò)教研的意識已逐步形成,教師教育科研意識和能力得到了提高,“寧夏高紅小學”的博客成為學校的窗口,原州教育信息網(wǎng)“六盤部落”上“高紅小學的博客”、“大漠孤煙的博客(黃軍紅的博客)”、“孤獨讓我如此美麗的博客(郭桂紅的博客)”文章數(shù)、點擊數(shù)、被評數(shù)、推薦數(shù)在所有博客中遙遙領(lǐng)先,受到更多老師的關(guān)注和好評,本學期在清河鎮(zhèn)中心小學片區(qū)教研交流活動中,學校被評為“片區(qū)教研先進集體”,七月份又被原州區(qū)教育局推薦為自治區(qū)教育科研先進集體。
今年,與李紅、楊進元在張易中學、楊郎中學。工作實績:
1.開發(fā)出導師真實需求調(diào)查工具,完成了導師真實需求分析報告。
2.對教師進行愛生學校理念培訓。
3、對導師進行教師真實需求調(diào)查與分析的技能培訓。
4.開展教師、學生真實需求問卷、訪談,與張易中學、楊郎中學校級導師團隊共同完成了教師、學生需求問卷分析報告。
5.完成前四期活動簡報。
6.進行了學校發(fā)展規(guī)劃制定的培訓,與兩校的校級導師團隊共同修訂完成了學校三年發(fā)展規(guī)劃。
7.進行教師專業(yè)成長計劃制定的培訓,幫助兩校教師制訂了比較規(guī)范的個人年度發(fā)展規(guī)劃。
8.與校級導師合作,建設(shè)學校學習支持中心和學習共同體,探索其運行機制。
9.指導教師建立了教師個人成長檔案夾。
1.通過聽課-評課,研討有效教學。
11.指導學校和教師在博客及其他網(wǎng)絡(luò)工具上進行交流。
12.主持了張易和楊郎兩校間的觀摩交流。
二、收獲與體會
1.學習到很多知識,鍛煉了很多能力。
按照《導師應(yīng)知應(yīng)會清單》的提示,自學了《教師支持服務(wù)體系實施指南》、《兒童權(quán)利公約》、多元智能理論、《如何幫助農(nóng)村教師專業(yè)發(fā)展》、《校本教研》等知識;在原州區(qū)項目辦組織下,通過多次的“實地鍛煉-集中培訓-交流探討-提高認識-實踐檢驗-反思修正”這樣的模式,在行動中提升了自己的能力。已經(jīng)熟練掌握了學校狀況調(diào)研能力、發(fā)現(xiàn)教師真實需求的能力、指導教師專業(yè)發(fā)展的能力、用各種方式與校長和教師溝通的能力,對教師進行專題培訓和有效教學指導的能力、進行系列活動的組織管理能力等等。2.在實踐過程中提升了自己的思想認識。
愛生學校的理念是對自己教育思想的整理和洗禮,如全納理論既包含了以學生為中心的理論又超越了它,因為以學生為中心的理論主要著眼于教學,而全納則包括整個教育。建立在兒童視角之上的安全校園將不僅僅是約學生或保護學生,而是竭盡全力為兒童營造適合兒童發(fā)展的樂園,為兒童提供生理、心理和情感上的安全感;為此,我們不僅要提倡教師愛護學生,也要引導孩子之間的友愛。愛生學校的發(fā)展離不開教師、學生、家長和社區(qū),因此廣泛的參與是決策民主和效益最大化的基礎(chǔ)。愛生學校的課堂是民主的.和諧的,還要追求有效教學,這是導師與教師的最重要的共同話語;學校的教學質(zhì)量要有吸引力,這是我們和學校做項目的共同出發(fā)點之一。以導師制為依托的教師支持服務(wù)體系項目與目前原州區(qū)實施的村小行動,與寧夏正在全面推開的寧夏回族自治區(qū)基礎(chǔ)教育學校綜合管理質(zhì)量工程相契合,從大的方面說就是實施素質(zhì)教育,推進教育均衡發(fā)展;從小的方面說就是使每個地區(qū)都有好學校,每個學校都有好教師,每個學生都得到全面發(fā)展。
3.三點經(jīng)驗
(1)一節(jié)課的效應(yīng)
在高紅小學,下校幾次,發(fā)現(xiàn)教師見了導師還是躲躲閃閃,談話很被動也很戒備,我知道這是教師與我們感情上有距離,認為項目工作是負擔。我選擇了一個突破口——主動為五年級學生上了一節(jié)作文課。作文課是難上的課,我的教學效果較好,而且在評課時真誠的請老師們提意見,之后,老師們的態(tài)度發(fā)生了很大變化,我很快融入了教師群體。啟示是:以教師視角來看教師,以真誠的態(tài)度幫助教師,就能贏得教師的信任,就能順利地開展合作。
(2)網(wǎng)絡(luò)交流使導師工作得以延續(xù)。
高紅小學是一所郊區(qū)農(nóng)村小學,教師沒有住校的,每天中午和下午回家,這使得導師與教師的交流時間很有限,曾經(jīng)成為我的一個難題。但是部分教師家中有上網(wǎng)條件且有初步的上網(wǎng)技術(shù),了解到此信息后,我教會了教師上網(wǎng)做博客,在博客上討論,利用qq等工具與教師進行八小時之外的交流。例如在新浪網(wǎng)的寧夏高紅小學的博客上,我對郭桂紅、馬莉等老師的課堂教學和教學設(shè)計進行了認真的評論,使得教學研討突破時空限制,也贏得了教師的感激和尊重。至今,我們還在共同經(jīng)營著這個博客,我與高紅小學的老師的交流還在繼續(xù)。
(3)今年在張易中學和楊郎中學實施導師制項目時又有新的感悟,那就是因地制宜,充分發(fā)揮學校和教師的主動性。張易中學李強校長在項目啟動之后,組建了包括副校長、各科教研組長在內(nèi)的9人校級導師團隊;在制訂學校三年發(fā)展規(guī)劃時印制了“張易中學學校發(fā)展規(guī)劃征求意見問卷”,廣泛征求校內(nèi)外人士的意見,這是我們提倡的但又沒有實際操作過的。張易中學做過好幾個大項目,他們有開闊的眼界和一個很有能力的團隊,因此很多事情關(guān)鍵在于計劃和達成共識,不必像在高紅小學那樣“示范”過多。事實上,今年張易和楊郎兩個中學的教師需求、學生需求、學校發(fā)展規(guī)劃、教師發(fā)展規(guī)劃等我們導師有培訓,參與修改,但是直接的“幫助”(或者說手把手的幫助)較少。
三、問題與思考
一是縣級導師的日常工作與項目工作存在一定的矛盾,縣級導師畢竟不是專職導師,因而在確保他們的項目工作時間上有一定沖突。導師還需要更高一級的培訓與學習、支持與幫助,自身能力仍需進一步加強和提高。二是項目學校校本研修、校本培訓的規(guī)范化、制度化、常規(guī)化還需著力促進和完善。校際之間、教師之間的學習、研討、合作與交流的氛圍要進一步創(chuàng)建和加強。
三是項目校學習支持中心團隊教師的支持力度、支持能力還沒有充分發(fā)揮出來。專業(yè)發(fā)展協(xié)調(diào)人就本校教師與縣級導師團隊和學校支持中心團隊之間的協(xié)調(diào)能力和如何協(xié)調(diào)需要進一步指導和培訓。
四是對“一堂好課”的標準莫衷一是,我們急需評價標準的指導。
【第3篇 2023四級人力資源考點總結(jié):培訓需求分析含義與作用
培訓需求分析含義:
在規(guī)劃與設(shè)計每項培訓活動之前,由培訓部門、主管人員、工作人員等采取各種方法和技術(shù),對各種組織及其成員的目標、知識、技能等方面進行系統(tǒng)的鑒別與分析,以確定是否需要培訓及培訓內(nèi)容的過程。
培訓需求分析作用:
1、尋找組織績效問題產(chǎn)生的原因
2、確認差距
3、了解員工個人需求,贏得組織成員的支持
4、建立培訓信息資料庫
5、確定培訓項目的成本與價值
執(zhí)業(yè)藥師考試介紹:
全國執(zhí)業(yè)藥師資格考試由中華人民共和國人力資源和社會保障部、國家食品藥品監(jiān)督管理總局共同負責執(zhí)業(yè)藥師資格考試工作。國家食品藥品監(jiān)督管理局負責組織擬訂考試科目和考試大綱,編寫培訓教材,建立試題庫及考試命題工作。按照培訓與考試分開的原則,統(tǒng)一固化并組織考前培訓。
【第4篇 軟件需求分析總結(jié)范文
1. 引言
引言是對這份軟件產(chǎn)品需求分析報告的概覽,是為了幫助閱讀者了解這份文檔是如何編寫的,并且應(yīng)該如何閱讀、理解和解釋這份文檔。
1.1 編寫目的
說明這份軟件產(chǎn)品需求分析報告是為哪個軟件產(chǎn)品編寫的,開發(fā)這個軟件產(chǎn)品意義、作用、以及最終要達到的意圖。通過這份軟件產(chǎn)品需求分析報告詳盡說明了該軟件產(chǎn)品的需求規(guī)格,包括修正和(或)發(fā)行版本號,從而對該軟件產(chǎn)品進行準確的定義。
如果這份軟件產(chǎn)品需求分析報告只與整個系統(tǒng)的某一部分有關(guān)系,那么只定義軟件產(chǎn)品需求分析報告中說明的那個部分或子系統(tǒng)。
1.2 項目風險
具體說明本軟件開發(fā)項目的全部風險承擔者,以及各自在本階段所需要承擔的主要風險,首要風險承擔者包括:
● 任務(wù)提出者;
● 軟件開發(fā)者;
● 產(chǎn)品使用者。
1.3 文檔約定
描述編寫文檔時所采用的標準(如果有標準的話),或者各種排版約定。排版約定應(yīng)該包括:
● 正文風格;
● 提示方式;
● 重要符號;
也應(yīng)該說明高層次需求是否可以被其所有細化的需求所繼承,或者每個需求陳述是否都有其自己的優(yōu)先級。
1.4 預期讀者和閱讀建議
列舉本軟件產(chǎn)品需求分析報告所針對的各種不同的預期讀者,例如,可能包括:
● 用戶;
● 開發(fā)人員;
● 項目經(jīng)理;
● 營銷人員;
● 測試人員;
● 文檔編寫入員。
并且描述了文檔中,其余部分的內(nèi)容及其組織結(jié)構(gòu),并且針對每一類讀者提出最適合的文檔閱讀建議。
1.5 產(chǎn)品范圍
說明該軟件產(chǎn)品及其開發(fā)目的的簡短描述,包括利益和目標。把軟件產(chǎn)品開發(fā)與企業(yè)目標,或者業(yè)務(wù)策略相聯(lián)系。
描述產(chǎn)品范圍時需注意,可以參考項目視圖和范圍文檔,但是不能將其內(nèi)容復制到這里。
1.6 參考文獻
列舉編寫軟件產(chǎn)品需求分析報告時所用到的參考文獻及資料,可能包括:
● 本項目的合同書;
● 上級機關(guān)有關(guān)本項目的批文;
● 本項目已經(jīng)批準的計劃任務(wù)書;
● 用戶界面風格指導;
● 開發(fā)本項目時所要用到的標淮;
● 系統(tǒng)規(guī)格需求說明;
● 使用實例文檔;
● 屬于本項目的其它己發(fā)表文件;
● 本軟件產(chǎn)品需求分析報告中所引用的文件、資料;
● 相關(guān)軟件產(chǎn)品需求分析報告;
為了方便讀者查閱,所有參考資料應(yīng)該按一定順序排列。如果可能,每份資料都應(yīng)該給出:
● 標題名稱;
● 作者或者合同簽約者;
● 文件編號或者版本號;
● 發(fā)表日期或者簽約日期;
● 出版單位或者資料來源。
2. 綜合描述
這一部分概述了正在定義的軟件產(chǎn)品的作用范圍以及該軟件產(chǎn)品所運行的環(huán)境、使用該軟件產(chǎn)品的用戶、對該軟件產(chǎn)品己知的限制、有關(guān)該軟件產(chǎn)品的假設(shè)和依賴。
2.1 產(chǎn)品的狀況
描述了在軟件產(chǎn)品需求分析報告中所定義的軟件產(chǎn)品的背景和起源。說明了該軟件產(chǎn)品是否屬于下列情況:
● 是否是產(chǎn)品系列中的下一成員;
● 是否是成熟產(chǎn)品所改進的下一代產(chǎn)品;
● 是否是現(xiàn)有應(yīng)用軟件的替代品(升級產(chǎn)品);
● 是否是一個新型的、自主型的產(chǎn)品。
如果該軟件產(chǎn)品需求分析報告定義的軟件系統(tǒng)是:
● 大系統(tǒng)的一個組成部分;
● 與其它系統(tǒng)和其它機構(gòu)之間存在基本的相互關(guān)系。
那么必須說明軟件產(chǎn)品需求分析報告定義的這部分軟件是怎樣與整個大系統(tǒng)相關(guān)聯(lián)的,或者(同時)說明相互關(guān)系的存在形式,并且要定義出兩者之間的全部接口。
2.2 產(chǎn)品的功能
因為將在需求分析報告的第4部分中詳細描述軟件產(chǎn)品的功能,所以在此只需要概略地總結(jié)。僅從業(yè)務(wù)層面陳述本軟件產(chǎn)品所應(yīng)具有的主要功能,在描述功能時應(yīng)該 針對每一項需求準確地描述其各項規(guī)格說明。如果存在引起誤解的可能,在陳述本軟件產(chǎn)品主要功能的作用領(lǐng)域時,也需要對應(yīng)陳述本軟件產(chǎn)品的非作用領(lǐng)域,以利 讀者理解本軟件產(chǎn)品。
為了很好地組織產(chǎn)品功能,使每個讀者都容易理解,可以采用列表的方法給出。也可以采用圖形方式,將主要的需求分組以及它們之間的聯(lián)系使用數(shù)據(jù)流程圖的頂層圖或類圖進行表示,這種表示方法是很有用的。
參考用戶當前管理組織構(gòu)架,了解各個機構(gòu)的主要職能,將有助于陳述軟件產(chǎn)品的主要功能。
2.3 用戶類和特性
確定有可能使用該軟件產(chǎn)品的不同用戶類,并且描述它們相關(guān)的特征。往往有一些軟件需求,只與特定的用戶類有關(guān)。描述時,應(yīng)該將該軟件產(chǎn)品的重要用戶類與非重要用戶類區(qū)分開。
用戶不一定是軟件產(chǎn)品的直接使用者,通過報表、應(yīng)用程序接口、系統(tǒng)硬件接口得到軟件產(chǎn)品的數(shù)據(jù)和服務(wù)的人、或者機構(gòu)也有他們的需求。所以,應(yīng)該將這些外部需求視為通過報表、應(yīng)用程序接口、系統(tǒng)硬件接口附加給軟件產(chǎn)品的附加用戶類。
2.4 運行環(huán)境
描述了本軟件的運行環(huán)境,一般包括:
● 硬件平臺;
● 操作系統(tǒng)和版本;
● 支撐環(huán)境(例如:數(shù)據(jù)庫等)和版本;
● 其它與該軟件有關(guān)的軟件組件;
● 與該軟件共存的應(yīng)用程序。
2.5 設(shè)計和實現(xiàn)上的限制
確定影響開發(fā)人員自由選擇的問題,并且說明這些問題為什么成為一種限制??赡艿南拗瓢ㄏ铝袃?nèi)容:
● 必須使用的特定技術(shù)、工具、編程語言和數(shù)據(jù)庫;
● 避免使用的特定技術(shù)、工具、編程語言和數(shù)據(jù)庫;
● 要求遵循的開發(fā)規(guī)范和標準
例如,如果由客戶的公司或者第三方公司負責軟件維護,就必須定義轉(zhuǎn)包者所使用的設(shè)計符號表示和編碼標準;
● 企業(yè)策略的限制;
● 政府法規(guī)的限制;
● 工業(yè)標準的限制;
● 硬件的限制
例如,定時需求或存儲器限制;
● 數(shù)據(jù)轉(zhuǎn)換格式標淮的限制。
2.6 假設(shè)和約束(依賴)
列舉出對軟件產(chǎn)品需求分析報告中,影響需求陳述的假設(shè)因素(與己知因素相對立)。如果這些假設(shè)因素不正確、不一致或者被修改,就會使軟件產(chǎn)品開發(fā)項目受到影響。這些假設(shè)的因素可能包括:
● 計劃使用的商業(yè)組件,或者其它軟件中的某個部件;
● 假定產(chǎn)品中某個用戶界面將符合一個特殊的設(shè)計約定;
● 有關(guān)本軟件用戶的若干假定(例如:假定用戶會熟練使用sql語言。);
● 有關(guān)本軟件開發(fā)工作的若干假定(例如:用戶承諾的優(yōu)惠、方便、上級部門給予的特殊政策和支持等。);
● 有關(guān)本軟件運行環(huán)境的一些問題;
此外,確定本軟件開發(fā)項目對外部約束因素所存在的依賴。有關(guān)的約束可能包括:
● 工期約束;
● 經(jīng)費約束;
● 人員約束;
● 設(shè)備約束;
● 地理位置約束;
● 其它有關(guān)項目約束;
3. 外部接口需求
通過本節(jié)描述可以確定,保證軟件產(chǎn)品能和外部組件正確連接的需求。關(guān)聯(lián)圖僅能表示高層抽象的外部接口,必須對接口數(shù)據(jù)和外部組件進行詳細描述,并且寫入數(shù) 據(jù)定義中。如果產(chǎn)品的不同部分有不同的外部接口,那么應(yīng)該把這些外部接口的全部詳細需求并入到這一部分實例中。
注意:必須將附加用戶類的特征與外部接口需求加以區(qū)分,附加用戶類的特征描述的是通過接口取得軟件產(chǎn)品的數(shù)據(jù)和服務(wù)的人的需求;而外部接口需求描述的是接口本身的需求。
3.1 用戶界面
陳述需要使用在用戶界面上的軟件組件,描述每一個用戶界面的邏輯特征。必須注意,這里需要描述的是用戶界面的邏輯特征,而不是用戶界面。以下是可能包括的一些特征:
● 將要采用的圖形用戶界面(gul)標準或者產(chǎn)品系列的風格;
● 有關(guān)屏幕布局或者解決方案的限制;
● 將要使用在每一個屏幕(圖形用戶界面)上的軟件組件,可能包括:
選單;
標準按鈕;
導航鏈接;
各種功能組件;
消息欄;
● 快捷鍵;
● 各種顯示格式的規(guī)定,可能包括:
不同情況下文字的對齊方式;
不同情況下數(shù)字的表現(xiàn)格式與對齊方式;
日期的表現(xiàn)方法與格式;
計時方法與時間格式;
等等。
● 錯誤信息顯示標準;
對于用戶界面的細節(jié),例如:一個特定對話框的布局,應(yīng)該寫入具體的用戶界面設(shè)計說明中,而不能寫入軟件需求規(guī)格說明中。
如果采用現(xiàn)成的、合適的用戶界面設(shè)計規(guī)范(標準),或者另文描述,可以在這里直接說明,并且將其加入?yún)⒖嘉墨I。
3.2 硬件接口
描述待開發(fā)的軟件產(chǎn)品與系統(tǒng)硬件接口的特征,若有多個硬件接口,則必須全都描述。接口特征的描述內(nèi)容可能包括:
● 支持的硬件類型;
● 軟、硬件之間交流的數(shù)據(jù);
● 控制信息的性質(zhì);
● 使用的通訊協(xié)議;
3.3 軟件接口
描述該軟件產(chǎn)品與其它外部組件的連接,這些外部組件必須明確它們的名稱和版本號以資識別,可能的外部組件包括:
● 操作系統(tǒng);
● 數(shù)據(jù)庫;
● 工具;
● 函數(shù)庫;
● 集成的商業(yè)組件
說明:這里所說的“集成的商業(yè)組件”,是指與系統(tǒng)集成的商業(yè)組件,而不是與軟件產(chǎn)品集成的商業(yè)組件。例如:中間件、消息服務(wù),等等。
描述并且明確軟件產(chǎn)品與軟件組件之間交換數(shù)據(jù)或者消息的目的。描述所需要的服務(wù),以及與內(nèi)部組件通訊的性質(zhì)。確定軟件產(chǎn)品將與組件之間共享的數(shù)據(jù)。如果必 須使用一種特殊的方法來實現(xiàn)數(shù)據(jù)共享機制,例如:在多用戶系統(tǒng)中的一個全局數(shù)據(jù)區(qū),那么就必須把它定義為一種實現(xiàn)上的限制。
3.4 通訊接口
描述與軟件產(chǎn)品所使用的通訊功能相關(guān)的需求,包括:
● 電子郵件;
● web瀏覽器;
● 網(wǎng)絡(luò)通訊標準或者協(xié)議;
● 數(shù)據(jù)交互用電子表格;
必須定義相關(guān)的:
● 消息格式;
● 通訊安全或加密問題;
● 數(shù)據(jù)傳輸速率;
● 同步和異步通訊機制;
4. 系統(tǒng)功能需求
需要進行詳細的需求記錄,詳細列出與該系統(tǒng)功能相關(guān)的詳細功能需求,并且,唯一地標識每一項需求。這是必須提交給用戶的軟件功能,使得用戶可以使用所提供 的功能執(zhí)行服務(wù)或者使用所指定的使用實例執(zhí)行任務(wù)。描述軟件產(chǎn)品如何響應(yīng)己知的出錯條件、非法輸入、非法動作。
如果每一項功能需求都能用一項,也只需要用一項測試用例就能進行驗證,那么就可以認為功能需求已經(jīng)適當?shù)剡M行描述了。如果某項功能需求找不到合適的測試用例,或者必須使用多項測試用例才能驗證,那么該項功能需求的描述必然存在某些問題。
功能需求是根據(jù)系統(tǒng)功能,即軟件產(chǎn)品所提供的主要服務(wù)來組織的??梢酝ㄟ^使用實例、運行模式、用戶類、對象類或者功能等級來組織這部分內(nèi)容,也可以便用這些元素的組合。總而言之,必須選擇一種是讀者容易理解預期產(chǎn)品的組織方案。
用簡短的語句說明功能的名稱,例如:“4.1系統(tǒng)參數(shù)管理”。按照服務(wù)組織的順序,逐條闡述系統(tǒng)功能。無論說明的是何種功能,都應(yīng)該針對該系統(tǒng)功能重復敘述4.1~ 4.3這三個部分。
可以通過各種方式來組織這一部分內(nèi)容,例如采用:使用實例、運行模式、用戶類、對象類、功能等級等,也可以采用它們的組合。其最終目的是,讓讀者容易理解 即將開發(fā)的軟件產(chǎn)品。一般來說,每個使用實例都對應(yīng)一個系統(tǒng)功能,因而按照使用實例來組織內(nèi)容比較容易讓用戶理解。
對應(yīng)一些被共享的獨立使用實例,可以定義一些公用系統(tǒng)功能。
必須特別注意的是,在2.2節(jié)“產(chǎn)品的功能”中描述的全部需求,以及它們的規(guī)格說明;必須在某個系統(tǒng)功能描述中有所反映,而且不應(yīng)重復。
4.1 說明和優(yōu)先級
對該系統(tǒng)功能進行簡短的說明,并且指出該系統(tǒng)功能的優(yōu)先級是:高、中、還是低。需要的話,還可以包括對特定優(yōu)先級部分的評價,例如:利益、損失、費用和風險,其相對優(yōu)先等級可以從1(低)到9(高)。
4.2 激勵/響應(yīng)序列
列出輸入激勵(用戶動作、來自外部設(shè)備的信號或者其它觸發(fā))并且定義針對這——功能行為的系統(tǒng)響應(yīng)序列,這些序列將與使用實例中相關(guān)的對話元素相對應(yīng)。
描述激勵/響應(yīng)序列時,不僅需要描述基本過程,而且應(yīng)該描述可選(擴充)過程,包括例外(引起任務(wù)不能順序完成的情況稱為例外)。疏忽了可選過程,有可能影響軟件產(chǎn)品的功能;如果遺漏例外過程,則有可能會引發(fā)系統(tǒng)崩潰。
如果采用流程圖來描述激勵/響應(yīng)序列,比較容易讓用戶理解。
4.3 輸入/輸出數(shù)據(jù)
列出輸入數(shù)據(jù)(用戶輸入、來自外部接口的輸入或者其它輸入)并且定義針對這些輸入數(shù)據(jù)的處理(計算)方法,以及相應(yīng)地輸出數(shù)據(jù),描述對應(yīng)區(qū)別:輸入數(shù)據(jù)和輸出數(shù)據(jù)。
當有大量數(shù)據(jù)需要描述時,也可以分類描述數(shù)據(jù),并且注明各項數(shù)據(jù)的輸入、輸出屬性。
對于每一項數(shù)據(jù),均需要描述:
● 數(shù)據(jù)名稱;
● 實際含義;
● 數(shù)據(jù)類型;
● 數(shù)據(jù)格式;
● 數(shù)據(jù)約束;
對于復雜的處理方法,僅僅給出算法原理是不夠的,必須描述詳細的計算過程,并且列出每一步具體使用的實際算式;如果計算過程中涉及查表、判斷、迭代等處理方法,應(yīng)該給出處理依據(jù)和相關(guān)數(shù)據(jù)。如果計算方法很簡單,也可以將其從略,不加描述。
5. 其它非功能需求
在這里列舉出所有非功能需求,主要包括可靠性、安全性、可維護性、可擴展性、可測試性等。
5.1 性能需求
闡述不同應(yīng)用領(lǐng)域?qū)浖a(chǎn)品性能的需求,并且說明提出需求的原理或者依據(jù),以幫助開發(fā)人員做出合理的設(shè)計選擇。盡可能詳細地描述性能需求,如果需要,可以針對每個功能需求或者特征分別陳述其性能需求。在這里確定:
● 相互合作的用戶數(shù)量;
● 系統(tǒng)支持的并發(fā)操作數(shù)量;
● 響應(yīng)時間;
● 與實時系統(tǒng)的時間關(guān)系:
● 容量需求
存儲器;
磁盤空間;
數(shù)據(jù)庫中表的最大行數(shù)。
5.2 安全措施需求
詳盡陳述與軟件產(chǎn)品使用過程中可能發(fā)生的損失、破壞、危害相關(guān)的需求。定義必須采取的安全保護或動作,以及必須預防的潛在危險動作。明確軟件產(chǎn)品必須遵從的安全標準、策略、或規(guī)則。
5.3 安全性需求
詳盡陳述與系統(tǒng)安全性、完整性問題相關(guān)的需求,或者與個人隱私問題相關(guān)的需求。這些問題將會影響到軟件產(chǎn)品的使用,和軟件產(chǎn)品所創(chuàng)建或者使用的數(shù)據(jù)的保 護。定義用戶身份認證,或備授權(quán)需求。明確軟件產(chǎn)品必須滿足的安全性或者保密性策略。也可以通過稱為完整性的質(zhì)量屬性來闡述這些需求。一個典型的軟件系統(tǒng) 安全需求范例如下:“每個用戶在第一次登錄后,必須更改他的系統(tǒng)預置登錄密碼,系統(tǒng)預置的登錄密碼不能重用。”
5.4 軟件質(zhì)量屬性
詳盡陳述對客戶和開發(fā)人員至關(guān)重要的在軟件產(chǎn)品其它方面表現(xiàn)出來的質(zhì)量功能。這些功能必須是確定的、定量的、在需要時是可以驗證的。至少也應(yīng)該指明不同屬性的相對側(cè)重點,例如:易用性優(yōu)于易學性,或者可移植性優(yōu)于有效性。
5.5 業(yè)務(wù)規(guī)則
列舉出有關(guān)軟件產(chǎn)品的所有操作規(guī)則,例如:那些人在特定環(huán)境下可以進行何種操作。這些本身不是功能需求,但是他們可以暗示某些功能需求執(zhí)行這些規(guī)則。一個 業(yè)務(wù)規(guī)則的范例如下:“進行達到或者超過10,000,00元人民幣的儲蓄業(yè)務(wù)時,必須通過附加的管理員認證。”
列舉業(yè)務(wù)規(guī)則時,可以根據(jù)規(guī)則的數(shù)量,選取合適的編目方式。
5.6 用戶文檔
列舉出將與軟件產(chǎn)品一同交付的用戶文檔,并且明確所有己知用戶文檔的交付格式或標準,例如:
● 安裝指南
紙質(zhì)文檔,16開本;
● 用戶手冊
紙質(zhì)文檔,16開本;
● 在線幫助
● 電子文檔,與軟件產(chǎn)品一同分發(fā)、配置;
● 使用教程電子文檔,與軟件產(chǎn)品一同分發(fā)、配置。
6. 詞匯表
列出本文件中用到的專業(yè)術(shù)語的定義,以及有關(guān)縮寫的定義(如有可能,列出相關(guān)的外文原詞)。為了便于非軟件專業(yè)或者非計算機專業(yè)人士閱讀軟件產(chǎn)品需求分析 報告,要求使用非軟件專業(yè)或者非計算機專業(yè)的術(shù)語描述軟件需求。所以這里所指的專業(yè)術(shù)語,是指業(yè)務(wù)層面上的專業(yè)術(shù)語,而不是軟件專業(yè)或者計算機專業(yè)的術(shù) 語。但是,對于無法回避的軟件專業(yè)或者計算機專業(yè)術(shù)語,也應(yīng)該列入詞匯表并且加以準確定義。
7. 數(shù)據(jù)定義
數(shù)據(jù)定義是一個定義了應(yīng)用程序中使用的所有數(shù)據(jù)元素和結(jié)構(gòu)的共享文檔,其中對每個數(shù)據(jù)元素和結(jié)構(gòu)都準確描述:含義、類型、數(shù)據(jù)大小、格式、計量單位、精度 以及取值范圍。數(shù)據(jù)定義的維護獨立于軟件需求規(guī)格說明,并且在軟件產(chǎn)品開發(fā)和維護的任何階段,均向風險承擔者開放。
如果為軟件開發(fā)項目創(chuàng)建一個獨立的數(shù)據(jù)定義,而不是為每一項特性描述有關(guān)的數(shù)據(jù)項,有利于避免冗余和不一致性。但是卻不利于多人協(xié)同編寫需求分析報告,容 易遺漏數(shù)據(jù),也不方便閱讀。因此還是建議為每個特性描述有關(guān)的數(shù)據(jù)項,匯總數(shù)據(jù)項創(chuàng)建數(shù)據(jù)定義,再根據(jù)數(shù)據(jù)定義復核全部數(shù)據(jù),使得它們的名稱和含義完全一 致。必須注意的是,為了避免二義性,在匯總數(shù)據(jù)項時應(yīng)該根據(jù)數(shù)據(jù)項所代表的實際意義匯總,而不是根據(jù)數(shù)據(jù)項的名稱匯總。
在數(shù)據(jù)定義中,每個數(shù)據(jù)項除了有一個中文名稱外,還應(yīng)該為它取一個簡短的英文名稱,該英文名稱應(yīng)該符合命名規(guī)范,因為在軟件開發(fā)時將沿用該英文名稱??梢允褂玫忍柋硎緮?shù)據(jù)項,名稱寫在左邊,定義寫在右邊。常見數(shù)據(jù)項的描述方式如下:
● 原數(shù)據(jù)元素
一個原數(shù)據(jù)元素是不可分解的,可以將一個數(shù)量值賦給它。定義原數(shù)據(jù)元素必須確定其
含義、類型、數(shù)據(jù)大小、格式、計量單位、精度以及取值范圍。采用以星號為界的一行
注釋文本,描述原數(shù)據(jù)元素的定義。
● 選擇項
選擇項是一種只可以取有限離散值的特殊原數(shù)據(jù)元素,描述時一一枚舉這些值,并用方
括號括起來寫在原數(shù)據(jù)元素的定義前。在兩項離散值之間,使用管道符分隔。
● 組合項
組合項是一個數(shù)據(jù)結(jié)構(gòu)或者記錄,其中包含了多個數(shù)據(jù)項。這些數(shù)據(jù)項可以是原數(shù)據(jù)元
素,也可以是組合數(shù)據(jù)項,各數(shù)據(jù)項之間用加號連接。其中每個數(shù)據(jù)項都必須是數(shù)據(jù)定
義中定義過的,結(jié)構(gòu)中也可以包括其它結(jié)構(gòu),但是絕對不允許遞歸。如果數(shù)據(jù)結(jié)構(gòu)中有
可選項,使用圓括號把該項括起來。
● 重復項
重復項是組合項的一種特例,其中有一項將有多個實例出現(xiàn)在數(shù)據(jù)結(jié)構(gòu)中,使用花括號
把該項括起來。如果知道該項可能允許的范圍,就按“最小值:最大值”的形式寫在花
括號前。
8. 分析模型
這是一個可選部分,包括或涉及到相關(guān)的分析模型,例如:
● 數(shù)據(jù)流程圖;
● 類圖;
● 狀態(tài)轉(zhuǎn)換圖;
● 實體-關(guān)系圖。
9. 待定問題列表
編輯一張在軟件產(chǎn)品需求分析報告中待確定問題時的列表,把每一個表項都編上號,以便跟蹤調(diào)查。
【第5篇 需求分析工作總結(jié)
需求分析是項目開發(fā)的基礎(chǔ),基礎(chǔ)打的牢不牢直接關(guān)系到后面所有的工作,是項目實施成敗的關(guān)鍵
項目經(jīng)理博客
總體上說,我們的需求分析是做了,但是做得很不夠,我們做的需求只解決了我們能做出這樣的項目,但是沒有解決這樣的項目是不是真就是客戶想要的。造成這種狀況的原因主要是下面幾個情況:
客戶本身說不清楚
文物網(wǎng)是這樣,中彰國際更是這樣,但是這不能怪客戶,畢竟客戶在軟件方面的知識要少的多,也沒有相關(guān)的經(jīng)驗,可能心里只有一個想要的軟件的輪廓,于是可能會要求我們?nèi)ヌ嫠麄儊硗暾@個輪廓的細節(jié),而我們的能力、我們能否真正站在客戶角度去搜集和整理這些需求,就決定了這個需求的完整性和有效性。
需求自身經(jīng)常變動
隨著客戶對這個項目越來越深刻的理解,那么可能他的需求也會隨之改變,這些變化的可能性越大項目風險就會越大,我們在需求分析的時候就要充分考慮到哪些需求是相對固定的需求,哪些可能會是產(chǎn)生變動的需求,考慮到他的可變性,這樣設(shè)計功能和數(shù)據(jù)庫的時候不致因為后面的變動而影響整個工程。
分析人員或客戶理解有誤
畢竟,不是每個分析人員都是專業(yè)而合格的,為避免這種情況的發(fā)生,需求分析必須要有審核制度,公司自己內(nèi)部要審核一遍,客戶再審一遍,提出意見,修改后雙方共同評審簽字,確認。
由此出現(xiàn)的問題:
a) 需求分析過于籠統(tǒng),只關(guān)注到面上,沒有關(guān)注到點上,開發(fā)出來的東西在具體的細節(jié)上和客戶的理解有誤差,并且無法嚴格界定是否屬于需求變更。中彰的方案就是這樣的。
b) 需求報告只求我們這方評審通過,不去關(guān)心客戶的評審,認為只要客戶簽字認可就行。雖然簽字認可能夠給日后出現(xiàn)問題時劃清我們的責任,但是不能保證使項目實施成功。
c) 需求分析中含有技術(shù)實施上有難度的功能,一味的求全和盲目按照客戶的設(shè)想,受客戶影響過大,畢竟,很多時候,客戶的想法在實際實施過程中是不現(xiàn)實的,或者可以有更為簡便的方法來替代的。如中彰國際的在線交易功能,后臺大批量郵件群發(fā)功能。
d) 對雙方已經(jīng)確定的需求,實現(xiàn)以后并不適合客戶使用,需要按照變更手續(xù)執(zhí)行的時候,客戶可能會糾纏,提出“你們是專業(yè)人士,你們應(yīng)該事先能提醒我們可能會出現(xiàn)這種問題”并以此來把責任推給我們,而我們又不好完全按照變更手續(xù)執(zhí)行,因為可能激化雙方的矛盾,比如508的批量處理功能,因為屬于人事管理比較專業(yè)的細節(jié)問題,需求分析師開始沒有對客戶業(yè)務(wù)熟悉到如此細致的地步,而客戶也沒有過多關(guān)注這些細節(jié),導致軟件的某些功能不合用,較為繁瑣,而重新按著客戶的意見修改的話工作量比較大,導致成本增加、工期延長。
e) 項目的成熟度受客戶預算的限制。大部分客戶在項目投入上都是有預算的,在成本有上限的前提下,項目的功能設(shè)計(軟件的成熟度)方面必然受一定影響,畢竟功能越多越完善,相應(yīng)的開發(fā)成本就越高。這種功能上的不完善需要事先告知客戶并得到理解。
f) 此項工作的反復造成思想上的倦怠,使需求分析最后虎頭蛇尾。需求分析是一項繁瑣枯燥的工作,需要和客戶之間不斷的商討、確認和反復,另外由于大部分的客戶雖然安排專人負責這項工作,但是該人并不只做這項工作,特別當他被很多其他的事情纏身的時候,而無心細看提交過去的需求報告的時候,他很可能會給你一個錯覺,讓你認為他已經(jīng)真正的理解并認可了你的設(shè)計。結(jié)論
a) 需求分析是整個項目管理中需要重點控制的幾個關(guān)鍵節(jié)點之一,首先思想上一定要重視。
b) 需求分析報告的編寫者要參與到需求的搜集工作中,準確領(lǐng)會客戶的意圖,并轉(zhuǎn)化成軟件能夠?qū)崿F(xiàn)的功能。對于說不清楚需求的客戶,要善于問關(guān)鍵問題,引導客戶提出自己的需求。可以采取的措施是事先編制一個問卷調(diào)查之類的文檔,詳細列舉需要客戶回答的問題,以便防止遺漏。
c) 需求報告的編寫者要能夠?qū)蛻粜枨筮M行深入分析,區(qū)別出哪些需求存在日后變更的可能,哪些需求屬于相對固定的,哪些需求能夠?qū)崿F(xiàn),哪些需求需要變通才能實現(xiàn),以便于指導后面的功能設(shè)計。
d) 需求分析報告對功能細節(jié)的描述不能有歧義,描述一定要全面、準確,防止開發(fā)方和客戶只見對同一個問題有兩個截然不同的理解。可以通過評審,用大家的力量來避免這種情況發(fā)生
e) 需求報告的每個關(guān)乎功能的描述都要讓客戶明白和理解,客戶在理解之上的確認才能夠保證日后一旦出現(xiàn)問題不致出現(xiàn)雙方互相推托責任糾纏不清的情況。
f) 需求報告一定要經(jīng)過一個有技術(shù)人員和業(yè)務(wù)人員參加的評審,要充分發(fā)揮團隊的力量,重視每個人的才智,一個模塊一個功能的逐一的過,讓大家來共同找出需求報告里不合理的、有歧義的、不完善的、遺漏的等等問題
g) 幫助客戶去理解提交給他的需求分析報告而不是只等簽字,對于有能夠用好幾種方式實現(xiàn)的功能,盡量做到能讓客戶去比較和選擇。不要讓客戶對報告中的部分產(chǎn)生歧義。只有客戶對報告的完全的理解,才能在日后客戶提出的修改被認為是需求變更的時候能夠得到客戶的理解
h) 最后,需求分析報告一定要雙方共同簽字確認