軟件需求分析(軟件需求獲取時應(yīng)注意哪些問題)

1.軟件需求獲取時應(yīng)注意哪些問題

1）應(yīng)能適當(dāng)?shù)卣{(diào)整收集范圍。在收集需求信息的開始，開發(fā)人員并不知道用戶需求信息量的大小，可以根據(jù)系統(tǒng)的范圍適當(dāng)擴(kuò)大收集范圍。但也不能過于擴(kuò)大收集范圍，因為在擴(kuò)大的范圍內(nèi)收集的需求信息有些可能不是真正的需求，這將導(dǎo)致開發(fā)人員要花費大量的精力和時間來理解和分析這些需求信息。顯然，收集的范圍也不能太小，否則有些重要需求會被遺漏或排除在外。

2）盡量把用戶所持的假設(shè)解釋清楚，特別是發(fā)生沖突的部分。這就需要根據(jù)用戶所講的話或提供的文字去理解，以明確用戶沒有表達(dá)清楚的、但又想加入的需求信息。

3）盡量理解用戶用于表達(dá)他們需求的思維過程，特別是盡量熟悉和掌握用戶具有的一些專業(yè)知識和術(shù)語。

4）在收集需求信息時，應(yīng)盡量避免受不熟悉細(xì)節(jié)的影響，如一些表格的具體設(shè)計等，。這些可作為需求先記錄下來。但也不能過于擴(kuò)大收集范圍，可以根據(jù)系統(tǒng)的范圍適當(dāng)擴(kuò)大收集范圍，特別是盡量熟悉和掌握用戶具有的一些專業(yè)知識和術(shù)語，否則有些重要需求會被遺漏或排除在外1）應(yīng)能適當(dāng)?shù)卣{(diào)整收集范圍。

4）在收集需求信息時。顯然，這將導(dǎo)致開發(fā)人員要花費大量的精力和時間來理解和分析這些需求信息。

6）需求信息收集工作的結(jié)束。

安排收集工作的結(jié)束時間已到。在收集需求信息的開始、但又想加入的需求信息。

用戶重復(fù)提出以前已提出的需求信息，因為需求階段的工作是要弄清楚軟件系統(tǒng)做什么。

3）盡量理解用戶用于表達(dá)他們需求的思維過程。

開發(fā)人員本身已提不出更多的問題。例如，收集的范圍也不能太小，特別是發(fā)生沖突的部分，需根據(jù)實際情況進(jìn)行判斷，應(yīng)盡量避免受不熟悉細(xì)節(jié)的影響。

5）應(yīng)盡量避免討論一些具體的解決方案。這就需要根據(jù)用戶所講的話或提供的文字去理解，但如何決定收集工作的結(jié)束并沒有一個簡單和嚴(yán)格的標(biāo)準(zhǔn)。需求信息的收集過程并不是沒完沒了的，而不是怎么做，以明確用戶沒有表達(dá)清楚的：

用戶不可能再提供更多新的需求信息，如一些表格的具體設(shè)計等。

2）盡量把用戶所持的假設(shè)解釋清楚。

與用戶的討論開始進(jìn)入設(shè)計方面的工作，開發(fā)人員并不知道用戶需求信息量的大小，因為在擴(kuò)大的范圍內(nèi)收集的需求信息有些可能不是真正的需求，然后再由設(shè)計工作去完成

2.軟件需求設(shè)計評審須知的8大注意是什么

、注意對需求規(guī)格說明的正確性進(jìn)行評審 需求規(guī)格說明的正確性通?？梢詮娜缦路矫娴靡泽w現(xiàn)： 是否有需求與其他需求相互沖突或者重復(fù)？通常一份長達(dá)幾百頁的需求規(guī)格說明書都不會是一蹴而就的，它可能是系統(tǒng)分析師幾個夜晚的心血之作。

正是因為撰寫過程的連續(xù)性，可能導(dǎo)致同一份文檔中前后名詞定義不一致，前后觀點上有重疊或差異的情況出現(xiàn)，這需要我們在撰寫報告前首先要在思想上形成統(tǒng)一概念， 可使術(shù)語列表貫穿整份文檔以達(dá)提綱挈領(lǐng)之效。 是否清晰、簡潔、無二義地表達(dá)了每個需求？ “清晰”是讓人能夠讀懂；“簡潔”是讓人愿意去讀；“無二義”決定”讀”的效果，是讓大家對需求描述的理解能夠達(dá)成一致。

需求陳述是“三重門”，這三扇門是否開啟決定了需求說明書的質(zhì)量高低。我們尤其要拒絕“二義性”的名詞術(shù)語的出現(xiàn)， 似是而非的概念定義是需求書應(yīng)該避免的。

換句話說，如果一份需求說明書沒能給人以清晰、簡潔和無二義的闡述，則需求評審是沒有進(jìn)行下去的必要，同時也無法進(jìn)行下去。需求評審的前提是用戶讀懂了需求說明，并且用戶的理解內(nèi)容就是分析師們所描述的內(nèi)容。

是否每個需求都通過了演示、測試、評審，分析是否得到了驗證？ 需求應(yīng)該是可以測試的，通常通過測試去驗證它是不是正確。 比如我們完成了“銷售員客戶傭金提成規(guī)則”需求的撰寫，如果需求書未能經(jīng)過原型測試通過，則需求評審是不能得到通過的。

面對相當(dāng)復(fù)雜的業(yè)務(wù)需求，經(jīng)過測試或演示是讓用戶信任的一個必要過程。試想一下， 如果連需求都不能很好地被確認(rèn)，則開發(fā)實現(xiàn)階段更是沒有把握控制了。

是否每個需求都在項目的范圍內(nèi)？ 劃分項目范圍和區(qū)分系統(tǒng)邊界同樣是需求說明書的一個任務(wù)，不要對需求書作出超范圍的論述和延伸，要知道需求書不是分析師賣弄概念、展示時尚的場所，它是軟件工程的一個重要環(huán)節(jié)。 是否每個需求都沒有內(nèi)容和語法上的錯誤？按照傳統(tǒng)的需求列表方式，需求像菜單一樣被一條條列出來，構(gòu)成需求項的主要欄位包括：需求ID、需求描述、優(yōu)先級、來源和狀態(tài)等。

通常需求首先要經(jīng)過“拼寫檢查”，保證沒有拼寫上的問題，然后通過逐行瀏覽修改那些在內(nèi)容或行文上出現(xiàn)問題的需求。 在現(xiàn)有的資源內(nèi)， 是否能實現(xiàn)所有的需求？ 需求規(guī)格說明要考慮可行性的問題。

事實上，分析師的關(guān)注層面是價值驅(qū)動和成本驅(qū)動方面。分析師應(yīng)該明白不是所有的需求都要去實現(xiàn)，一些看上去很明顯與涉及用戶有沖突的、費力不討好的需求應(yīng)該果斷地舍棄。

國內(nèi)有專家提出，搞需求也要講“和諧”即是此中道理。 每一條特定的錯誤信息，是否都是唯一的和具有含義的？ 不要忽視錯誤信息的定義， 它必須具有唯一性。

如果過于籠統(tǒng)地定義錯誤信息則和沒有定義的效果是一樣的。 二、注意對需求規(guī)格說明的實踐性進(jìn)行評審 所謂實踐性是指需求本身是否來源于目前企業(yè)的相關(guān)業(yè)務(wù)規(guī)則和文件制度，而非源于分析師們經(jīng)驗主義的臆測。

實踐性是判斷需求規(guī)格說明是不是理論聯(lián)系實踐、密切和用戶聯(lián)系的一個關(guān)鍵性指標(biāo)。如果需求規(guī)格說明和用戶實踐脫離，即使看上去寫得再天花亂墜，也會使需求說明如同無根之樹、無源之水，會大大減低用戶對需求報告本身的信任度。

有經(jīng)驗的系統(tǒng)分析師通常會迷信自己的經(jīng)驗，把從前的經(jīng)驗嫁接到目前的企業(yè)需求分析中。 也許由于行業(yè)性質(zhì)相同，但如果不經(jīng)過當(dāng)前的實踐調(diào)研則給出需求，仍然會無法體現(xiàn)出企業(yè)自身的特征。

因而不能為企業(yè)帶來真正的價值，也會造成與用戶需求的鴻溝。 筆者也曾經(jīng)“輕實踐重抽象”，我認(rèn)為系統(tǒng)分析師的工作特點是站在具體案例上的深度抽象，前提是必須獲得本企業(yè)的一手具體業(yè)務(wù)背景、流程和規(guī)則。

我們在分析比如“任務(wù)跟蹤”之類的系統(tǒng)時，由于系統(tǒng)的抽象模型是已知的（通過大量同類軟件的分析得知），但還是需要分析師把抽象模型演繹到企業(yè)當(dāng)前業(yè)務(wù)現(xiàn)狀。這樣的需求分析才會有“實話實說”之效，才能引發(fā)評審者的共鳴。

否則，在需求評審中評審者是很難讀懂你的意圖，自然不會立即通過你的需求報告，導(dǎo)致需要重新返工撰寫需求報告。 三、注意對需求規(guī)格說明的完整性進(jìn)行評審 我們經(jīng)常由下面的問題清單來評審需求說明書是否“完整”。

1 編寫的所有需求，其詳細(xì)程度是否一致和合適？ 2 需求是否能為設(shè)計提供足夠的基礎(chǔ)？ 3 所有對其他需求的內(nèi)部引用是否正確？ 4 是否包含了每個需求的實現(xiàn)優(yōu)先級？ 5 是否定義了功能說明的內(nèi)在算法？ 6 是否包含了所有已知的客戶需求或系統(tǒng)需求？ 7 是否遺漏了必要的信息？如果有遺漏的話，把他們標(biāo)記為待確定的問題（TBD）? 8 是否對所有預(yù)期的錯誤條件所產(chǎn)生的系統(tǒng)行為都編制了文檔？ 需求說明的完整性主要體現(xiàn)在需求說明的詳細(xì)程度上，我們怎樣判斷該需求的描述是否詳細(xì)呢？我認(rèn)為需求需要精化，而不是僅僅提出精化功能、對象要考慮涉眾參與者、做些什么、需要什么數(shù)據(jù)信息、受什么業(yè)務(wù)規(guī)則和條件限制、系統(tǒng)會有什么響應(yīng)，等等。

3.怎樣做軟件的需求分析

軟件需求的定義：（1）用戶解決問題或達(dá)到目標(biāo)所需的條件或能力。

（2）系統(tǒng)或系統(tǒng)部件要滿足合同、標(biāo)準(zhǔn)、規(guī)范或其它正式規(guī)定文檔所需具有的條件或能力。（3）一種反映上面（1）或（2）所描述的條件或權(quán)能的文檔說明。

實通俗的講，“需求”就是用戶的需要，它包括用戶要解決的問題、達(dá)到的目標(biāo)、以及實現(xiàn)這些目標(biāo)所需要的條件，它是一個程序或系統(tǒng)開發(fā)工作的說明，表現(xiàn)形式一般為文檔形式。需求工程的定義：需求分析的過程，也叫做需求工程和需求階段，它包括了需求開發(fā)和需求管理兩個部分。

需求開發(fā)是指從情況收集、分析和評價到編寫文檔、評審等一系列產(chǎn)生需求的活動，分為四個階段：情況獲取、分析、制訂規(guī)格說明和評審。這四個階段不一定是遵循線性順序的，他們的活動是相互獨立和反復(fù)的。

需求管理是軟件項目開發(fā)過程中控制和維持需求約定的活動，它包括：變更控制、版本控制、需求跟蹤、需求狀態(tài)跟蹤等工作。需求開發(fā)與管理的一些方法：（1）繪制關(guān)聯(lián)圖：繪制系統(tǒng)關(guān)聯(lián)圖是用于定義系統(tǒng)與系統(tǒng)外部實體間的界限和接口的簡單模型。

（2）可行性分析：在允許的成本、性能要求下，分析每項需求實施的可行性，提出需求實現(xiàn)相關(guān)風(fēng)險，包括與其它需求的沖突，對外界因素的依賴和技術(shù)障礙。（4）系統(tǒng)原型：當(dāng)用戶自身對有的需求不十分清楚時，我們可以建立一個系統(tǒng)原型，用戶通過評價原型更好地理解所要解決的問題。

（5）圖形分析模型：繪制圖形分析模型是編制軟件需求規(guī)格說明重要手段。

它們能幫助分析人員理清數(shù)據(jù)、業(yè)務(wù)模式、工作流程以及他們之間的關(guān)系，找出遺漏、冗余和不一致的需求。這樣的模型包括數(shù)據(jù)流圖、實體關(guān)系圖、狀態(tài)變換圖、對話框圖、對象類及交互作用圖。

（6）數(shù)據(jù)字典：數(shù)據(jù)字典是對系統(tǒng)用到的所有數(shù)據(jù)項和結(jié)構(gòu)的定義，以確保開發(fā)人員使用統(tǒng)一的數(shù)據(jù)定義。在需求階段，數(shù)據(jù)字典至少應(yīng)定義客戶數(shù)據(jù)項，確?？蛻襞c開發(fā)小組是使用一致的定義和術(shù)語。

需求管理的方法主要包括以下一些方面：1）確定需求變更控制過程。制定一個選擇、分析和決策需求變更的過程，所有的需求變更都需遵循此過程。

2）進(jìn)行需求變更影響分析。評估每項需求變更，以確定它對項目計劃安排和其它需求的影響，明確與變更相關(guān)的任務(wù)并評估完成這些任務(wù)需要的工作量。

通過這些分析將有助于需求變更控制部門做出更好的決策。3）建立需求基準(zhǔn)版本和需求控制版本文檔。

確定需求基準(zhǔn)，這是項目各方對需求達(dá)成一致認(rèn)識時刻的一個快照，之后的需求變更遵循變更控制過程即可。每個版本的需求規(guī)格說明都必須是獨立說明，以避免將底稿和基準(zhǔn)或新舊版本相混淆。

4）維護(hù)需求變更的歷史記錄。將需求變更情況寫成文檔，記錄變更日期、原因、負(fù)責(zé)人、版本號等內(nèi)容，及時通知到項目開發(fā)所涉及的人員。

為了盡量減少困惑、沖突、誤傳，應(yīng)指定專人來負(fù)責(zé)更新需求。5）跟蹤每項需求的狀態(tài)。

可以把每一項需求的狀態(tài)屬性（如已推薦的，已通過的，已實施的，或已驗證的）保存在數(shù)據(jù)庫中，這樣可以在任何時候得到每個狀態(tài)類的需求數(shù)量。6）衡量需求穩(wěn)定性。

可以定期把需求數(shù)量和需求變更（添加、修改、刪除）數(shù)量進(jìn)行比較。過多的需求變更"是一個報警信號"，意味著問題并未真正弄清楚。

4.需求分析評價標(biāo)準(zhǔn)（1）清晰：目前大多數(shù)的需求分析采用的仍然是自然語言，自然語言對需求分析最大的弊病就是它的二義性，所以開發(fā)人員需要對需求分析中采用的語言做某些限制。例如盡量采用主語+動作的簡單表達(dá)方式。

需求分析中的描述一定要簡單，千萬不要采用疑問句、修飾這些復(fù)雜的表達(dá)方式。 除了語言的二義性之外，注意不要使用行話，就是計算機(jī)術(shù)語。

需求分析最重要的是和用戶溝通，可是用戶多半不是計算機(jī)的專業(yè)人士，如果在需求分析中使用了行話，就會造成用戶理解上的困難。（2）完整：需求的完整性是非常重要的，如果有遺漏需求，則不得不返工，在軟件開發(fā)過程中，最糟糕的事情莫過于在軟件開發(fā)接近完成時發(fā)現(xiàn)遺漏了一項需求。

但實際情況是，需求的遺漏是常發(fā)生的事情，這不僅僅是開發(fā)人員的問題，更多發(fā)生在用戶那里。要做到需求的完整性是很艱難的一件事情，它涉及到需求分析過程的各個方面，貫穿整個過程，從最初的需求計劃制定到最后的需求評審。

（3）一致：一致性是指用戶需求必須和業(yè)務(wù)需求一致，功能需求必須和用戶需求一致。在需求過程中，開發(fā)人員需要把一致性關(guān)系進(jìn)行細(xì)化，比如用戶需求不能超出預(yù)前指定的范圍。

嚴(yán)格的遵守不同層次間的一致性關(guān)系，就可以保證最后開發(fā)出來的軟件系統(tǒng)不會偏離最初的實現(xiàn)目標(biāo)。（4）可測試：一個項目的測試從什么時候開始呢？有人說是從編碼完成后開始，有人說是編碼的時候同時進(jìn)行單元測試，編碼完成后進(jìn)行系統(tǒng)測試，這些結(jié)論都不完全正確。

實際上，測試是從需求分析過程就開始了，因為需求是測試計劃的輸入和參照。這就要求需求分析是可測試的，只有系統(tǒng)的所有需求都是可以被測試的，才能夠保證軟件始終圍繞著用戶的需要，保證軟件系統(tǒng)是成功的。

4.軟件需求分析的過程

軟件需求分析所要做的工作是深入描述軟件的功能和性能，確定軟件設(shè)計的限制和軟件同其它系統(tǒng)元素的接口細(xì)節(jié)，定義軟件的其它有效性需求。

進(jìn)行需求分析時，應(yīng)注意一切信息與需求都是站在用戶的角度上。盡量避免分析員的主觀想象，并盡量將分析進(jìn)度提交給用戶。在不進(jìn)行直接指導(dǎo)的前提下，讓用戶進(jìn)行檢查與評價。從而達(dá)到需求分析的準(zhǔn)確性。

分析員通過需求分析，逐步細(xì)化對軟件的要求，描述軟件要處理的數(shù)據(jù)域，并給軟件開發(fā)提供一種可轉(zhuǎn)化為數(shù)據(jù)設(shè)計、結(jié)構(gòu)設(shè)計和過程設(shè)計的數(shù)據(jù)和功能表示。在軟件完成后，制定的軟件規(guī)格說明還要為評價軟件質(zhì)量提供依據(jù)。

5.p2p網(wǎng)貸系統(tǒng)需求分析需要注意哪些事項

需求分析一直是所有軟件在開發(fā)時重點關(guān)注內(nèi)容，那么迪蒙p2p網(wǎng)貸系統(tǒng)開發(fā)需求分析應(yīng)需要注意以下幾點：一、功能需求，即p2p網(wǎng)貸軟件需要有什么功能，包括主要的和非主要的，一般來講，功能是最后驗證軟件是否成功開發(fā)的方法之一。

二、非功能需求，非功能需求是指功能需求以外的需求，如性能需求，比如p2p網(wǎng)站的響應(yīng)時間、擴(kuò)展性，還可能是界面用什么背景色，一般來說功能需求是比較受客戶重視的，非功能需求一般很少提要求，不過我們還是要注意，畢竟非功能需求也涉及到用戶體驗和以后的軟件維護(hù)。三、約束，約束是指一些條件限制，如數(shù)據(jù)約束。

約束要在p2p網(wǎng)貸軟件需求分析階段考慮清楚，如果沒有約束，那么所有的人都可以進(jìn)入p2p網(wǎng)站，那么平臺的結(jié)果可以一想而知?！靶枨蟆笔亲プ∮脩粽嬲男枨?，“分析”是分析用戶的習(xí)慣，p2p網(wǎng)貸軟件需求分析做的越好，那么后續(xù)p2p網(wǎng)站開發(fā)做的就會越成功。