捕获需求：从构想到需求.md
为什么捕获需求很困难
开发人员通常是为用户而不是为自己构造软件。而用户常常不知道需求是什么，或者不知道如何以一种精确的方式描述需求。
解决问题的传统方式是指派一名分析人员从每个用户哪里获得需求清单，并将其整理成完整、正确、一致的需求规格说明。如果相信人类的头脑可以以“系统必须...”的形式给出上千页需求清单、而又能做到相对一致的话，那就太不切实际了。而且，这些需求规格说明也很难转变为设计和实现规格说明。
即使有分析人员的帮助，用户也不完全理解软件系统到底应该实现什么功能，他们知道系统基本完成时才知道自己的需求。
更重要的是系统要支持任务，因为系统是为执行任务而构造的，系统应该为应用它的业务和客户提供价值。通常，很难确定或理解这种价值到底是什么，又是也不可能使系统确保这种价值。更糟的是，由于世界是不断变化的，这种令人难以著名的价值再整个项目的过程中很可能也会改变。
即使明白了这些，捕获需求仍旧相当困难。
需求工作流的目的
需求工作流的主要目的是致力于开发正确的系统。要做到这一点，就要足够详细地描述系统需求，使客户和开发人员再系统应该做什么、不应该做什么方面达成共识。
这样做的一个最大的挑战是，我们驾驶客户不是计算机专家，但必须读懂并理解需求捕获工作的到的结果。为了迎接这种挑战，我们必须用客户语言来描述这些结果。
需求捕获概述
每个软件项目都是唯一的。同样，捕获需求的起始点也有所不同。起始点可能是一个模糊的景象描述，也可能是一个详细的需求规格说明；如此大的差异要求分析人员的需求捕获方法能适应不同的情况。
经过起始点不同，但再大多数情况下一些确定的步骤都是剋选哪个的，这就允许我们建立原型工作流。步骤如下：
- 列举出候选需求，在系统的生命周期中，客户、用户、分析人员和开发人员都会提出很多好的想法，把它们作为一系列的候选需求，有可能在将来的系统版本中选择实现它们。每个特征有一个简短的名字和简要的解释或定义，这些信息对于产品规划期间讨论该特征已经足够了。每个特征都有一系列规划值：
- 状态
- 估计实现成本
- 优先级
- 在实现特征时的风险关联级别。
- 理解系统语境，为了正确的捕获需求和正确的建立系统，关键开发人员-特别是构架师和一些高级分析人员-需要牢固把我系统所处的语境。至少有两种方法表达系统所处的语境：
- 领域模型，把语境中的重要概念描述为领域对象，并将这些对象彼此连接起来。
- 业务模型，目的是描述过程-存在的或可以察觉到的-以便于了解它们。
- 捕获功能性需求，确定系统需求的简明方法是基于用况。这些用况既捕获功能性需求，也捕获非功能性需求。每个用况表示一种使用系统的方法。捕获系统确实需要的用况，要求我们能透彻理解用户和客户的需求。为了做到这一点，需要理解系统的语境，与用户讨论各种建议等。
- 捕获非功能性需求，非功能性需求确定了系统的性质，有的非功能性需求只与某一个用况有关，并且应该与这个用况联系起来。有些非功能性需求非常通用，应该将它们归入到补充需求列表中单独处理。
需求再软件生命周期中的作用
- 初始阶段，分析人员确定了大部分用况，以限定系统和项目的范围，并详细说明最重要的用况（少于10%）。
- 细化阶段，分析人员捕获大多数剩余的需求，以便开发人员能够估计所需要的开发工作量，目标时捕获大约80%的需求，并在细化阶段结束时描述大部分用况（注意，此时只能将这些需求的大于5%~10%时限为构架基线）。
- 构造阶段，捕获其余的需求。
- 移交阶段，基本上不在捕获任何需求，除非需求发生了变化。
运用领域模型来理解系统的语境
什么是领域模型？
领域模型能捕获系统语境中最重要的对象类型。领域对象代表系统工作的环境中存在的“事情”或发生的事情。有三种典型的形式：
- 业务对象，表示业务中可操作的东西。
- 系统需要处理的现实世界中的对象和概念。
- 将要发生或已经发生的事件。
UML图（尤其是类图）描述了领域类型。这些图向客户、用户、评审人员和其他开发人员阐明领域类，以及它们之间是如何通过关联彼此相关的。
建立领域模型
领域模型通常是在讨论会上由领域分析人员完成的，他们用UML和其他建模语言把结果文档化。讨论会上应该包括领域专家、还应有以建模见长的其他人员。
领域建模的目的是理解和描述在领域语境中最重要的类。规模适度的领域模型通常需要10~50个类。规模更大的领域可能需要更多的类。
由分析人员为该领域所选取的几百个候选类将作为术语表中的定义保存下来。
术语表和领域模型有助于用户、客户、开发人员和其他项目相关人员使用统一的词汇。
很容易首先对系统的内部建模而不考虑其语境。领域模型应该有助于理解系统在其语境中解决的问题。
领域模型的使用
在确定用况和分析模型时要用到领域类和术语表：
- 描述用况和设计用户界面时。
- 分析期间，提出索要开发的胸痛的内部类。
使用业务模型来理解系统的语境
业务模型时理解一个组织中业务过程的技术。如果所使用的系统与我们中大多数人所关系的业务无关怎么办呢？在这些情况下，我们可能还会微软着将要开发的软件系统建立一个系统模型这个系统时嵌入式软件系统的“业务模型”。它参与了需要简要概括的叫高层的系统用况。目的时确定软件用况和软件所支持的相关业务实体，所以只需建立模型来理解系统语境就行了。这项活动的结果时根据对有关“业务系统”功能的理解而导出的领域模型。
由两种类型的UML模型支持业务建模：用况模型和对象模型。
什么是业务模型
业务用况模型时分别从与业务过程和客户对应的业务用况和业务参与者的角度来描述公司的业务过程。
业务对象模型时业务的内部模型。它描述了如何由一组工作人员使用一些业务实体和工作单元来实现每个业务用况。每个业务用况的实现可以用交互图和流程图来表示。
业务实体代表如账单这样的事务，工作人员可以在业务用况中访问、检查、处理、产生或使用它。一个工作单元时一个实体集合，它对最终用户来说是一个可认知的整体。
业务实体和工作单元用于表示同一类型的领域类概念。
每个工作人员、业务实体和工作单元可能会参与多个业务用况的实现。
如何建立业务模型
业务模型分两部来建立：
- 业务模型建模人员应该建立一个业务用况模型，用于确定业务的参与者和参与者使用的业务用况。这个业务用况模型使歼灭战能更好地理解业务向其参与者提供的价值。
- 建模者应该建立一个业务对象模型，其中包括工作人员、业务实体和工作单元，三者集合在一起共同实现业务用况。业务规则和施加于业务上的其他条例于这些不同的对象相关联。
业务建模和领域建模的区别：
- 领域建模方法中的类可以跟踪到领域专家的经验。业务建模方法中的每个模型元素可以跟踪到客户的需求。
- 领域类具有属性，但通常没有或仅有少量操作。业务视图不同。
- 在业务建模中确定的工作人员，将走位到处所构造的信息系统的第一批参与者和用况集合的起点。这就允许我们在信息系统中经由工作人员和业务用况来跟踪每个用况，并返回到业务的客户。
根据业务模型确定用况
分析人员使用业务模型作为输入，运用一种系统的技术来建立一个暂时的用况模型。
首先，分析人员把每个将称为信息系统用户的工作人员和业务参与者确定为一个参与者。
每个将称为信息系统用户的工作人员都需要获得系统支持。这种支持需求使通过遍历所有工作人员来确定的。
一旦确定了所有的工作人员或业务参与者所充当的角色后，便可以为信息系统的系统参与者确定用况。
分析人员还必须决定有多少工作人员或业务参与者的任务应该由信息系统自动完成，并重新整理这些用况以便更好地适应参与者的需要。
补充需求
补充需求使指步需任何特定的用况相关联的非功能性需求，每个这样的需求可能会影响到几个用况或根本不影响任何一个用况。补充需求可以被捕获作为传统的需求规格说明中陈述的需求。
- 性能需求。
- 接口需求详细描述了系统必须与之交互的外部项目的接口。
- 物理需求详细i奥数了系统必须具有的物理特性。
- 设计约束时对系统设计进行限制，如可扩展性和可维护性约束，或有关重用一六系统或其中的主要部分的约束。
- 实现约束时对系统的编码或构造进行说明或限制。
- 其他需求，如法律方面的需求和规章制度方面的需求。