編寫需求文件，在嵌入式開發領域是非常普遍的。需求文件被用來定義開發任務，協調大規模的研發計畫。對於最終的產品，需求文件扮演著開發者行為和消費者行為之間溝通紐帶的角色。
當需求文件書寫正確的時候，便可以發揮巨大的作用。然而，如果你在嵌入式開發領域工作的時間足夠長，你就會很快發現，這個領域裡不合格的需求文件實在是太多了。當你嘗試對這些不合格的文件進行修復時，你又會很快發現，書寫正確的需求文件絕非易事。
在這裡，我們提出一些建議，希望能將書寫正確需求文件這件事情變得清晰一些。
從較高的層次來看，書寫需求文件的目的就是要提供對所需行為的有效描述。該所需行為可用乙個黑盒系統描述，並需要注意以下細節：
工程師可以根據系統所說進行實現
測試人員，在不與開發人員溝通的前提下，可以利用滿足硬體要求的裝置驗證需求。
最終產生的成果滿足終端使用者的要求。
黑盒測試
書寫優質的需求文件：
最基本的原則是：需求文件應當盡量簡潔，用最易懂的描述來約束系統的預期行為。如果你遵循這個原則，剩下的那些重要因素（可測試性、避免過度設計等等）都將變得順理成章。
列舉一下更詳細的規則，通常會更有幫助。下面是書寫優質需求文件需要遵循的步驟：
1. 定義系統的邊界。這也是黑盒系統所必要的。
2. 定義輸入和輸出。這也應當是你看待內部系統的唯一方式。
3. 用最易懂的方式描述系統的預期行為
4. 除了輸入和輸出之外，你的需求是不是還涉及了系統的其他部分？如果是，那麼你的需求就設計過度了。重構需求，讓它變得精簡。
5. 你的需求是不是過於模稜兩可？加入更多的限定規範。
注意：有些模稜兩可的描述並不是壞事，假設描述所包含的所有情況均可被接受，且測試的時候不需要附加的資訊加以說明，那麼就沒關係。你不需要（也不應該）把系統的行為限制得過頭。
6. 你的需求是否可測試？（這裡指的是黑盒測試）如果不是，你最好返回到第 4 步。
如果這種返工發生很多次，那就說明你的黑盒無法正確描述系統，或者你的測試工具不夠優秀。無論是哪種情況，不可測試的需求文件幾乎就是一文不值的。
7. 你的需求文件通俗易懂麼？如果你的需求文件非常難以讀懂，那就說明你寫得不好，只能給那些照著你的需求負責實施的人帶來無盡的痛苦。如果是這樣，回到第 3 步。
8. 你是不是真的做到了第 4 步？你確認麼？再檢查一下。
例子：下面的例子，讓我們描述乙個自製的嵌入式裝置的需求，這個裝置能從彎曲感測器上讀取彎曲的頻率，並根據不同的頻率值讓乙個 led 閃爍。
顯然，我們已經完成了步驟 2 和步驟 3 了!
· 輸入：從彎曲感測器讀取資料。
· 輸出：led。
但是我們跳過了步驟1：
· 在這個例子裡，我們將把黑盒畫到裝置的微處理器上。
讓我們繼續往下進行,
第四步：除了輸入和輸出以外，我們是否還涉及了其他的系統邊界？
· 微處理器並不關心從彎曲感測器讀取什麼樣的資料，從處理器的角度來看，僅需要做的是測量 adc 腳的電壓而已。
· led 僅由數字輸出腳控制。
下面，讓我們來修正這個問題：
第 0 版本的需求：
1. 該裝置應當根據 adc 腳的不同頻率的電壓，來切換數字輸出端的狀態。
第五步: 需求寫模稜兩可麼?
恩，我們的描述太模稜兩可了.輸出端切換的速度要多快? 跟電壓的關係如何? 輸入電壓的範圍是多少? 讓我們加一些更細節的描述吧:
版本0.1
1. 輸出端應當由乙個自由活動的定時器進行控制
2. 自由執行定時器的頻率最高不得高於每秒 10 次，不得低於每秒 1 次.
3. 自由執行定時器的觸發頻率應當在最高和最低值之間呈線性變化，並與 adc 端的輸入電壓成正比.
4. adc 端的輸入電壓應當每 100 毫秒讀取一次
5. 當 adc 端的輸入電壓端被讀入時，控制自由執行定時器週期時間的註冊值也應當被更新.
6. adc 輸入端的電壓有效範圍應當被控制在 0 到 1 伏之間.
第六步: 你的需求是可測試的麼?
· 首先，自由執行的定時器在這裡不需要提及. 因為對它基本上無法進行黑盒測試，它既不是輸入也不是輸出，而且跟這兩者也沒有什麼聯絡。
讓我們用「數字輸出端變化的頻率應控制在每秒 10 次和每秒 1 次之間」來代替自由執行定時器的測試標準。
· 對於上述的第四條需求，可能需要一些小修改才能作為測試標準。讓我們用「adc 端的輸入電壓應當保證在每 100 毫秒內至少被讀取一次」來加以描述，這樣的描述能讓我們預期的測試行為顯得更加通俗易懂。
· 需求的第五條也需要一些小修改。我們如何才能檢測電壓的輸出範圍是在 0 到 1 伏之間呢？ 總不能給個 2 伏的電壓，然後看看元器件有沒有被燒毀吧？
那麼，說「檢驗系統在 adc 端輸入電壓為 1 到 2 伏之間的時候，工作是否正常」，這樣就檢驗就容易多了。需求描述應當是「正面」的，應當描述裝置「應該」的行為，而不是裝置「不應該」的行為。否則的話，測試將會無法進行。
版本0.2
1. 數字輸出端的切換頻率應當控制在每秒 10 次到每秒 1 次之間
2. 數字輸出端的切換頻率應當在最大值和最小值之間呈線性變化，並與 adc 端的輸入電壓成正比
3. adc 端的輸入電壓應當保證在每 100 毫秒內至少被讀取一次
4. 檢驗當 adc 端的輸入電壓範圍在 0 到 1 伏之間的時候，系統工作是否正常
第七步：你的需求是否通俗易懂？
相比於我們原來的描述：「根據彎曲感測器的輸出不同頻率來控制 led 閃爍」，我們上面的那些需求描述顯得難以閱讀和理解。
我發現，讓需求文件變得通俗易懂，最簡單辦法莫過於，把過於細節的東西抽取出來，然後以條目的形式單獨定義。
版本11. 彎曲感測器應當保證至少在 100 毫秒內讀取一次資料（放到注釋單獨列出）
2. 切換 led 的狀態，使其與彎曲感測器的讀數保持一致
3. 當彎曲感測器的讀數為 1 伏特時，led 狀態切換的次數應當保持在平均一秒十次；當感測器的讀數為 0 伏特時，led 的切換次數應保持在一秒 1 次。
定義：· 彎曲感測器：輸入電壓位於 adc 的x端。安全電壓範圍為 0 到 1 伏特（放到注釋單獨列出）
· led 狀態：數字狀態由y端輸出
這樣就好多了（儘管還不完美）。這些需求通俗易懂，不涉及到系統內部實現，且易於測試。對於系統行為的限定也僅僅限於需要做什麼，點到為止。
（例如，對彎曲感測器的取樣頻率，在實現上也可以更高，只要不產生非預期行為，一切都可以）。
編寫需求就彷彿是在大腦中構建軟體的過程。因此要重於實作。
需求分析編寫規範
專案名稱 需求分析說明書 版本 1.0 注 用方括號括起來並以藍色斜體 樣式 infoblue 顯示的文字，它們用於向作者提供指導，在發布此文件之前應該將其刪除。按此樣式輸入的段落將被自動設定為普通樣式 樣式 body text 本文中 專案名稱 公司名稱 為自動更新字段。更新操作步驟如下 開啟選單...
國家優質工程匯報材料的編寫
建築工程類 一 國家優質工程質量匯報內容 1 工程概況 2 工程特點及施工難點 3 新技術開發 推廣應用 4 工程質量管理 5 工程質量情況 6 質量亮點 7 獲獎情況 8 工程的社會影響 9 工程綜合評價 一 工程概況的編寫要求 工程概況中應說明以下內容 工程名稱 工程的全稱 工程有關各方 建設 ...
如何編寫教案
教師要上好課，必須做好課堂教學準備，即備好課。教學好比演戲，而備課過程如同編寫劇本 排劇 舞台設計等準備演出的過程。教師擔任著編劇 導演 主演 劇務等全部工作。可見，備課既是一項艱苦的腦力勞動，又是一門創造性的藝術。教師通過大量的備課活動，所要達到的直接目的，就是制定出比較完善的課時授課計畫，即教案...