需求**、需求收集方法
軟體需求可以來自方方面面，這取決於所開發產品的性質和開發環境。需從不同使用者代表和**收集需求，這說明了需求工程是以相互交流為核心的性質。下面是幾個軟體需求的典型**。
1）. 訪問並與有潛力的使用者**為找出新軟體產品的使用者需求，最直截了當的方法是詢問他們。
2）. 把對目前的或競爭產品的描述寫成文件
文件可以描述一種所必須遵循的標準或產品所必須遵循的**或工業規則。
3）. 系統需求規格說明
乙個包含軟、硬體的產品需要乙個高檔次的系統需求規格說明以介紹整個產品。系統需求的子集被分配到每個軟體子系統中（nelsen 1990） 。附加的詳細軟體功能需求將從有關軟體
的系統需求裡獲得。
4）. 對當前系統的問題報告和增強要求指導使用者和提供技術支援的工作人員是最有價值的需求**。他們收集了使用者在使用現有系統過程中所遇到問題的資訊，還接受了使用者關於系統改進的想法。
5）. 市場調查和使用者問卷調查
調查有助於從廣大有潛力的使用者那裡獲得大量定量的資料，務必調查相關的使用者並詢問一些能產生反響的好問題。
6）. 觀察正在工作的使用者
對當前系統的使用者和將來系統的有潛力的使用者，分析員觀察「日常工作」以獲得經驗，這些經驗能提供很有價值的資訊。分析員可通過觀察使用者與所關聯的任務環境的工作流程來預見使用者在使用當前系統時所遇到的問題，並能分析新的系統可有效支援工作流程的方面（mcgraw and harbison 1997; beyer and holtzblatt 1998） 。比起僅僅簡單地詢問使用者，並記下使用者在處理任務時的步驟來說，直接觀察使用者的工作流程可以對他們的活動有更正確的理解。分析員必須抽象和總結使用者的直接活動，以確保所獲得的需求具有普遍性，而不僅僅代表單個使用者。乙個富有技巧的分析員還可以為改進使用者的當前事務處理過程提出一些見解。
7）. 使用者任務的內容分析
通常通過開發具體的情節（s c e n a r i o）或活動順序（有時稱作「情節」 ） ，可以確定使用者利用系統需要完成的任務，分析員由此可以獲得使用者用於處理任務的必要的功能需求。這是使用例項方法的精髓。
7、需求開發活動指導方針
對於需求開發沒有乙個簡單的、公式化的途徑。下面列出了1 4個步驟，你可以利用它們指導你的需求開發活動。
1）. 定義專案的檢視和範圍
2）. 確定使用者類（比如市場人員、財務人員、生產人員等）
3）. 在每個使用者類中確定適當的代表
4）. 確定需求決策者和他們的決策過程
5）. 選擇你所用的需求獲取技術
6）. 運用需求獲取技術對作為系統一部分的使用例項進行開發並設定優先順序
7）. 從使用者那裡收集質量屬性的資訊和其它非功能需求
8）. 詳細擬訂使用例項使其融合到必要的功能需求中
9）. 評審使用例項的描述和功能需求
10）. 如果有必要，就要開發分析模型用以澄清需求獲取的參與者對需求的理解
11）. 開發並評估使用者介面原型以助想像還未理解的需求
12）. 從使用例項中開發出概念測試用例
13）. 用測試用例來論證使用例項、功能需求、分析模型和原型
閱讀筆記02
第二階段 需求分析階段 在第二個階段重點就是粒度的細化，從主題域我需要細化一層到識別了關鍵業務物件的領域檢視，從業務事件進行流程分析我們需要講業務事件細化一層到具體的業務活動，而業務活動正式我們在識別用例的時候的重要參考。所以在這裡我們基本清楚了第二階段剛開始是通過業務事件進行業務流程分析，業務實體...
閱讀筆記02
第六章 應對大型專案 1 常用的設計與實現方法 1 視覺化軟體過程和使用準則 2 重要的框架 3 積極的分解 4 多平台支援 5 物件導向技術 6 運算子過載 7 庫，元件和程序 8 對於處理的積極使用 2 大多數的大型專案使用乙個複雜的編譯過程，這類過程一般能夠處理配置選項 多種型別的輸入輸出檔案...
2021 9 15 閱讀筆記02
一 今日學習內容 閱讀筆記 這周讀了 人月神話 作者闡述的主要觀點是在軟體開發專案上專案進度和增加人員這兩個概念是不能互換。在之前一直認為，人多做的事情就多，就可以解決很多問題，這個觀點在一些方面可能成立，但是在開發專案方面好像並不是。一 美國20年前軟體專案所面臨的問題，在我們現在依然如此，糟糕的...