- 需求获取
需求开发的核心就是需求的获取，这是一种为软件系统确定各类干系人的需要和约束的过程。
获取是一个综合协作性和分析性的过程，其活动包括收集、发现、提炼和定义需求。获取的目的是为了发现业务需求、用户需求、功能需求和非功能性需求，还有一些其他类型的信息。
请尽量试着理解用户在陈述需求时的思维过程。
要保证每个人都明白系统为什么必须要执行那些特定的功能。
过时、无效的业务过程或规则，都不应该纳入新的系统之中。
业务分析师必须营造一种环境，以便对正在拟定的产品进行彻底、全面的探索。为了使用业务方面的词汇，不能强迫用户理解技术术语。将重要的程序术语编入一个词汇表，不能想当然地认为所有参与方对产品定义的理解都是一致的。
需求开发的目的是使各类项目干系人对需求达成共识。当开发人员了解了这些需求之后，他们就能探索出待解决问题的可选方案。参与需求获取的人要沉得住气，避免在理解问题本质之前就开始设计系统。
我们要强调用户任务而非用户界面，关注真正的用户需求而非口头诉求，避免团队过早陷入设计细节中。
需求获取、分析和规范说明的循环本质
需求获取会议要进行的活动
需求获取技巧
获取技巧包括引导活动（期间与干系人互动以获取需求）和独立活动（期间独立工作以发现信息）。引导活动主要聚焦于发现业务和用户需求。
访谈
要想找出软件系统用户需要，最常见的方法是对他进行提问。访谈是一种传统的需求输入来源。
采用一对一或者小范围讨论而不是更大型的工作坊形式，会使他们感觉更安全（特别是针对敏感主题），更有利于他们分享想法。
>建立融洽的关系
>不脱离范围 在任何获取会议上，都要将讨论聚焦在会议的主题上。
>提前准备好问题和稻草人（某种假设）模型
>提出看法 有创造力的业务分析师不会只是简单地将客户所说的内容记录下来，而是会在获取活动中提出观点和替代选项。
>主动倾听
工作坊
工作坊能鼓励干系人在定义需求时精诚合作。Ellen Gottesdiener（2002）对需求工作坊如此定义：“一种结构性的会议，会议中有经过仔细甄选的干系人群体和内容专家，大家协同定义、创造、精炼并对代表用户需求的交付物（比如模型和文件）达成最终意见。
相比和个体逐一对话，团队工作对于解决分歧更高效。
必工作坊可能是资源密集型的,就必须仔细规划会议。开始前就准备好材料。
获取工作坊所需要的一些技巧，但其中很多技巧也适用于访谈。
>建立和执行基本规则
>为所有团队成员设定角色
>准备会议日程
>坚守范围 参照业务需求，确定大家所提出的用户需求是否符合目前的项目范围。
>将条目放入“停车场”供日后考虑 一些偶然但又很重要的信息：质量属性、业务规则、用户界面构思等。将此类信息放入挂图（停车场），这样既不会丢失信息，还能显示出对提出这些信息的人的尊重。
>时间盒式的讨论 为每个讨论话题分配一个固定的时间段。
>保持团队的小规模但还要吸纳正确的干系人
>使每个人都保持专注
焦点小组
焦点小组就是一组用户代表，他们会参加有人引导的需求获取活动，对产品的功能和质量需求提出建议和看法。
这些成员用过产品的以前版本或者用过与你现在开发产品类似的产品。要么选择同样类型的一群客户（针对不同用户类组织多个焦点小组），要么选择能代表所有用户群的一组人，使其有广泛的代表性。
观察
观察人是很耗时的，因此不适合所有用户或所有任务。
选择重要或高风险任务以及若干个用户类别来观察。
问卷调查
问卷调查是一种针对大群体用户进行调查并了解其需要的方式。
最大的挑战就是问题设计“”
>提供的答案选项要涵盖所有可能的反馈。
>选择答案既要互斥（在数字范围内不重叠），又要穷尽（列举所有可能的选项和/或为未考虑到的地方留出空白以便加以补充）。
>列出的问题不能暗示有“正确”答案。
>如果你使用了比例，则在整个问卷调查中保持其一致性。
>如果想将问卷调查的结果用于统计分析，则使用封闭式问题，要有两个或以上的具体答案。开放式间题允许用户按照自己的意愿来回答，因此很难用它来寻找共性答案。
>在问卷调查的设计和管理方面，可以咨询专家的意见，保证你针对正确的人群提出正确的问题。
>在发放问卷调查之前，一定要进行测试。如果很晚才发现问题措辞模糊或者意识到忽略了重要问题，肯定会非常懊恼。
>对于人们不愿意回答的问题，不要穷追不舍。
系统接口分析
系统接口分析揭示的功能需求涉及系统之间的数据和服务交换（IIBA 2009）。关联图和生态系统图这两种方式通俗易懂，我们可以用来发现接口并进行深入研究。
用户界面分析
用户界面（UI）分析也是一种独立的需求获取技巧，用于研究现有系统，揭示用户和功能需求。
文档分析
文档分析是指检查现有文档，从中发现潜在的软件需求。
制定项目需求获取计划
为干系人设置比较现实的期望。只有在获取资源、日程和交付物方面获得具体的委托，参与者才会专注于本职工作。获取计划包括将用到的技术、使用时间以及使用目的。
计划要包括如下要点：
>目标
>策略和计划采用的技术
>进度和资源估算
>独立获取活动所需要的文件和系统
>获取工作后的预期成果
>获取风险
准备需求获取
引导性获取会议要求有准备活动，这样才能最合理地利用每个人的时间。参与会议的人越多，准备活动就越重要。
>准备会议范围和日程
>准备资源
>了解干系人
>准备问题-在每次引导获取会议上，手头上都要有一组准备好的问题。
作为分析师，必须要对客户提交的需求进行深层次的挖掘，理解其真正需要。
探求未知领域。
与任何一种改进活动一样，对当前情况的不满反而会为未来的创新和改进提供优秀的素材。
>准备稻草人模型-在需求获取会议开始之前，先创建一个稻草人（straw man）或者说草稿、模型。稻草人的作用就是作为一个出发点来帮助了解主题，并激发用户的灵感。
执行获取活动
>教育干系人-将需求获取方法以及选择这种方法的原因告诉干系人。
>做好笔记
>全面利用空间
需求获取后的跟进
整理和分享会议笔记
记录提出的问题
对客户的输入进行分类
不要指望客户能够给出一份简洁、完整并组织良好的需求清单。业务分析师必须对他们听到的各类需求信息单元进行归类整理，进行准确的记录和利用。
无法归入此类的可能有以下几种情形。
>与软件开发无关的项目需求
>假设或依赖项
>历史、上下文设置或者描述性特征方面的其他信息
>不能增加价值的冗余信息
业务需求–如果描述客户或开发组织希望从产品中获得资金、市场或者其他业务利益，则可以归入业务需求
用户需求–对用户目标或者用户需要完成的业务任务之总体陈述就是用户需求，最常见的表达方式为用例、场景或者用户故事。如果用户说“我需要<做什么>”，他可能就是在描述一个用户需求。
业务规则–当客户说只有特定的用户在特定的环境下才能去做某项活动时，他可能是在表达一个业务规则（参见第9章）。
功能需求–功能需求描述的是系统在特定的条件下展示出来的可观察到的行为及系统允许用户采取的行动。
质量属性–对系统如何很好完成某些任务的陈述就是质量属性。
外部接口需求–此类需求描述系统与外部世界的联系。
约束—设计和实现约束是对开发人员可用选项的合理限制。
数据需求–如果客户描述的内容如下：格式、数据类型、允许值或者数据元素的默认值：复杂的业务数据结构的组成：或者是待生成的报告（参见第13章），那他们就是在表达数据需求。
解决思路–很多来自用户的“需求”实际上都是解决思路。如果有人在描述与系统交互使其执行某个动作的一种特定方法，说明他就是在提议解决方案。
如何知道已经完成
完成需求获取时，是没有任何信号的。
出现以下情况时，就说明已经完工。
>用户再也想不出更多用例或用户故事。用户发现的用户需求在重要性上在下降。
>用户提出了新的使用场景，但是这些方案并不能引出新的功能需求。“新”用例实际上可能只是你捕获的用例的替代流程。
>用户重复以前讨论中已经提到的问题。
>建议的新特性、用户需求或者功能需求都在范围之外。
>提议的新需求优先级都很低。
>用户提议的性能可以纳入“产品生命周期中的某个时间”，而不是“我们此刻所讨论的具体产品。”
>检查某一领域需求的开发人员和测试人员提出的问题越来越少。
即使你付出最大努力揭示所有需求也做不到，因此要随着开发的进行做出变更。记住：你的目标是总结大家对需求的共同理解，这些需求要好到足以用来构建下一个版本或者增量开发，并将风险控制在合理的范围之内。
需求获取的注意事项
平衡干系人出席的人数–最佳的平衡方式是吸收一些产品代言人，他们为其各自的用户类别代言，而每个代言人又受同一用户类别其他代表支持。
定义范围要适当
避免需求对抗设计之争–需求获取确实应当将重点放在要做什么上，但在分析和设计之间有一个灰色区域，不能简单用细线来划分（Wiegers 2006）。可以使用假设性的怎么做来分类和改善对用户需求的理解。
合理调查–如果你的项目需要大量调查，就要使用渐进式开发方法来探索需求，将其分为低风险的小块。
假设的需求和隐晦的需求
期望得不到满足有两个可能的原因：假设的需求和隐晦的需求。
>假设的需求是人们期望但又没有明确表述出来的需求。
>隐晦的需求之所以需要，是由于存在另外的需求，但隐晦需求的表述不是很明确。开发人员无法实现自己都不知道的功能。
找出遗漏的需求
需求遗漏是一种常见的需求缺陷。
下面这些技巧可以帮助你发现以前没揭示出来的需求。
>将概要需求进行详细分解，揭示出真正的需要。
>保证所有用户类别都提供了输入。
>追溯系统需求、用户需求、事件相应列表和业务规则至其相应的功能需求，确保全部功能需求都已经提炼出来。
>检查边界值以免遗漏需求。
>表达需求信息的方式不止一种。意到哪些条目有缺失。如果在研究某种模型时觉得两个方框之间应当有一个箭头，那么这个遗漏的箭头就代表一个遗漏的需求。
>用复杂的布尔逻辑（Boolean logic，即AND，OR，NOT）来描述需求集合通常是不完整的。在表达复杂逻辑时，我们可以使用决策表或者决策树涵盖所有可能的条件。
>为项目创建一个常用功能领域检查表。将这个检查表定期与你已经制定的功能进行比较，找出差距。
>数据模型可以揭示遗漏的功能。系统所控制的所有数据实体必须要有对应的功能性，用首字母缩写词CRUD来指代这四种常见的操作。确保能够在程序中找出功能，实际完成这些操作。
- 理解用户需求
最好选择“以用户为中心”和“以使用为中心”的需求获取方法。关注用户及其预期用途有助于展现必备功能，避免实现那些没人使用的特性，帮助确定优先级。
用户需求位于需求的第二个层次，它们位于为项目设定目标的业务需求和描述开发人员必须实现的功能需求之间。
目的是描述用户需要使用系统执行的任务，或是能为一些干系人带来价值成果的“用户.系统”交互。这种方法指引业务分析师获取必要的功能以便实现上述使用场景。
用例和用户故事适合探索业务应用程序、网站、自助终端和用户操作硬件的系统需求。然而，它们不足以充分了解特定类型的应用程序需求。
用例和用户故事也不能充分指明许多嵌入式和实时系统的需要。
用例和用户故事
用例描述一系列系统和外部角色之间的交互，让该角色能够由此获取一些价值。用例名通常使用动宾短语形式。选择强调并且有描述性的名字能够清晰表达出用例为用户交付的价值。
在敏捷开发项目中，用户故事是一个“从迫切需要该功能的人（通常是一个系统的用户或客户）角度出发的一个短小而且简单的描述，”（Cohn2010）。写用户故事通常使用以下模板，不过也有其他的风格：
作为<用户类型>，我想要<一些目标>，以便于<某种原因>。
都聚焦于理解不同类型的用户与软件系统交互的目标。然而，这两种方法从类似的起点出发，朝着不同方向前进。
业务分析师通过用例模板收集用例，结构化这些信息。
通过用例说明，业务分析师可以获得开发人员必须实现的功能需求：测试人员可以确定测试方法来判断用例是否正确实现；开发人员可能在一次发布或迭代实现一个完整的用例。
在早期阶段就思考测试，这对所有项目来说都是一个好主意，不管他们使用什么开发方法。
用例不应该深入设计细节，只要走到用户心中想象的交互就够了。
可以检查用例的每一个元素（前置、后置、流动等）来寻找相关的功能性和非功能性需求并加以测试。
用例方法
用例描述的是系统和某个外部角色之间的一系列交互，这些交互为该角色提供了价值。
>系统内部有事情发生时，谁（或什么）会收到通知？
>谁（或什么）为系统提供信息或服务？
>谁（或什么）帮助系统响应和完成一个任务？
长方形框代表系统边界。箭头从每个角色（柱状图）连接到与之进行交互的用例（椭圆）。从角色到用例的箭头表明该角色是用例的主要角色。主要角色通过发起用例，从中获取主要的价值。一个箭头从用例指向第二个角色，该角色以某种方式参与用例的成功执行。
用例图中的箭头只表明参与的角色和用例之间的联系，并不代表任何形式的流动。
用例和使用场景
用例描述的是一个分散、独立的活动，某个角色可以执行它来实现一些有价值的收益。
场景描述的是系统使用方法。因此，用例是相关使用场景的一个集合，场景是用例的特定实例。
用例的基本要素如下：
>一个惟一的ID和一个简洁的名称（指明用户目标）
>一个简短的文字说明，用来描述用例的意图
>开始执行用例的触发条件
>用例开始需要满足的零个或多个前提条件
>一个或多个后置条件，描述用例成功完成后系统的状态
>一个有编号的步骤列表展示了角色与系统之间的交互顺序，一个从前置条件向后置条件的对话
前置条件和后置条件
前置条件定义系统开始执行用例之前必须满足的先决条件。先决条件可以描述系统的状态，但是他们并不会描述用户的意图。
后置条件描述用例执行成功后系统的状态。
>用户可观察到的内容
>物理产出
>内部系统状态变化
正常流程、可选流程和异常
场景被确定作为用例事件的正常流程。
用例内其他成功的场景称为可选流程或者二级场景。描述了任务中一些不常见或低优先级的变化或它是如何完成的。
相对于用例提供的丰富的描述，用户故事是用户需求的简单声明。
潜在的阻止用例成功执行的条件称为异常。异常描述执行用例期间预期的错误条件及其对应的处理方法。
一些错误条件可能影响多个用例或一个用例正常流程的多个步骤。把这些当作额外的功能需求加以实现，而不是作为所有可能受影响的用例的异常。
不一定要实现每一个用例的可选流程。可以推迟到以后的迭代或发布中。但必须解决阻止流程正常进行的异常。
被忽略的异常通常源自需求的缺失。在需求获取阶段说明异常条件会帮助团队构建健壮的产品。
扩展和包含
可以在用例图中展示两个用例之间的关系类型，分别称为扩展和包含。
用例图可以显示一个独立的用例扩展正常流程到可选流程。
有时，好几个用例都有若干个相同的步骤。为了避免在每一个这样的用例中重复这些步骤，可以定义一个单独的包含相同功能的用例并表明其他用例包括这个从属用例。
前置条件和后置条件要对齐
为了实现这个流程，每一个用例都必须使系统保留一个状态，使得用户能够立即开始下一个用例。一个用例的后置条件必须满足任务序列中下一个用例的前置条件。在一个事务处理应用中，每个用例必须使系统保留允许下一个事务开始的状态。
用例和业务规则
用例和业务规则是交织在一起的。规则可能施加前提条件，使系统在让用户继续进行之前必须先通过测试。
在探索用例时，你也许会发现潜在的业务规则。
识别用例
可以从下面几个方面识别用例：
>首先确定角色，然后制定系统所支持的业务过程，并为角色和系统的交互活动定义用例。
>创建一个特定的场景来说明每个业务过程，然后将这些场景概括为用例，并识别每个用例所涉及的角色。
>使用业务过程描述
>识别系统必须响应的外部事件，然后将这些事件关联到参与活动的角色和特定用例。
>使用CRUD分析来确定需要用例创建、读取、更新、删除或控制的数据实体。
>检查关联图
探索用例
先确定受益于用例的用户，并写下简短描述。估算使用频率提供了一个早期指标，可以从中了解并发使用和容量需求。然后他们开始定义前置条件和后置条件（用例的边界）所有用例步骤都发生在这些边界之内。
询问参与者他们是如何构想与系统交互从而执行任务的。最后得出的一系列角色行动和系统响应就成为用例的正常流程。
在写用例流程中的步骤时，避免使用指向特定用户界面交互的语言。
用例常常涉及不适合放在模板中任何部分的额外信息。
验证用例
从用例创建不依赖于实现和用户特定界面的概念性的测试
早期概念性测试想法比写代码、构建部分系统、执行测试时才发现问题更便宜、更快。它类似于敏捷方法中用验收测试来充实用户故事。
团队使用测试来验证功能需求，找出不能被需求集合“执行”的测试以及不能被测试覆盖的需求。
用例和功能需求
软件开发人员不会实现业务需求和用户需求。他们实现的是功能需求，即具体的系统行为。一些实践者将用例作为功能需求。
为了减少这种不确定性，可以考虑让业务分析师明确指定实现每个用例所需要的功能需求。
这种从用户需求视角到开发人员视角的分析是业务分析师为项目增加的价值之一
下列方法都不完美，所以请选择最适合的方式来记录和管理项目的软件需求。
>只用用例
>只用功能需求
用例要避免的陷阱
注意以下几个陷阱。
>太多的用例–如果遭遇用例激增，说明你很可能没有在合适的抽象层上写。
>高度复杂的用例–要确认是否真的只描述了一个场景。
>内含设计的用例–用例应该聚焦于用户在系统帮助下需要完成的事，而不是屏幕的界面。
>内含数据定义的用例–用例探索容易诱发数据讨论，思考交互过程中哪些数据元素作为输入和输出。在项目范围级别的数据字典和数据模型中存储数据定义。
>用户不明白的用例–从用户的视角写用例，而不是系统的视角，让用户审查用例。
“以使用为中心”的需求有何好处
用例或用户故事可能由于以下几个原因而具有高优先级。
>描述了系统支持的部分核心业务过程。
>许多用户会经常使用它。
>某些受优待的用户类型需要它。
>符合法规要求。
>其他系统功能依赖于它的存在。
用例还有一些技术收益。它们暴露了一些重要的领域对象和彼此的责任。使用面向对象设计方法的开发人员可以将用例变成对象模型，形成类和序列图等。业务过程随着时间推移而变化，特定用户需求中体现的任务也会变。
发表回复