描述使用者的某個需求看似一件簡單易做的事情，感覺上只需要指出使用者想要幹什麼，系統能夠提供什麼就可以了，實則不然。
比如，使用者在商品建檔時有如下需求
「使用者可以臨時調整商品的**，其規則是：使用者申請對某個商品臨時調價，並設定臨時**啟用期的起止日期，臨時調價審批通過後，在該臨**啟用期內系統按臨時**開單銷售，有效期結束後，系統恢復臨時調價前的**」
這段話看上去沒有任何問題，讀起來也很自然，事實上，程式設計師拿到這個需求後，他
/她仍然很痛苦，他
/她可能有如下問題不清楚
1、使用者申請對某個商品臨時調價，這裡的「商品」是尚未**的還是已經**的，弄不清楚這個，他
/她沒辦法寫
sql語句
2、設定臨時**啟用期的起止日期，起止日期可能會產生歧意，是否包含「止」的那一天，系統從「起」天
0:00:000
還是9:00:000 am
開始，到「止」天
23:59:59
還是17：59
：59
結束，不同行業、不用使用者都可能有不同的答案
3、臨時調價審批通過後
….，如果審批不通過，系統是刪除這個申請還是保留該申請允許使用者編輯，這要看使用者的使用習慣，有時可能刪除比保留來得更合理些
……….
可能還有其他類似問題，每個人考察問題的角度和解決問題的方式都不盡相同，怎麼盡可能降低這種語義表達的晦澀，比如不完整和二義性是需求定義和表達的重要目標。
在需求定義時，系統詞彙表是必不可少的組成部分。
系統詞彙表是系統（業務）術語的集合，詞彙一般是行業相關專業術語或公司業務詞彙，這些術語的含義用自然語言表達出來，尋求需求人員和使用者對該詞彙有一致的認識並固定下來。
有些系統詞彙本身就是對業務規則的一種表達，這種性質的系統詞彙應給予更多重視。
系統詞彙一旦固定下來，決不能任意修改；除非有不得已的原因，但也要通過評審
傳統的需求表達方式，把使用者的業務需求按業務性質（對映成系統的功能模組，比如採購模組、銷售模組、庫房模組等等）分解成乙個個小的業務特性/功能
(feature/function)
一一間接描述系統要支援的功能（以解決使用者的現時業務問題），以文字直接陳述為主。
比如，下面是乙個描述零售店鋪建檔的簡單需求
系統可由使用者錄入店鋪資料建檔，審批通過的店鋪在系統中啟用；審批未通過的店鋪，使用者可編輯後提交審批或者刪除。
對於已經申請的店鋪資料或審批通過的店鋪資料，系統要提供編輯功能；對於已審批店鋪資料的編輯要重新審批
業務單據資料字段或業務列表顯示字段資訊
【店鋪檔案】欄位有：**、名稱、簡稱、經營性質、位址、**、聯絡人、管理歸屬、店鋪定位、營業面積、協議
其中經營性質欄位的取值由系統定義為扣率或租金，使用者店鋪建檔時選擇其一，可在整個系統內使用
管理歸屬、店鋪定位欄位的取值範圍由使用者自定義，因為不同地區使用者的業務要求及命名方式不一致，僅在地區範圍內使用
協議：當且僅當店經營性質為「扣率」時出現
有兩個明細項
扣率：使用者手工填寫，以％計，比如32％
結算：設定結算日期
,使用者錄入。
這種定義和表達需求的方式形式上比較自由、功能相對離散，用模組將近似需求組織起來。
但是，這種表達不能夠直觀的體現出需求之間的若干關係；在需求發生變更等情況時，如果需求管理沒有借助有效的
rm工具，很難有效跟蹤其產生的連鎖反應（對其他依賴此需求的需求產生的影響）
其描述的系統需求還比較抽象，由於完全依賴於文字載體描述功能，需求人員和使用者也可能對同一種描述產生不同的理解，這種分歧可能導致後來系統部門模組重寫。
作為補充手段，可以結合系統原型或者業務
demo
與使用者溝通以達成一致
用例是基於場景（scenario）的，從這個角度來說，uc直觀的表達出使用者期望的系統功能及使用者與系統的互動細節
關於何如編寫用例，可以參考cockburn寫的《writing effective use cases》一書。
系統分析員通過分析uc，抽取業務領域（domain）並分析其關係可形成最初的系統模型，進而不斷深化衍生出系統架構
rose
ea
需求管理系列之二 軟體需求分析關注什麼？
需求開發沒有做好會出現什麼後果？需求問題的代價？需求分析如何做？為什麼要做？首先來看下需求問題產生的代價模型 一 需求問題的代價 通過圖形可以看出，在需求階段消除問題的代價最小，而如果需求問題等到產品發布出去後才發現的話，那修復的成本就會 n倍的增加。不合格的需求分析 1 沒有足夠的使用者參與 2 ...
《需求管理》系列之一需求捕獲
之所以用捕獲這個詞，而不是獲取 獲得一類詞彙，僅僅是想說明需求不是信手拈來的 它是跳動的 不穩定的，你必須下點功夫才可能有所收穫 主要方式 圓桌會議 最常見 最普通的需求獲取方式，就是需求人員與使用者 代表 坐下來就某個 業務 主題展開培訓或討論，使用者稱述 需求人員提問的方式，這種方式通常能獲得業...
02軟體需求之二
今天是第二次讀軟體需求這本書，經過上次的閱讀，我知道了軟體需求的三個層次，分別是 業務，使用者和功能。在專案中它們在不同的時間來自不同的 也有著不同的目標和物件，並需以不同的方式編寫成文件。業務需求不應包括使用者需求，而所有的功能需求都應該源於使用者需求。同時你也需要獲取非功能需求，如質量屬性。那麼...