需求分析 实战
需求分析是软件项目过程中间的一个环节,上游活动是确定项目愿景。下游活动是软件开发或者是采购（这一句是个人理解）
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可对扩展性有一定要求，这也是非功能需求。
--------------------------------------------------------------------------------------------
总结与强调
本立道生。软件需求方面的知识和能力可谓软件架构师的“起跑线”，缺了“这一块”就意味着输在起跑线上。
软件架构师面对纷繁复杂的需求，必须对需求分类、需求折衷和需求变更的知识和规律有透彻的了解，从而把握大局、抓住重点，做出最合适的架构设计决策。