編寫需求文檔，在嵌入式開發(fā)領域是非常普遍的。需求文檔被用來定義開發(fā)任務，協(xié)調大規(guī)模的研發(fā)計劃。對于最終的產(chǎn)品，需求文檔扮演著開發(fā)者行為和消費者行為之間溝通紐帶的角色。當需求文檔書寫正確的時候，便可以發(fā)揮巨大的作用。然而，如果你在嵌入式開發(fā)領域工作的時間足夠長，你就會很快發(fā)現(xiàn)，這個領域里不合格的需求文檔實在是太多了。當你嘗試對這些不合格的文檔進行修復時，你又會很快發(fā)現(xiàn)，書寫正確的需求文檔絕非易事。在這里，我們提出一些建議，希望能將書寫正確需求文檔這件事情變得清晰一些。

10年積累的網(wǎng)站設計、做網(wǎng)站經(jīng)驗，可以快速應對客戶對網(wǎng)站的新想法和需求。提供各種問題對應的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡服務。我雖然不認識你，你也不認識我。但先網(wǎng)站設計后付款的網(wǎng)站建設流程，更有祿勸免費網(wǎng)站建設讓你可以放心的選擇與我們合作。

從較高的層次來看，書寫需求文檔的目的就是要提供對所需行為的有效描述。該所需行為可用一個黑盒系統(tǒng)描述，并需要注意以下細節(jié)：

• 工程師可以根據(jù)系統(tǒng)所說進行實現(xiàn)
• 測試人員，在不與開發(fā)人員溝通的前提下，可以利用滿足硬件要求的設備驗證需求。
• 最終產(chǎn)生的成果滿足終端用戶的要求。

黑盒測試

書寫優(yōu)質的需求文檔：

最基本的原則是：需求文檔應當盡量簡潔，用最易懂的描述來約束系統(tǒng)的預期行為。如果你遵循這個原則，剩下的那些重要因素（可測試性、避免過度設計等等）都將變得順理成章。

列舉一下更詳細的規(guī)則，通常會更有幫助。下面是書寫優(yōu)質需求文檔需要遵循的步驟：

1. 定義系統(tǒng)的邊界。這也是黑盒系統(tǒng)所必要的。

2. 定義輸入和輸出。這也應當是你看待內(nèi)部系統(tǒng)的唯一方式。

3. 用最易懂的方式描述系統(tǒng)的預期行為

4. 除了輸入和輸出之外，你的需求是不是還涉及了系統(tǒng)的其他部分？如果是，那么你的需求就設計過度了。重構需求，讓它變得精簡。

5. 你的需求是不是過于模棱兩可？加入更多的限定規(guī)范。注意：有些模棱兩可的描述并不是壞事，假設描述所包含的所有情況均可被接受，且測試的時候不需要附加的信息加以說明，那么就沒關系。你不需要（也不應該）把系統(tǒng)的行為限制得過頭。

6. 你的需求是否可測試？（這里指的是黑盒測試）如果不是，你最好返回到第4步。如果這種返工發(fā)生很多次，那就說明你的黑盒無法正確描述系統(tǒng)，或者你的測試工具不夠優(yōu)秀。無論是哪種情況，不可測試的需求文檔幾乎就是一文不值的。

7. 你的需求文檔通俗易懂么？如果你的需求文檔非常難以讀懂，那就說明你寫得不好，只能給那些照著你的需求負責實施的人帶來無盡的痛苦。如果是這樣，回到第3步。

8. 你是不是真的做到了第4步？你確認么？再檢查一下。

例子：下面的例子，讓我們描述一個自制的嵌入式設備的需求，這個設備能從彎曲傳感器上讀取彎曲的頻率，并根據(jù)不同的頻率值讓一個LED閃爍。

顯然，我們已經(jīng)完成了步驟2和步驟3了!

• 輸入：從彎曲傳感器讀取數(shù)據(jù)。
• 輸出：LED。

但是我們跳過了步驟1：

• 在這個例子里，我們將把黑盒畫到設備的微處理器上。

讓我們繼續(xù)往下進行,

第四步：除了輸入和輸出以外，我們是否還涉及了其他的系統(tǒng)邊界？

• 微處理器并不關心從彎曲傳感器讀取什么樣的數(shù)據(jù)，從處理器的角度來看，僅需要做的是測量ADC腳的電壓而已。
• LED僅由數(shù)字輸出腳控制。

下面，讓我們來修正這個問題：

第0版本的需求：

1. 該設備應當根據(jù)ADC腳的不同頻率的電壓，來切換數(shù)字輸出端的狀態(tài)。

第五步: 需求寫模棱兩可么?

恩，我們的描述太模棱兩可了.輸出端切換的速度要多快? 跟電壓的關系如何? 輸入電壓的范圍是多少? 讓我們加一些更細節(jié)的描述吧:

版本0.1

1. 輸出端應當由一個自由活動的定時器進行控制

2. 自由運行定時器的頻率最高不得高于每秒10次,不得低于每秒1次.

3. 自由運行定時器的觸發(fā)頻率應當在最高和最低值之間呈線性變化,并與ADC端的輸入電壓成正比.

4. ADC端的輸入電壓應當每100毫秒讀取一次

5. 當ADC端的輸入電壓端被讀入時,控制自由運行定時器周期時間的注冊值也應當被更新.

6. ADC輸入端的電壓有效范圍應當被控制在0到1伏之間.

第六步: 你的需求是可測試的么?

• 首先，自由運行的定時器在這里不需要提及. 因為對它基本上無法進行黑盒測試，它既不是輸入也不是輸出，而且跟這兩者也沒有什么聯(lián)系。
• 讓我們用“數(shù)字輸出端變化的頻率應控制在每秒10次和每秒1次之間”來代替自由運 行定時器的測試標準。
• 對于上述的第四條需求，可能需要一些小修改才能作為測試標準。讓我們用“ADC端的輸入電壓應當保證在每100毫秒內(nèi)至少被讀取一次”來加以描述，這樣的描述能讓我們預期的測試行為顯得更加通俗易懂。
• 需求的第五條也需要一些小修改。我們?nèi)绾尾拍軝z測電壓的輸出范圍是在0到1伏之間呢？ 總不能給個2伏的電壓，然后看看元器件有沒有被燒毀吧？

那么，說“檢驗系統(tǒng)在ADC端輸入電壓為1到2伏之間的時候，工作是否正?！保@樣就檢驗就容易多了。需求描述應當是“正面”的，應當描述設備“應該”的行為，而不是設備“不應該”的行為。否則的話，測試將會無法進行。

版本0.2

1. 數(shù)字輸出端的切換頻率應當控制在每秒10次到每秒1次之間

2. 數(shù)字輸出端的切換頻率應當在最大值和最小值之間呈線性變化，并與ADC端的輸入電壓成正比

3. ADC端的輸入電壓應當保證在每100毫秒內(nèi)至少被讀取一次

4. 檢驗當ADC端的輸入電壓范圍在0到1伏之間的時候，系統(tǒng)工作是否正常

第七步：你的需求是否通俗易懂？

相比于我們原來的描述：“根據(jù)彎曲傳感器的輸出不同頻率來控制LED閃爍”，我們上面的那些需求描述顯得難以閱讀和理解。
我發(fā)現(xiàn)，讓需求文檔變得通俗易懂，最簡單辦法莫過于，把過于細節(jié)的東西抽取出來，然后以條目的形式單獨定義。

版本1

1. 彎曲傳感器應當保證至少在100毫秒內(nèi)讀取一次數(shù)據(jù)（放到注釋單獨列出）

2. 切換LED的狀態(tài)，使其與彎曲傳感器的讀數(shù)保持一致

3. 當彎曲傳感器的讀數(shù)為1伏特時，LED狀態(tài)切換的次數(shù)應當保持在平均一秒十次；當傳感器的讀數(shù)為0伏特時，LED的切換次數(shù)應保持在一秒1次。

定義：

• 彎曲傳感器：輸入電壓位于ADC的X端。安全電壓范圍為0到1伏特（放到注釋單獨列出）
• LED狀態(tài)：數(shù)字狀態(tài)由Y端輸出

這樣就好多了（盡管還不完美）。這些需求通俗易懂，不涉及到系統(tǒng)內(nèi)部實現(xiàn)，且易于測試。對于系統(tǒng)行為的限定也僅僅限于需要做什么，點到為止。（例如，對彎曲傳感器的采樣頻率，在實現(xiàn)上也可以更高，只要不產(chǎn)生非預期行為，一切都可以）。
編寫需求就仿佛是在大腦中構建軟件的過程。因此要重于實作。

英文原文：Job Vranish

原文鏈接：http://blog.jobbole.com/wp-admin/post.php?post=15561

【編輯推薦】

1. XQuery 開發(fā)：一種更好的數(shù)據(jù)庫編程語言
2. 編程語言新生兒到底因何成功 又為何失??？
3. Android應用開發(fā)者抱怨谷歌拖延支付分成
4. 跨平臺開發(fā)：初探AppCan移動開發(fā)框架
5. 給用戶和開發(fā)者最佳的.Net框架部署方案

新聞標題：如何編寫優(yōu)質的需求文檔
網(wǎng)頁路徑：http://uogjgqi.cn/article/cciceii.html