本文是溫昱先生著《軟體架構設計》中的乙個小節.感覺很好.所以手打出來,供各位賞讀.
需求分析是軟體專案過程中間的乙個環節,上游活動是確定專案願景。下游活動是軟體開發或者是採購（這一句是個人理解）
10.4 pm tool 實戰：需求分析
10.4.1 上游活動: 確定專案願景
乙個專案要被開發、要拔款立項，一定有它的的業務目標。作為《願景文件》內容的一部分，業務目標占有非常重要的地位。即使是敏捷軟體開發，也很重視以業務目標列表等形式來明確建立某軟體的最終目的。
從組織的角度而言，之所以要開發並使用pm tool作為專案管理工具，是要達到以下業務目標：通過幫助專案經理更好地控制專案、更有效地分配資源，幫助專案成員之間更順暢地協作，從而提高專案的投入產出比。
要開發的pm tool的業務目標列表
* 幫助專案經理更好地控制專案
* 幫助專案經理更有效地分配資源
* 幫助專案成員之間更順暢地協作
10.4.2 第1步：從業務目標到特性列表
業務目標是組織或客戶方的高層對未來系統的期望，最終要落實到使用這套系統的人（終端使用者）實際操作中所需的功能 - 這些功能被稱為「使用者需求」。如果從業務目標向使用者需求直接過渡的話，我們會發現中間的「跨度」過大，所以可以借助特性列表技術作為中間的「跳板」。
特性（feature）在實踐中其實有兩種用法：
* 有時，我們把它看作高度概括的功能性需求，它的數量將比具體的使用者需求的數量要少乙個數量組。它的作用是支援從業務目標到使用者需求的過渡思維：「為了達到期望的業務目標，未來系統應在大方向上具有哪些方面的特性，每個特性再有一組功能來支撐...」
* 另外一些實踐者把特性當作比「功能更小的需求單位」，特性驅動開發（feature driven development,fdd）方法也持這種觀點；
第2步：從特性列表到用例圖
所謂使用者需求，就是使用者希望軟體系統能為他做什麼，用例技術是捕獲和記錄使用者需求的合適技術，它是以使用者為中心的，用例名是使用者需求最直觀、最簡便的反映。
從用例圖中很清楚地看到，pm tool的主要使用者分為兩種角色，專案成員和專案經理。有些功能是只有專案經理才能使用的，在用例圖中通過「包」的方式給予清晰說明，當然，用例圖輔以用例簡述技術對每個用例的功能進行簡要說明效果很好，在些未列出。
第3步：從用例圖到用例規約
用例圖並不足夠。換句話說，需求分析進行到使用者需求的層次並不足夠，因為如果不明確定義軟體系統的行為需求，我們就不知道要開發什麼。基於用例技術的需求實踐中， 此時應和使用者一起編寫用例規約。
用例：新增專案任務
1、用例名稱
新增專案任務
2、簡要說明
通過此功能，專案經理可以為專案新增任務
3、事件流：
3.1 基本事件流
1) 專案經理進入「新增專案任務」介面。
2) 系統自動顯示已經存在的「專案列表」。
3) 專案經理選定具體專案，並輸入任務的名稱、任務目標、開始日期、結束日期等基本資訊。
4) 專案經理確定建立此任務。
5) 系統完成專案任務的建立。
3.2 擴充套件事件流
如果該任務的開展必須在特定任務完成之後進行，則專案經理可選擇乙個或多個任務作為「前置任務」
4、非功能需求：
操作必須方便直觀
5、前置條件
身份驗證：登入使用者必須是專案經理身份
6、後置條件
任務被成功新增到專案，或因任務所在專案還未被建立而退出。
7、擴充套件點
無8、優先順序
高。需求驗證與需求啟發
在需求分析過程中需要不斷地和客戶進行交流，這時客戶非常希望能夠看到給他帶來實感的介面圖甚至可執行的系統原型。而開發方最擔心的問題是客戶需求的不斷變化，所以他們也希望能夠盡早掌握客戶的真正需求，並希望需求成果得到客戶的確認。
為此，我們可以在需求分析期間就開始介面設計，並將介面草圖等設計成果用於和客戶的交流當中，這樣可以增加實感、方便交流，並幫助客戶「發現」他真正想要的功能。當然，介面設計的成果並不應放入《需求文件》，因為他們是設計而不是需求。
舉個例子。在一開始和客戶討論「新增專案任務」這項需求時，他們未必能意識到兩個需求細節：
* 他們希望為每項任務指定優先順序，這樣有利於承擔多項任務的專案成員在時間不夠時權衡取捨；
* 出於易用性的極高要求，他們要求確定任務細節的時機必須非常靈活.
後來，在介面圖和可執行原型的幫助下，使用者很容易地意識到了「令人不滿的地方到底在哪兒」，明確提出上面二個細節，開發方也更新了「新增專案任務」的介面原型。如下圖，使用者只輸入任務名稱和所屬專案就建立任務，也可以同時指定許多詳細資訊。
最終成果：《軟體需求規格說明書》
需求分析工作的最終成果是《軟體需求規格說明書》。
非功能需求的滿足程度對軟體專案的成功非常關鍵，因此，《軟體需求規格說明書》必須系統地描述非功能需求的具體要求。非功能需求大致分為質量屬性和約束兩 大類。質量屬性是軟體系統的整體質量品質----所謂整體品質，就是它往往和大多數功能有關，而不是僅僅表現在某個功能「內部」。至於約束性需求，它們是 架構設計中必須遵循的限制，並有可能「衍生」出質量屬性需求和功能需求。
一部分非功能需求來自使用者。諸如效能、易用性等軟體質量屬性，雖然不像功能需求那樣直接幫助使用者達到特定目標，但並不意味著軟體質量不是必需的，恰恰相 反，質量屬性差的軟體系統大多都不會成功。還有一部分非功能需求來自開發者和公升級維護人員。軟體的可擴充套件性、可重用性、可移植性、易理解性和易測試性先進 非功能需求，都屬於「軟體開發期質量屬性」之列，它們都將影響開發和維護成本。也有一部分非功能需求來自客戶組織。架構師必須充分考慮客戶對上線時間的要 求，預算限制，以及整合需要等非功能需求，還要特別關注客戶所在領域的業務規則和業務限制。
例如，如果pm tool很難使用，那反而增加了專案組的工作負擔，不利於提高效率，因此，pm tool必須有較高的易用性，再例如，pm tool可對擴充套件性有一定要求，這也是非功能需求。
總結與強調
本立道生。軟體需求方面的知識和能力可謂軟體架構師的「起跑線」，缺了「這一塊」就意味著輸在起跑線上。
軟體架構師面對紛繁複雜的需求，必須對需求分類、需求折衷和需求變更的知識和規律有透徹的了解，從而把握大局、抓住重點，做出最合適的架構設計決策。
架構設計 需求分析 實戰
本文是溫昱先生著 軟體架構設計 中的乙個小節.感覺很好.所以手打出來,供各位賞讀.需求分析是軟體專案過程中間的乙個環節,上游活動是確定專案願景。下游活動是軟體開發或者是採購 這一句是個人理解 10.4 pm tool 實戰 需求分析 10.4.1 上游活動 確定專案願景 乙個專案要被開發 要拔款立項...
架構實戰 軟體架構設計的過程
幾年前，我們 peter eeles和peter cripps 開始注意到grady booch首創的 軟體架構手冊 handbook of software architecture www.handbookofsoftwarearchitecture.com grady起初的目的是 整理許多有趣...
對話 關於架構 設計與需求
2007年10月22日 10 12 00 wwe wwe 我這幾年的大部分工作也是偏重架構設計 aim 有什麼感想呢？wwe 個人覺得架構設計就像生活中的一部分 aim en.這個怎麼講？wwe 架構設計就像規劃你的生活一樣，都想把它變好 變美 aim 但是，你也應該知道。會有很多人 很多因素讓生活...