工作流程明细：理解涉众需要
系统分析员和关键涉众通过访谈、专题讨论会、示意板、业务流程用例和其他手段，确定更多的涉众，获取他们的请求，确定关键需要和特性。这些会话由一个或多个系统分析员主持进行。需求专题讨论会是最有用的需求获取手段。该流程包括用户、帮助台人员、企业主、测试员以及其他对提议项目的结果有利害关系的个人。涉众请求通常是不明确、重叠甚至是离谱的。除正式的获得结果外，涉众请求还可以用格式设计很好的文档、数据库的缺陷和扩展请求或者电子邮件和群件线程等形式表达。系统分析员记录已确定的关键涉众需要，对其进行分类和区分优先次序。
理解涉众需要：“取悦客户”从何处开始
涉众请求要尽可能在请求涉众使用的语言和格式中获取。与后继的需求类型(通常由具有丰富流程知识和技术的项目团队成员创造)不同，涉众请求通常很难表达清楚。涉众请求经常交叉或重复。而且涉众请求的表达形式多种多样，从纸条到扩展请求数据库等等都有。
分析员(或代表分析员角色的团队)必须复审所有需求，对其进行解释、分类，甚至还要重新录入(不重写)，在前景文档中将其翻译成关键涉众需要及系统特性。根据开发的严格程度以及工具的可用性，可应用一部分或所有涉众请求、需要与特性之间的可追踪性，帮助涉众理解在决定系统需求时如何解释清楚他们的请求和需要。
通过应用理解涉众需要工作流程，说明获取请求和满足涉众需要的非常重要事项，对建立涉众对开发团队能力的信心而言具有重大意义。
对涉众需要有了更好的理解之后，开发团队里的系统分析员改进前景文档，将主要精力放在制定“产品定位说明”上。该说明用简洁的两三句话确立项目的显著价值。说明应包括预期用户、项目解决的问题、所带来的利益，以及它所取代的竞争者。所有的团队成员都应该理解该项目的主题。系统分析员还更新词汇表，促进团队对术语的共同理解。
从多方面向关键涉众咨询，以便对从理解涉众需要得到的新特性的优先级进行协商，获得对当前开发新特性所需资源和工作量的理解。利用问题分析，在该工作流程中管理依赖关系有助于管理项目的规模。它还建立起涉众请求、需要与系统特性之间的可追踪性，让涉众相信他们的建议确实得到考虑。
工作流程明细：定义系统
最初的两个需求工作流程明细(分析问题和理解涉众需要)创建了关键系统定义的早期迭代(包括前景文档指定的特性)、用例模型的第一个大纲，以及初始需求属性。下一个工作流程明细即定义系统，通过改进特性定义，添加新主角、用例和补充规约，完善了高级系统需求说明。
图 12 - 定义系统
工作流程明细：定义系统
更新词汇表是为了反映当前对术语的理解，这些术语用于描述在用例模型及补充规约中捕获的特性和需求。
系统分析员使用在改进的前景文档中定义的特性集来派生用例并以说明，这些用例详细阐述用户对系统预期行为的观点。用例模型作为客户、用户和系统开发人员之间的合同，规定了所选特性如何在系统中发挥作用。它有助于系统开发人员设置符合现实的期望和目标，帮助客户和用户验证系统是否达到了这些期望。
一些系统需求没有很好地符合用例。系统分析员就在补充规约里说明这些需求。许多非功能性需求，如可用性、可靠性、性能、可支持性等，都放在补充规约中。应该注意，这些类型的许多非功能性需求专门针对单个用例。用例阐释者最好将这些需求放在用例规约本身(请参见改进系统工作流程)，在补充规约里描述系统范围的非功能性需求。
在该工作流程明细中，系统分析员创建和设置了补充需求的属性(如优先级和相关用例)。除此之外，系统分析员还为初始用例和新用例添加并更新属性值。
最后，系统分析员通过追踪重要用户需要和关键特性到相关用例以及补充规约说明的需求，以此来管理依赖关系。
文章来源于领测软件测试网 https://www.ltesting.net/
