《需求工程—軟件建模與分析》閱讀筆記一

     軟件經歷了以「機器」爲中心，以「應用」爲中心，以「企業」爲中心的發展過程，隨着「應用」爲中心的軟件發展，原來的個體化「軟件做坊式」的軟件開發模式顯示出了不少的問題，針對這些問題，人們在不斷地討論與制定對策，在軟件開發技術和軟件開發過程與管理方面都取得了不少進步。

     根據不少方面的調查顯示，在全部的軟件開發項目中，項目成功的概率是很小很小的。形成這些軟件問題的一個很重要的緣由是：未能很好地理解和掌握應用型軟件的模擬特徵以及由此而產生的一系列影響和要求。

 

      軟件能夠分爲：面向專業用戶的純工具型軟件、面向普通用戶的純工具型軟件和應用型軟件。不一樣種類的軟件的評判標準是不同的，面對不一樣的用戶他們有不一樣標準。這就要求軟件需求的全面性。產生需求問題的最大緣由是應用型軟件的模擬特徵理解不透徹或應用不堅定。一樣，非技術性和社會性因素重視不足、傳統需求分析的方法的缺陷也會帶來需求問題。需求工程必須說明軟件系統將被應用環境及其目標，必須將目標、功能和約束反映到軟件系統中，映射爲可行的軟件行爲，並對軟件行爲進行準確的規格說明，須要妥善處理目標、功能和約束隨時間的演化狀況。

 

     需求工程分爲需求開發、需求管理，需求開發分爲需求獲取、需求分析、需求規格說明、需求驗證。

 

    【IEEE1998】將需求分爲功能需求、性能需求、質量屬性、對外接口、約束5類，即兩大類功能需求和非功能需求。

 

     功能需求中按抽象層次的高低分爲業務需求、用戶需求、系統需求。業務需求是系統的目標，用戶需求是系統的任務，系統需求是系統的行爲。

 

對於非功能需求，咱們很難在系統完成以前清晰地看到，不少時候是在系統完成以後纔會發現非功能需求。在解決系統成功或失敗的因素中，非功能需求與功能需求同等重要，甚至更重要。

 

      一個優秀的需求是完整的，每一個需求都完整的描述出系統所須要的功能，並將用戶的指望傳遞給了開發人員，能夠在系統及運行環境的已知條件和約束下實現，任何一個需求都是不能忽視的、無歧義的、能夠驗證的。

 

     需求工程的一些工做須要不少的活動細節，經過實踐的方法來完成這些活動細節，不一樣的需求階段都有其標誌性的活動，都有各自的實踐方法。

 

     需求獲取中會遇到不少的困難，例如：用戶與開發人員的背景、立場不一樣，交流存在困難；用戶缺少歸納性、綜合性的表述能力；用戶存在認知困難；開發者爲用戶創造需求，用戶爲開發者提出解決方案；用戶很差選擇，用戶不肯參與等等，這都要採起措施去面對、解決，有一個好的需求獲取流圖。

 

     項目開始的時候要確立項目的目標，咱們要有一個共同的認識，明確的分析出問題，發現業務需求，制定一個解決方案找到系統特徵，這一點在寫系統時有了不少的感觸，面對一個系統，不知道應該有什麼樣的內容，不瞭解用戶，不知道用戶會用它幹什麼，用戶須要什麼，單從本身的理解去創建系統的功能，不少時候都有一種寫文章的感受，不知道下面該有什麼，下文是什麼？一個功能，加也不是，不加也不是。這時候真的很須要用戶的需求。

 

     面談是需求獲取的方法之一，他能夠得到不少的內容：事實和問題、被會見者的觀點、被會見着的感覺、組織和我的目標。可是訪談者要注意不少問題：禮貌的傾聽，選擇好的時間和地點，筆錄，在用戶贊成的條件下錄音或錄像。

 

     原型的介質有不少：紙面、幻燈動畫、快速語言和工具和程序代碼。紙質原型的真實感最低但其可以緩解原型方法的高成本缺點。當用戶需求出現了模糊、不清晰、不完整等具備必定不肯定性的特徵時，就能夠考慮使用原型方法。[Houde1997]認真原型的需求內容有：外觀、角色、實現。

 

     觀察能夠幫助理解複雜的協同事件，獲取工做中的異常處理，獲取與用戶認知不一致的實際知識，瞭解用戶的認知，獲取默認的知識。