TBD或采用漢語拼音略寫DQD）符號作為標準指示器來強調軟件需求規格說明中這些需求的缺陷。通過這種方法，你可以在軟件需求規格說明中查找所要澄清需求的部分。記錄誰將解決哪個問題、怎樣解決及什么時候解決。把每個TBD編號并創建一個TBD列表，這有助于方便地跟蹤每個項目。<BR>&nbsp;&nbsp;&nbsp;&nbsp;在繼續進行構造需求集合之前，必須解決所有的TBD問題，因為任何遺留下來的不確定問題將會增加出錯的風險和需求返工。當開發人員遇到一個TBD問題或其它模糊之處時，他可能不會返回到原始需求來解決問題。多半開發者對它進行猜測，但并不總是正確的。如果有TBD問題尚未解決，而你又要繼續進行開發工作，那么盡可能推遲實現這些需求，或者解決這些需求的開放式問題，把產品的這部分設計得易于更改。<BR>&nbsp;&nbsp;&nbsp;&nbsp;編寫優秀的需求文檔沒有現成固定的方法，最好是根據經驗進行。從過去所遇到的問題中可使你受益匪淺。許多需求文檔可以通過使用有效的技術編寫風格和使用用戶術語而不是計算機專業術語的方式得以改進。<BR>你在編寫優秀的需求文檔時，希望讀者還需牢記以下幾點建議：<BR>&nbsp;&nbsp;&nbsp;&nbsp;   
            保持語句和段落的簡短。<BR>&nbsp;&nbsp;&nbsp;&nbsp;   
            采用主動語態的表達方式。<BR>&nbsp;&nbsp;&nbsp;&nbsp;   
            編寫具有正確的語法、拼寫和標點的完整句子。<BR>&nbsp;&nbsp;&nbsp;&nbsp;   
            使用的術語與詞匯表中所定義的應該一致。<BR>&nbsp;&nbsp;&nbsp;&nbsp;   
            需求陳述應該具有一致的樣式，例如“系統必須..”或者“用戶必須..”，并緊跟一個行為動作和可觀察的結果。例如，“倉庫管理子系統必須顯示一張所請求的倉庫中有存貨的庫存清單。”<BR>&nbsp;&nbsp;&nbsp;&nbsp;   
            為了減少不確定性，必須避免模糊的、主觀的術語，例如，用戶友好、簡單、有效、、最新技術、優越的、可接受的等。當用客說“用戶友好”或者“快”時，你應該明確它們的真正含義并且在需求中闡明用戶的意圖。<BR>&nbsp;&nbsp;&nbsp;&nbsp;   
            避免使用比較性的詞匯，定量地說明所需要提高的程度或者說清一些參數可接受的最大值和最小值。當客戶說明系統應該“處理”、“支持”或“管理”某些事情時，你應該能理解客戶的意圖。由于需求的編寫是層次化的，因此，可以把頂層不明確的需求向低層詳細分解，直到消除不明確性為止。<BR>&nbsp;&nbsp;&nbsp;&nbsp;   
            文檔的編寫人員不應該把多個需求集中在一個冗長的敘述段落中。在需求中諸如“和”，“或”之類的連詞就表明了該部分集中了多個需求。務必記住，不要在需求說明中使用“和/或”，“等等”之類的連詞。<BR>
            <CENTER><B>8．需求分析的過程</B></CENTER>&nbsp;&nbsp;&nbsp;&nbsp;需求獲取是在問題及其最終解決方案之間架設橋梁的第一步。獲取需求的一個必不可少的結果是對項目中描述的客戶需求的普遍理解。一旦理解了需求，分析者、開發者和客戶就能探索出描述這些需求的多種解決方案。參與需求獲取者只有在他們理解了問題之后才能開始設計系統，否則，對需求定義的任何改進，設計上都必須大量的返工。把需求獲取集中在用戶任務上—而不是集中在用戶接口上—有助于防止開發組由于草率處理設計問題而造成的失誤。<BR>&nbsp;&nbsp;&nbsp;&nbsp;需求獲取、分析、編寫需求規格說明和驗證并不遵循線性的順序，這些活動是相互隔開、增量和反復的。當你和客戶合作時，你就將會問一些問題，并且取得他們所提供的信息（需求獲取）。同時，你將處理這些信息以理解它們，并把它們分成不同的類別，還要把客戶需求同可能的軟件需求相聯系。然后，你可以使客戶信息結構化，并編寫成文檔和示意圖。下一步，就可以讓客戶代表評審文檔并糾正存在的錯誤。這四個過程貫穿著需求開發的整個階段。<BR>&nbsp;&nbsp;&nbsp;&nbsp;由于軟件開發項目和組織文化的不同，對于需求開發沒有一個簡單的、公式化的途徑。下面列出了1   
            4個步驟，你可以利用它們指導你的需求開發活動。對于需求的任何子集，一旦你完成了第十三步，那么你就可以很有信心地繼續進行系統的每一部分的設計、構造，因為你將開發出一個好的產品:<BR>&nbsp;&nbsp;&nbsp;&nbsp;1.   
            定義項目的視圖和范圍。<BR>&nbsp;&nbsp;&nbsp;&nbsp;2.   
            確定用戶類。<BR>&nbsp;&nbsp;&nbsp;&nbsp;3.   
            在每個用戶類中確定適當的代表。<BR>&nbsp;&nbsp;&nbsp;&nbsp;4.   
            確定需求決策者和他們的決策過程。<BR>&nbsp;&nbsp;&nbsp;&nbsp;5.   
            選擇你所用的需求獲取技術。<BR>&nbsp;&nbsp;&nbsp;&nbsp;6.   
            運用需求獲取技術對作為系統一部分的使用實例進行開發并設置優先級。<BR>&nbsp;&nbsp;&nbsp;&nbsp;7.   
            從用戶那里收集質量屬性的信息和其它非功能需求。<BR>&nbsp;&nbsp;&nbsp;&nbsp;8.   
            詳細擬訂使用實例使其融合到必要的功能需求中。<BR>&nbsp;&nbsp;&nbsp;&nbsp;9.   
            評審使用實例的描述和功能需求。<BR>&nbsp;&nbsp;&nbsp;&nbsp;10.   
            如果有必要，就要開發分析模型用以澄清需求獲取的參與者對需求的理解。<BR>&nbsp;&nbsp;&nbsp;&nbsp;11.   
            開發并評估用戶界面原型以助想像還未理解的需求。<BR>&nbsp;&nbsp;&nbsp;&nbsp;12.   
            從使用實例中開發出概念測試用例。<BR>&nbsp;&nbsp;&nbsp;&nbsp;13.   
            用測試用例來論證使用實例、功能需求、分析模型和原型。<BR>&nbsp;&nbsp;&nbsp;&nbsp;14.   
            在繼續進行設計和構造系統每一部分之前，重復6~1   
            3步。<BR>需求獲取可能是軟件開發中最困難、最關鍵、最易出錯及最需要交流的方面。需求獲取只有通過有效的客戶—開發者的合作才能成功。分析者必須建立一個對問題進行徹底探討的環境，而這些問題與產品有關。為了方便清晰地進行交流，就要列出重要的小組，而不是假想所有的參與者都持有相同的看法。對需求問題的全面考察需要一種技術，利用這種技術不但考慮了問題的功能需求方面，還可討論項目的非功能需求。確定用戶已經理解：對于某些功能的討論并不意味著即將在產品中實現它。對于想到的需求必須集中處理并設定優先級，以避免一個不能帶來任何益處的無限大的項目。<BR>&nbsp;&nbsp;&nbsp;&nbsp;需求獲取是一個需要高度合作的活動，而并不是客戶所說的需求的簡單拷貝。作為一個分析者，你必須透過客戶所提出的表面需求理解他們的真正需求。詢問一個可擴充的問題有助于你更好地理解用戶目前的業務過程并且知道新系統如何幫助或改進他們的工作。<BR>需求獲取利用了所有可用的信息來源，這些信息描述了問題域或在軟件解決方案中合理的特性。一個研究表明：比起不成功的項目，一個成功的項目在開發者和客戶之間采用了更多的交流方式。與單個客戶或潛在的用戶組一起座談，對于業務軟件包或信息管理系統（MIS）的應用來說是一種傳統的需求來源。<BR>&nbsp;&nbsp;&nbsp;&nbsp;在每一次座談討論之后，記下所討論的條目，并請參與討論的用戶評論并更正。及早并經常進行座談討論是需求獲取成功的一個關鍵途徑，因為只有提供需求的人才能確定是否真正獲取需求。進行深入收集和分析以消除任何沖突或不一致性。盡量理解用戶用于表述他們需求的思維過程。充分研究用戶執行任務時作出決策的過程，并提取出潛在的邏輯關系。流程圖和決策樹是描述這些邏輯決策途徑的好方法。<BR>&nbsp;&nbsp;&nbsp;&nbsp;當進行需求獲取時，應避免受不成熟的細節的影響。在對切合的客戶任務取得共識之前，用戶能很容易地在一個報表或對話框中列出每一項的精確設計。如果這些細節都作為需求記錄下來，他們會給隨后的設計過程帶來不必要的限制。你可能要周期性地檢查需求獲取，以確保用戶參與者將注意力集中在與今天所討論的話題適合的抽象層上。向他們保證在開發過程中，將會詳盡闡述他們的需求。<BR>&nbsp;&nbsp;&nbsp;&nbsp;在一個逐次詳細描述過程中，重復地詳述需求，以確定用戶目標和任務，并作為使用實例。然后，把任務描述成功能需求，這些功能需求可以使用戶完成其任務，也可以把它們描述成非功能需求，這些非功能需求描述了系統的限制和用戶對質量的期望。雖然最初的屏幕構思有助于描述你對需求的理解，但是你必須細化用戶界面設計。<BR><FONT 
            color=red>作者小傳：</FONT><BR><FONT 
            color=blue>&nbsp;&nbsp;&nbsp;&nbsp;曹偉，南京易點網絡軟件公司技術總監。從ERP的系統開發，對整體系統有較強的認識欲望，現正在實施企業級軟件系統構架，實施一個國際化企業電子化的解決方案。</FONT></TD></TR></TBODY></TABLE></TD>
    <TD class=hui vAlign=top width=195>
      <SCRIPT language=JavaScript 
      src="需求工程——如何進行軟件需求分析.files/ListJS.htm"></SCRIPT>
    </TD></TR>
  <TR>
    <TD class=hui14 align=middle colSpan=3><IFRAME id=Opinion name=id=Opinion 
      marginWidth=0 marginHeight=0 
      src="需求工程——如何進行軟件需求分析.files/ArticleOpinion.htm" frameBorder=0 width="98%" 
      height=400>
	</IFRAME>
    </TD></TR></TBODY></TABLE></BODY></HTML>