發(fā)布時(shí)間：2017-04-26 19:20

  本文關(guān)鍵詞：掌握需求過程，由筆耕文化傳播整理發(fā)布。

【活動(dòng)】Python創(chuàng)意編程活動(dòng)開始啦�。�！      CSDN日?qǐng)?bào)20170424 ——《技術(shù)方向的選擇》      程序員4月書訊：Angular來了！

掌握需求過程

標(biāo)簽：

本文章已收錄于：

分類：

掌握需求過程

后篇

第十章 功能需求

功能需求是產(chǎn)品為了支持工作而必須做的事情，它們的表述應(yīng)該盡可能獨(dú)立于實(shí)現(xiàn)需求的技術(shù)。作為業(yè)務(wù)分析師不要嘗試打造技術(shù)方案，而是要指定技術(shù)解決方案必須做的事，如何實(shí)現(xiàn)結(jié)果是設(shè)計(jì)師的事情。場(chǎng)景中包含3-10個(gè)步驟給出合理的細(xì)節(jié)程度，又不會(huì)讓非技術(shù)的利益相關(guān)者感覺太復(fù)雜�？刂菩枨竺枋龅募�(xì)節(jié)程度或粒度，在需求描述中添加理由，在許多情況下，這是需求的關(guān)鍵部分。不論需求最終如何實(shí)現(xiàn)，寫下描述和理由顯然會(huì)引導(dǎo)發(fā)現(xiàn)真正的需求。
在編寫需求時(shí)，不只要注意一詞多義，如果產(chǎn)品的上下文不清楚，也會(huì)引起二義性。需求的層次結(jié)構(gòu)，工作上下文范圍是最高層次的需求說明，它分解為下一個(gè)層次即業(yè)務(wù)事件，業(yè)務(wù)事件下一層由產(chǎn)品用例組成，每個(gè)產(chǎn)品用例又被分解為一些產(chǎn)品用例步驟，最底層的需求包括原子需求，每項(xiàng)原子需求都可以追蹤到高層的用例步驟。有場(chǎng)景、用戶故事（作為[角色]，我想要[功能]，這樣就能[使用該功能的理由]）、業(yè)務(wù)過程模型等多種方法來描述產(chǎn)品的功能。
功能需求描述了產(chǎn)品的處理動(dòng)作，即為了支持業(yè)務(wù)而必須做的事，功能需求是產(chǎn)品功能描述，它應(yīng)該是完整的，并盡量避免二義性。

第十一章 非功能需求

非功能需求描述產(chǎn)品將失去做到什么程度。把功能需求看成是使產(chǎn)品工作的需求，把非功能需求看成是為工作增加某些特征的需求。非功能需求描述了特征或功能完成的方式。非功能需求類型包括感官、易用性和人性化、執(zhí)行、操作、可維護(hù)行性和支持、安全、文化和政策、法律等。

需求類型有助于發(fā)現(xiàn)需求的工具，可以將需求類型看作一份檢查清單，將來會(huì)為每項(xiàng)需求加上驗(yàn)收標(biāo)準(zhǔn)，并使它可測(cè)試。我們可以通過用博客記錄需求、用例、模板、原型、客戶等來發(fā)現(xiàn)非功能需求。非功能需求也許看起來有些模糊，需要在寫驗(yàn)收標(biāo)準(zhǔn)時(shí)，寫下測(cè)量指標(biāo)，，量化每項(xiàng)需求的含義。

第十二章 驗(yàn)收標(biāo)準(zhǔn)和理由

驗(yàn)收意味著解決方案準(zhǔn)確地實(shí)現(xiàn)了需求所要求做的事情，或具備需求所要求的屬性。需求本身必須是可測(cè)量的，需求的測(cè)量指標(biāo)就是驗(yàn)收標(biāo)準(zhǔn)，它量化了需求的行為、執(zhí)行方式以及一些其他品質(zhì)。
驗(yàn)收標(biāo)準(zhǔn)既不是測(cè)試，也不是對(duì)測(cè)試的設(shè)計(jì)，而是測(cè)試提交的產(chǎn)品時(shí)必須采用的測(cè)試基準(zhǔn)。它是構(gòu)建測(cè)試用例的輸入信息，測(cè)試者通過測(cè)試用例來確保產(chǎn)品的每項(xiàng)需求都符合它的驗(yàn)收標(biāo)準(zhǔn)。驗(yàn)收標(biāo)準(zhǔn)是產(chǎn)品要執(zhí)行的、無二義性的測(cè)試基準(zhǔn)。通過檢查需求描述和理由，確定哪種量化方式最能體現(xiàn)用戶需求的意圖，從而導(dǎo)出驗(yàn)收標(biāo)準(zhǔn)。

第十三章 質(zhì)量關(guān)

質(zhì)量關(guān)是檢查每項(xiàng)需求并確保它合適的活動(dòng)，對(duì)需求活動(dòng)提供清晰、完整和無二義性的描述，說明要構(gòu)建什么，所有的需求都必須經(jīng)過質(zhì)量關(guān)的確認(rèn)。當(dāng)規(guī)范的潛在需求到達(dá)質(zhì)量關(guān)時(shí)，它應(yīng)該足夠完整，以便能進(jìn)行測(cè)試，決定是否納入規(guī)格說明書。被拒絕的需求退回給提出者，要求澄清、修改或取消。質(zhì)量關(guān)防止不受歡迎、不想要的需求進(jìn)入規(guī)格說明。
拒絕的需求：

質(zhì)量關(guān)守關(guān)人的任務(wù)就是確保驗(yàn)收標(biāo)準(zhǔn)是合理的需求測(cè)量指標(biāo)，即可以對(duì)照需求來測(cè)試產(chǎn)品。驗(yàn)收標(biāo)準(zhǔn)使用數(shù)據(jù)來表達(dá)需求，但數(shù)字本身必須不是主觀確定的，要基于事實(shí)依據(jù)。驗(yàn)收標(biāo)準(zhǔn)可以采用事先定義的標(biāo)準(zhǔn)。安全需求可能也會(huì)采用標(biāo)準(zhǔn)作為驗(yàn)收標(biāo)準(zhǔn)，要么是特定行業(yè)的安全標(biāo)準(zhǔn)，要么是組織結(jié)構(gòu)自己的安全標(biāo)準(zhǔn)。驗(yàn)收標(biāo)準(zhǔn)采用數(shù)字還是引用標(biāo)準(zhǔn)，取決于需求的類型，執(zhí)行需求和可用性需求通常采用數(shù)字，而觀感、安全和文化等需求大多采用標(biāo)準(zhǔn)。高價(jià)值的需求要溝通和談判，低價(jià)值的需求要放棄。在“伙伴結(jié)對(duì)”中，需求分析師相互測(cè)試得到的需求。如果兩個(gè)分析師懂得客觀地對(duì)待彼此的工作，這種策略最有效。質(zhì)量關(guān)對(duì)潛在的需求進(jìn)行測(cè)試，評(píng)估標(biāo)準(zhǔn)如下：

通過防止不正確的需求進(jìn)入規(guī)格說明書，質(zhì)量關(guān)降低了開發(fā)成本。因?yàn)楸M早消除錯(cuò)誤是開發(fā)產(chǎn)品最快、最省錢的方式。

第十四章 需求與迭代開發(fā)

一些開發(fā)技術(shù)如SCRUM、Crystal Clear、極限編程、看板等，這些技術(shù)的目的是迭代式地交付能工作的產(chǎn)品，迭代式地構(gòu)建產(chǎn)品。分析業(yè)務(wù)需求是一項(xiàng)持續(xù)的活動(dòng)，收集新的業(yè)務(wù)要求并對(duì)它們進(jìn)行探討、評(píng)估和排列優(yōu)先級(jí)。大多數(shù)迭代過程通過用戶故事來溝通，一組用戶故事代表了下一個(gè)發(fā)行版需要的功能。用戶故事是一種方式，它大致相當(dāng)于產(chǎn)品用例（PUC）場(chǎng)景中的一個(gè)步驟，用戶故事起源于極限編程，但現(xiàn)在已經(jīng)被大多數(shù)迭代方法所接受。用戶故事的常見形式是：最為[角色]，我想要[功能]，以便能實(shí)現(xiàn)[理由]。故事寫下來，被加到開發(fā)列表中，為它們排列優(yōu)先級(jí)，根據(jù)架構(gòu)和開發(fā)的要求，當(dāng)然還有業(yè)務(wù)的要求。這種優(yōu)先級(jí)排列是連續(xù)的。
用戶故事確定了產(chǎn)品要為用戶做的事情，但它也必須關(guān)注業(yè)務(wù)用例所確定的業(yè)務(wù)問題，因此，BUC作為故事的起點(diǎn)，每個(gè)BUC通常導(dǎo)出一個(gè)或多個(gè)故事。BUC提供了業(yè)務(wù)指導(dǎo)，這樣用戶故事會(huì)支持業(yè)務(wù)，而不只是確定用戶界面。好故事帶來卓越的產(chǎn)品。
擴(kuò)展用戶故事設(shè)計(jì)一些領(lǐng)域?qū)＜业妮斎胄畔ⅲ簶I(yè)務(wù)、易用性、安全性、觀感等非功能需求。業(yè)務(wù)是項(xiàng)目中最關(guān)鍵的部分，業(yè)務(wù)知識(shí)很重要。因?yàn)闃I(yè)務(wù)分析師既不屬于業(yè)務(wù)，也不屬于開發(fā)團(tuán)隊(duì)，所以業(yè)務(wù)分析師是業(yè)務(wù)知識(shí)的有用來源。技術(shù)知識(shí)體現(xiàn)為開發(fā)者、系統(tǒng)架構(gòu)師、測(cè)試員、外部供應(yīng)商等角色的某種組合。業(yè)務(wù)專家關(guān)注業(yè)務(wù)的運(yùn)營(yíng)以及他們的日常工作，技術(shù)專家投身于解決方案和追蹤最新技術(shù)，他們的工作是完成項(xiàng)目和解決問題。
有了業(yè)務(wù)分析師和其他人給出的輸入信息和解釋，開發(fā)者寫下最能滿足業(yè)務(wù)要求的故事。開發(fā)者對(duì)開發(fā)列表中的用戶故事排列優(yōu)先級(jí)，針對(duì)選出的故事，擴(kuò)展并決定產(chǎn)品下一個(gè)發(fā)行版要實(shí)現(xiàn)的原子需求。

第十五章 復(fù)用需求

在一個(gè)組織結(jié)構(gòu)中，項(xiàng)目常常構(gòu)建相同或類似的產(chǎn)品。需求復(fù)用指利用為其他項(xiàng)目寫下的需求。有一下幾種來源：規(guī)格說明書的復(fù)用庫(kù)、相同領(lǐng)域的需求規(guī)格說明或來自其他人的經(jīng)驗(yàn)。成功的復(fù)用始于一種組織文化，這種文化有意識(shí)地鼓勵(lì)復(fù)用，而不是重新發(fā)明。啟動(dòng)會(huì)議的提交產(chǎn)物為確定可復(fù)用的知識(shí)提供了關(guān)注點(diǎn)，否則這些知識(shí)也許不能發(fā)現(xiàn)。如果每個(gè)人都按一致的方式來組織需求和使用術(shù)語，那么所有的需求就更容易被將來的項(xiàng)目路復(fù)用。
非正式的、有關(guān)經(jīng)驗(yàn)的需求復(fù)用：當(dāng)我們向同事問問題時(shí)，我們希望從他人的經(jīng)驗(yàn)中學(xué)習(xí)，這樣不必從頭開始努力。一旦知道了工作的上下文范圍，就可以尋找針對(duì)全部或部分這一上下文的需求規(guī)格說明，將它們作為潛在可復(fù)用需求的來源。采用訓(xùn)練有素的過程來編寫需求規(guī)格說明書有一項(xiàng)好處：得到的需求更容易被將來的項(xiàng)目復(fù)用。

第十六章 溝通需求

編寫需求不是一項(xiàng)單獨(dú)的活動(dòng)，而是在網(wǎng)羅和發(fā)現(xiàn)需求時(shí)完成的。將潛在需求變成書面需求，它必須包含清晰、完整、可測(cè)試的要求，說明必須構(gòu)建什么。將半成形的相反變成準(zhǔn)確的、可溝通的需求表述。項(xiàng)目通常組合使用電子表格、字處理程序、需求管理工具、建模工具以及老式卡片來管理知識(shí)模型中展現(xiàn)的信息。
原子需求的屬性：

有許多不同的自動(dòng)化需求工具，工具清單參見
編寫需求規(guī)格說明不是一項(xiàng)隨意的活動(dòng)，業(yè)務(wù)事件、業(yè)務(wù)用例、產(chǎn)品用例、模板和需求框架使之成為一個(gè)有序的過程，而且它們也隨著度量完成程度，更重要的是，指出哪些地方需要完善。需求知識(shí)管理是管理需求知識(shí)的文檔系統(tǒng)的一種抽象視圖，它為追蹤一部分知識(shí)對(duì)其他知識(shí)的影響提供了基礎(chǔ)。正確地編寫需求是很重要的，一組好的需求能得到數(shù)倍的回報(bào)：構(gòu)建工作更精確，維護(hù)成本更低，完成的產(chǎn)品更準(zhǔn)確地反映了顧客的需要和想法。

第十七章 需求完整性

質(zhì)量關(guān)已測(cè)試并接受了單項(xiàng)的需求，它們被允許進(jìn)入規(guī)格說明，現(xiàn)在需要評(píng)估規(guī)格說明是否完整。這種復(fù)查可以迭代進(jìn)行，最好每次針對(duì)一個(gè)產(chǎn)品用例的需求。復(fù)查的過程是迭代式的，尋找問題或遺漏、修正問題。有一種相當(dāng)有效的規(guī)格說明復(fù)查方式，它是一個(gè)正式的過程，成為審查。審查過程開始時(shí)，由一名協(xié)調(diào)人確定要審查的材料和審查者，審查者收到被審查的文檔的概要，用一天的時(shí)間來研究這些材料，審查會(huì)議利用以前發(fā)現(xiàn)的問題的檢查清單來分析文檔。如果發(fā)現(xiàn)新錯(cuò)誤，就會(huì)更新清單。審查工具是非常有效的工具，確保了需求的正確性和完整性。為了進(jìn)行復(fù)查，不必產(chǎn)生更多的文檔，只要更好地利用已有的信息。復(fù)查過程如下：

排列需求優(yōu)先級(jí)，可以將需求分組，并將它們作為一個(gè)單元來排列優(yōu)先級(jí)。影響優(yōu)先級(jí)的因素：

常見的需求優(yōu)先級(jí)登記是“高”、“中”、“低”等，優(yōu)先級(jí)可以預(yù)防某些沖突的發(fā)生。沖突的產(chǎn)生可能是因?yàn)椴煌睦嫦嚓P(guān)者提出了不同的需求，或者利益相關(guān)者提出的需求與客戶對(duì)需求的想法不一致。這對(duì)于大多數(shù)的需求收集工作來說都是正確的，它表明需要建立某種沖突解決機(jī)制。作為業(yè)務(wù)分析師，要將沖突的需求隔離出來，單獨(dú)與每個(gè)利益相關(guān)者溝通接觸。
規(guī)格說明書用到的所有術(shù)語，都必須在數(shù)字字典部分得到明確定義。如果每個(gè)詞都有達(dá)成共識(shí)的定義，而且一致地使用術(shù)語，那么整個(gè)規(guī)格說明書的意思就是一致的和無二義性的。
風(fēng)險(xiǎn)評(píng)估不是正在的需求，而是項(xiàng)目問題。作為需求分析師，不必獨(dú)自進(jìn)行風(fēng)險(xiǎn)分析，如果組織機(jī)構(gòu)足夠大，員工中應(yīng)該有人接受過風(fēng)險(xiǎn)評(píng)估方面的培訓(xùn)。業(yè)務(wù)分析師在風(fēng)險(xiǎn)評(píng)估中的角色，是考慮需求是否包含某種風(fēng)險(xiǎn)，可能影響項(xiàng)目的成功。
項(xiàng)目驅(qū)動(dòng)
- 項(xiàng)目驅(qū)動(dòng)
- 客戶、顧客和其他利益相關(guān)者
- 產(chǎn)品用戶

項(xiàng)目限制條件
- 強(qiáng)制的限制條件
- 相關(guān)事實(shí)和假定
功能需求
- 工作的范圍
- 業(yè)務(wù)數(shù)據(jù)模型和數(shù)據(jù)字典
- 產(chǎn)品的范圍
度量所需的工作量
復(fù)查是為了評(píng)估需求規(guī)格說明的正確性、完整性和質(zhì)量。復(fù)查才有機(jī)會(huì)測(cè)量構(gòu)建產(chǎn)品的好處、成本和風(fēng)險(xiǎn)，從而評(píng)估是否值得繼續(xù)開發(fā)該產(chǎn)品。

掌握需求過程為分析方面提供了一個(gè)眾人期盼的“前傳”。

頂 0 踩 0

上一篇淘寶技術(shù)這十年

下一篇HTMl標(biāo)簽

我的同類文章

參考知識(shí)庫(kù)

更多資料請(qǐng)參考：

猜你在找

關(guān)閉

查看評(píng)論

* 以上用戶言論只代表其個(gè)人觀點(diǎn)，不代表CSDN網(wǎng)站的觀點(diǎn)或立場(chǎng)

個(gè)人資料

lipeishenshen

訪問：4260次

積分：260

等級(jí)：

積分：260

排名：千里之外

文章搜索

文章分類

需求分析類(3)

產(chǎn)品架構(gòu)師類(1)

技術(shù)發(fā)展總結(jié)(1)

HTML5(12)

CSS3(6)

文章存檔

2016年02月(21)

2016年01月(2)

閱讀排行

CSS發(fā)展史(760)

HTML5元素分類(515)

軟件產(chǎn)品架構(gòu)師手記(433)

HTML5文檔結(jié)構(gòu)(207)

CSS新增特性和CSS選擇器(186)

掌握需求過程(183)

掌握需求過程(170)

淘寶技術(shù)這十年(168)

CSS3用戶界面(155)

掌握需求過程2(148)

評(píng)論排行

軟件產(chǎn)品架構(gòu)師手記(1)

HTML5表單(0)

HTML5元素分類(0)

HTML5文檔結(jié)構(gòu)(0)

HTML5新增功能元素(0)

XHTML(0)

HTMl標(biāo)簽(0)

掌握需求過程(0)

淘寶技術(shù)這十年(0)

掌握需求過程2(0)

推薦文章

* 探索通用可編程數(shù)據(jù)平面

* 這是一份很有誠(chéng)意的 Protocol Buffer 語法詳解

* CSDN日?qǐng)?bào)20170420 ——《開發(fā)和產(chǎn)品之間的恩怨從何來?》

* Android圖片加載框架最全解析——從源碼的角度理解Glide的執(zhí)行流程

* 如果兩個(gè)程序員差不多，選寫作能力更好的那個(gè)

* 從構(gòu)造函數(shù)看線程安全

最新評(píng)論

qingteng826: 學(xué)習(xí)了

  本文關(guān)鍵詞：掌握需求過程，由筆耕文化傳播整理發(fā)布。

本文編號(hào)：329088