产品需求管理

产品需求管理版本历史在产品开发之前形成明确的产品需求描述，并在产品开发过程中对产品需求进行严格管理，是产品成功的关键所在。产品需求，可分为功能性需求和非功能性需求：功能性需求：是一种行为需求，指那些需要具体完成某项内容的产品功能；非功能性需求：是指那些为满足用户需要而必须具有、但又不是功能性需求的产品特性，或者称为质量（Quality），包括性能、效率、安全性、易用性等多方面；产品的功能性需求与非功能性需求，其描述方式可以不同，但是要使用同样的管控方法、同样的管控质量标准。功能性需求描述描述用户需求的方法有很多，针对用户的功能性需求，我们建议使用“特征（Features）+用例（UseCases）”的组合来描述。这种描述方法的主要优点有：基于“特征+用例”的用户产品需求描述，逻辑结构强，颗粒度可控，能让产品需求更明晰、定义更规范；用“特征+用例”的形式描述用户产品需求，将为产品开发过程的跟踪管理打好基础——产品过程的每次迭代都可制定一个量化目标、过程中随时可给出完成度；增加新用户需求是通过增加新特征/新用例或者修改已有特征／用例来实现的，便于变更管理，能更好地实现版本管控。1.1特征与用例分别是什么？所谓“特征+用例”的描述方法，是指在描述用户需求时使用两种对指在描述产品需求时使用两种对象，一个是特征（Feature），另一个是用例（UseCase）。特征（Feature）是指系统围绕某个对象发生的功能，用<动作><结果><by|for|of|to><对象>来表达。特征（Feature）描述的是产品的功能性需求，必须是通过某种动作、产生某种结果。特征功能是用户提出的切实有效的功能，从用户角度看，一个特征必须对应着一个有价值的结果。用例（UseCase）是系统在作业时与用户交换信息的一个个场景。用例是站在用户角度上描述系统功能的，强调用户的目标。在整理清楚产品需求后，我们首先把产品的用户需求分解为若干个特征（Feature），要求这些特征合在一起能完整地表达该产品的用户需求。然后我们通过用例（UseCase）来详细描述这些产品特征（Feature）。于是，特征（Feature）与用例（UseCase）的关系构成了一个需求描述的树状体系。特征（Feature）是树状体系中的高等级对象，用例（UseCase）是这个体系中的低等级对象。在这个体系里，用例是需求描述的基本单元。在这个树状体系中，每个用例（UseCase）都必然隶属于某一个特征（Feature）。特征（Feature）可以通过BreakDown的方式进行逐级分解和细化，形成特征之间的隶属关系；同样的，用例（UseCase）也可以进行BreakDown，从而形成更加详细的描述。特征（Feature）和用例（UseCase）的粒度大小，既要取决于业务分析的精细度，也要考虑开发实现的周期（开发计划将以特征和用例作为任务颗粒）。1.2“特征+用例”的描述格式在“特征+描述”的描述方法中，特征（Feature）本身并不需要细致的描述，因为隶属于它的用例（UseCase）可以详细地说明该特征（Feature）的所有内容要素。所以，针对特征（Feature）的直接描述是非常简要的，描述的重点是要表达出它和用例（UseCase）之间的隶属关系。而用例（UseCases）是需求描述的基本单元，所以用例的描述内容中包含较多的细节。特征（Feature）和用例（UseCase）是通过两种表格来分别描述的，如下页中的表1、表2。如果特征和用例具有各自的BreakDown结构，可以对表1的结构进行扩展。无论是特征还是用例的描述内容中，无法也不应该包含太多的实现细节。它们本身无法展示很多界面交互的内容，因此，要想完整表达产品需求，还应该包括界面和交互建模的内容，这就是上表中两个“附加描述文件”列存在的意义。附加描述文件可以是任何类型的文件内容，其作用都是用来针对特征（Feature）或用例（UseCases）的内容进行补充说明，以期更明确、更细致地描述产品需求。表1：特征描述表（FeaturesList）Feature名称Feature编号附加描述文件所含用例的名称用例编号附加描述文件特征的名称01……(ifexist)用例的名称01.01……(ifexist)……01.02…………01.03…………n…………n.m……表2：用例描述表（UseCasesList）用例编号：n.m优先级：[√]必须[]应当[]可以[]希望状态：[]建议[√]采纳[]待定[]驳回创建：日期/人名修改：日期/人名目标版本：在哪个产品版本中实现用例名称：……操作者：用户群中的某一种角色前提条件：前提条件应该是系统能够检测和验证的业务流程：操作者和系统交互的业务过程，用3~9个步骤来描述，明确交互动作和触发机制实现结果：业务完成后达到的结果异常处理：异常情况的处理过程补充说明：可能用到的业务规则等附加说明2.非功能性需求描述2.1非功能性需求的分类为了让非功能性需求的描述更加系统和易于管理，把这类需求进行分类汇总是一个可取的做法。非功能性需求的分类标准可以有很多种，但我们建议划分为以下几类：观感需求：描述针对产品外观/界面的期望，规定了产品外观/界面想要达到的目标。它与详细的界面设计是有区别的，它体现的是用户感觉。易用性需求：描述产品符合用户习惯的能力，或者描述用户的使用期望。它影响用户使用产品时的生产率、错误率以及用户对新产品的接受程度。执行需求：执行需求是指产品在给定的时间或特定的精确度来执行某些任务，或者在一段时间内的极端状态值。在考虑执行需求时，可以从完成任务的速度、结果的精确度、容量、允许值的范围、单位时间内完成的任务数、资源的使用效率、两次故障间的平均无故障时间、连续不停机时间等方面入手。它还应该包括对风险的控制内容。环境需求：主要描述产品使用的环境。分为软件环境和硬件环境方面内容。还应包括使用产品时必须要提供的合作软件的内容。可维护性需求：主要描述产品安装/升级的方便性、产品出现故障或者用户错误操作后的可恢复性、用户使用过程中遇到错误能否快速定位等方面的能力。安全性需求：指产品消除潜在风险的能力和对风险的承受能力，包含保密性、可靠性和完整性三个子特性。保密性指的是数据不能被授权用户以外的任何人访问的能力。可靠性指的是授权用户可以不受阻止的访问数据、与其它软件的兼容的能力和产品的强壮度。完整性指的是安预期目标完成任务的能力。文化和政策需求：这是一类特殊的需求，由于人的习惯、宗教、语言、禁忌或偏见，可能会导致产品不被接收。2.2非功能性需求的描述方式非功能性需求往往面临着难以描述、难以量化的问题。但是，产品的所有需求都应该是可测量、可验证的，否则，需求就不属于有效需求、没有存在的意义。所以，对于非功能性需求，还是要尽可能地设置数据标准，从而将其量化为有效需求。非功能性需求还有一个特点，就是不同的非功能性需求，其作用覆盖范围可能有差别。有的功能性需求是针对整个产品的，有的可能针对某一项或某几项功能性需求（特征->用例）。我们使用两种表格来描述非功能性需求。表3：非功能性需求索引表组别名称组编号需求名称需求编号类别作用到的Features界面友好度01快速从界面识别出品牌01.01观感01/02界面加载时间尽量短01.02执行02表4：非功能性需求描述表需求编号需求验收标准01.0160％的用户在第一次看见该产品的5秒内，就会识别出产品所属公司01.02在95％的情况下，一般时段响应时间不超过1.5秒，高峰时段不超过4秒…………3.产品需求的分析与表述3.1产品需求的形成通过市场调研、用户调查、会议、观摩同类产品等手段，获取到尽可能多的与目标产品相关的需求，并从这些需求材料中整理出涉众需求（StakeholderRequests）。注意！用户告诉你的，通常是他转化后的解决方案，而不是原始需求；注意收集用户群中不同角色的各自价值和关注点；分析需求时，应遵循“定性->场景->定量”的路线；必要的时候，整理目标产品所涉及到的专业术语和词汇，形成需求说明的词汇表，作为需求描述的基础；分析需求的过程总是伴随着建立领域模型的过程。建立领域模型是需求分析的方法，也是提炼和总结需求的基础。使用业务流程图（或UML活动图）、UML类图和UML用例图来表达领域模型。还可以增加使用数据流图（DFD）。针对领域模型中的业务对象，进行对象属性的整理归纳，形成描述文字作为UML类图的辅助内容。表达领域模型的各种图形及辅助文字内容，应作为需求描述的辅助文件。分析需求的过程也会伴随着对人机交互的分析，主要围绕系统操作界面的要求和交互模式的要求。使用界面模拟图来表达操作界面的要求，必要时辅以交互方式的演示。界面模拟图应作为需求描述的辅助文件。通过需求分析，确定出目标产品的特性，描述产品的前景，整理出产品的特征（Feature），并标定每个特征的优先级。通过Features描述的产品需求，应该覆盖用户的大部分业务；标定优先级时，应从离主营业务的远近、发生频率的高低两个方面来度量。用户想要和真正需要是有区别的，没有识别好优先级，可能导致需求过度；对领域建模过程输出的用例和需求分析整理出的“特征”进行功能关系分析，把各个用例指定为某个“特征”的实现成员，形成“特征”和用例之间的隶属关系，从而构建出树型的需求体系。为每个用例编写详细的规约内容，描述每个用例的过程，描述每个用例的业务规则以及对人机交互的要求。从原始的涉众需求（StakeholderRequests）中，识别出质量、效率、性能等方面的非功能性需求，归纳整理成产品的非功能性需求列表。基于以上工作结果，形成一系列产品需求描述文档，并把产品需求分配到产品版本规划上。3.2产品需求的描述载体需求分析过程会形成两类需求描述载体：1）图形领域模型的表达：业务流程图或UML活动图、UML类图、UML用例图，数据流图人机交互要求的表达：界面模拟图及交互演示2）文字功能需求列表：“特征”集、用例（操作流程、业务逻辑）非功能需求列表：质量／性能／效率等方面要求的表述与验证方法业务对象属性集：配合UML类图要求把功能需求列表和质量需求列表合并为一个doc文档，作为产品需求的主描述文档，形成产品需求规格说明文档。而其它文件则以辅助描述文档的方式，作为主文档的内容补充。任何一个需求描述文件，必须含有版本历史记录表，版本初创及以后的每次内容修订，均应在记录表中予以登记。每次登记内容，要包含日期、操作人、内容变化概要等3项内容。4.需求描述文档的变更管理4.1版本控制是基础针对产品需求进行管理的核心活动包括三个方面：定义需求基线——针对某一产品版本，形成意见一致的需求描述；审查需求变更请求，评估其影响，核准或驳回；以可控的方式把核准的变更融入开发工作，保持开发计划与需求的同步；这些需求管理的活动又可以分为四种类型的工作：变更控制——提出申请、分析影响、做出决策、修改需求文档、修改开发计划、评估需求的稳定性；版本控制——定义需求版本标识机制、确定需求文档的版本；需求状态跟踪——定义可能的需求状态、记录每个需求的状态、报告所有需求的状态分布；需求跟踪——定义到其它需求的联系链、定义到其它系统元素的联系链；从这些工作内容可以看出，针对需求描述的版本控制是需求管理活动的基础之一。良好的需求文档版本管理，可以避免需求过时或需求不一致而浪费开发资源。4.2根据需求变更的类型修改文档为了便于记录产品需求的变化，我们概括地把产品需求变更划分为以下几种情况：增加／删除业务对象（BO）：增加／删除业务对象时领域模型会发生变化，通常会导致用例的增加、删除或修改。修改业务对象：改变业务对象的属性集、改变业务对象之间的关系。改变业务对象通常会引起用例的变化。新增／删除用例修改用例：改变用例的操作流程、改变用例中的系统响应、改变用例使用的业务规则等增加／删除质量要求修改质量要求增加／删除软件界面修改软件界面：改变软件界面的布局与内容、改变交互模式。针对以上不同类型的需求变更，应分别修改相应的需求描述载体。对于用例的变化和质量要求的变化，要相应地修订产品需求规格说明文档。对于涉及业务对象变化的，要相应地修改领域模型的相关文件（业务流程图、UML图、业务对象属性集等）。涉及界面和交互方式变化的，要相应地修改界面与交互模拟。4.3产品需求文档的版本变化标识方法为了简单方便地实现针对需求的版本管理，我们把产品需求的版本控制分为两个级别：微小变更导致的需求文档版本要发生变化时，我们使用文件内标识：我们要求需求描述文档的主文件必须是Word文件，这样可以使用修订功能来标识记录版本变化；其它不支持修订痕迹的辅助描述文件，则需要在文件内容中添加修改说明。较大变更导致的需求文档版本要发生变化时，我们使用文件外标识：从原来的需求文档复制出新文件夹或者新文件，通过文件夹或文件的重新命名来标识版本变化（新文件夹以版本号来命名）。采用Word文件的修订功能来标识需求版本变化时，如果需求变更积累太多，可能会导致Word文件的可读性大大降低，此种情况下，可以为Word文档保存一个小的基线版本，然后合并所有修订内容形成一个新的版本控制起点。5.需求变更的控制方式从建立需求基线后的第一刻起，用户需求变化就会接踵而至，比如要求新增功能、要求改变功能等。在产品测试、产品演示、用户试用／正式使用等过程中，用户需求变化都会随时产生。用户需求变化可能是通过某次活动（比如讨论会、演示等）集中收集到的，更可能是平时零星反馈来的。无论是通过什么方式获得，这些信息必须得到真实有效的记录，而且能够及时反馈给产品负责人或项目负责人。用户需求变化的记录格式不做具体要求（建议以禅道项目管理软件的新建任务作为记录方式），但所有记录必须描述清晰准确。收集并记录下来的用户需求变化，应该周期性地进行处理。所谓周期性，可以是每月、每周甚至每天，处理周期长短取决于产品处于生命周期的什么阶段。某些用户需求变化可能需要立即处理，比如：需求变化使得当前的设计开发方案变得不合理，需求变化是用户急需实现的，等等。因此，周期性处理过程中应照顾到紧急情况。处理用户需求变化的过程，就是评估、初审、修改需求描述文档、评审的过程，就是需求变更控制的过程。5.1需求变更的级别需求变更的可以粗略分为大小两个级别。大级别的需求变更通常包括以下几种变更类型：领域模型发生变化，比如业务流程有所改变、业务对象增加／减少／发生属性变化，用户角色增加／减少等。领域模型的变化往往引起其它几种的需求变更情况的发生。增加或者减少功能特征（Feature）与用例（UseCase）。增加新的质量要求，或者删除已有的质量要求。增加或减少操作界面，或者人机交互方式发生重大变化。小级别的需求变更通常包括以下几种变更类型：用例内部发生变化（比如过程改变、系统响应方式改变、业务规则改变等）。提高或降低已有的质量要求。界面的内容布局改变、人机交互方式有所改变。5.2需求变更的评估与初审所谓分析评估，就是对每个用户需求变化进行细化描述，需求分析人员评估它对产品的价值、可行性以及它属于哪种变更类型，评估结果必须形成内容清晰的描述文档。形成评估结果后，召集“需求变更初审会议”。初审会议的输入，是用户需求变化评估结果的文档。初审会议的目标，是经过讨论，确定出哪些用户需求变化将纳入产品需