第4章 需求定义最佳实践（2）
需求定义的产物
- POS类，对于项目型的软件开发工作，通常会在立项结束时编写一份，立项报告，最典型的格式包括POS、项目可行性报告、项目章程等。
|
内容 |
说明 |
|
目标 |
对业务目标的简短、可度量的描述 |
|
相关人员和用户 |
说明那些人和系统有利益关系；谁将操作系统，能力如何 |
|
限制条件 |
必须采用某设计方案？时间？经费如何 |
|
关键术语 |
该项目使用那些术语 |
|
相关事实与假定 |
项目是在什么背景下提出来的，对技术能力做了什么假设 |
|
工作范围 |
系统将设计那些内容 |
|
费用计划 |
需要花费多少工作量或资金 |
|
风险 |
面临的主要风险 |
|
可行性 |
包括技术、经济、社会可行性的论证 |
- Vision类，对于一些生命周期相对较长、应用面相对较广的项目或产品而言，则会在POS的基础上添加一些相关的内容。
需求定义的要素
- 目标，目标对于一个项目而言，其重要性不言而喻。一个好的目标描述应该满足SMART原则：必须是具体的；必须是可以度量的；必须是可以达到的；必须和其他目标具有相关性；必须具有明确的截止期限。
- 范围，需求分析人员在进行需求定义工作时，核心的工作就是确定范围。
- 相关人员与用户，在进行需求定义时，需要对和软件相关的人进行研究。
- 相关事实与假定，相关事实是可能对产品产生影响的外部因素，具体来说，就是要罗列出对产品产生影响的其他因素、系统和活动，以便提醒开发可能对需求产生影响的一些情况和事实。
案例说明：
- 什么是主题域
- 为什么使用构件图
a) 系统/主题域都不是孤立存在的，他们之间总是会有这样那样的协作，因为我们需要提前将这些协作标识出来，这就是主题域之间的服务接口。
b) 构件图解析，在图中标识出不同主题域以及他们之间的服务接口，显然最合适的建模工具就是UML中的构架图
c) 标识服务接口的要点，在考虑和标志服务接口时，最有参考价值的思想是“职责却动设计”。
d) 其他，划分主题域是可以根据自己的需要进行多级嵌套，也就是每个主题域还可以在分成几个更小的主题域。
确定主题域范围
- 上下文关系图绘制要点
l 首先用一个矩形表示系统，写上系统的名称，将整个系统看作一个黑盒子；
l 然后找到该系统的所有customer（客户），考虑海这些customer会发起什么时间，这些时间会引发worker（内部工作人员）的什么工作，将这些序列逐一表示出来；
l 最后在看看系统的每个worker还有没有一些主动发起的事件。
- 标识业务事件与报表，当上下关系图绘制出来之后，整个主题域的范围也就框定出来了，但是他还不足以为后续的需求捕获、分析与建模活动提供良好的基础。
业务事件解析，是树立业务系统需求的一个很重要的线索
i. 业务事件类型，外部事件和内部事件
ii. 业务事件标识要点，寻找主动触发的源头
- 生成需求大纲
小结：
需求定义工作的重点在于明确项目的目标和范围，是后续需求工作的基础。解决了目标问题之后，另一个重点是界定范围，然后可以用业务事件列表和报表列表作为线索，展开进一步的需求捕获、需求分析与建模工作。
戒语：
l 需求阶段描述的时用户的能力特点，旨在特高可用性。
l 你可以不做一件事，但一定不能不知道为什么需要做这件事。
l 在分解系统是，应该按照业务的脉络来划分成不同的主题域
l 各个主题域之间的服务接口是需求变更的防火墙
l 确保能做的事和知道的事相匹配是职责却动设计的要点
l 绘制上下文关系图，先考虑customer在考虑worker是要点
l 业务事件应该是主动出发的，并且将会产生一系列后续行为
l 业务事件是直接作用于系统的，也就是将处罚系统行为。