php网站分类目录源码,李时珍现货交易平台,淮安网站建设公司电话,制作企业网站要花多少钱在传统的瀑布开发模式中#xff0c;开发人员通常在初始阶段就确定需求并将之“冻结”#xff0c;以便在不受需求变更影响的情况下进行开发。然而#xff0c;实际经验告诉我们#xff0c;这种方法在多数情况下并不适用#xff0c;更为有效的方法是先建立需求基线#xff0…在传统的瀑布开发模式中开发人员通常在初始阶段就确定需求并将之“冻结”以便在不受需求变更影响的情况下进行开发。然而实际经验告诉我们这种方法在多数情况下并不适用更为有效的方法是先建立需求基线然后进行基线变更管理。
一、什么是需求基线?
需求基线是一个时间快照代表的是已经讨论过、批准过并且承诺会在特定产品发布中实现的一系列需求共同认同。
这个“发布”可能是一个完全交付的产品或者是该产品的任何中间开发阶段。当利益相关者对需求“签字确认”时他们实际上在做的就是同意并承诺一个特定的需求基线无论他们是否以这种方式思考。
一旦项目团队建立了需求基线团队应当遵循一个务实的变更控制流程以对新增的功能需求和修改或删除现有需求进行合理的商业和技术决策。
变更控制流程并不是为了压制变化而是为了提供信息给决策者使他们能够及时、适当地做出决定修改计划的功能。这个计划的功能就是基线。
通常情况下基线会被赋予一个唯一的名称这样所有的项目参与者都可以明确无误地引用它。良好的配置管理实践可以让团队准确地重构任何之前的基线及其所有的组件。
二、实施需求基线
范围定义是为了区分项目中包含和不包含的部分而需求基线则明确标识出项目将实施的需求规范。基线不是一个实物而是一份定义清楚的物品清单。一种可能的存储位置是软件需求规范SRS文档。
如果SRS文档只包含并且全面覆盖了特定产品发布的所有需求那么这个SRS就构成了该发布的需求基线。然而SRS文档可能还会包含一些额外的优先级较低的需求这些需求是为了之后的发布准备的。
反之一个大项目可能需要多个软件、硬件和接口需求规范以完全定义基线的组成部分。目标是提供清晰的信息让项目的利益相关者了解即将发布的内容到底是什么。
也许你是在一个需求管理工具如PingCode等中而不是在文档中储存你的需求。在这种情况下你可以将基线定义为计划用于特定发布的数据库中的需求的子集。
使用需求管理工具储存需求可以维护一组聚合的当前承诺的需求和计划的未来需求。一些商业需求管理工具包括基线功能以区分哪些需求可能是每个需求的特定版本属于某个特定的基线。
另一种方法你可以在需求管理工具中定义一个需求属性用来保存发布编号或其他基线标识符。将需求从一个基线转移到另一个基线只需要简单地改变那个需求属性的值。
当每个需求只属于一个基线时这种属性方法就有效。然而如果你正在并行开发产品的多个版本如家庭版和专业版你可能需要将同一个需求或不同版本的同一需求分配到多个基线。在这种复杂的基线管理中工具的支持是必要的。
在迭代开发生命周期中每个迭代的基线只会代表整个系统功能的一部分。
例如我们的团队曾经在一个小项目中采取了这种方法。这个项目每三周发布一次。对于每个周期业务分析员都会指定在接下来的三周内需要设计、编码、集成和验证的软件需求。因此每个需求基线都非常小。在典型的敏捷方法中随着开发者定期向用户发布有用的版本产品逐渐增长到完全的功能。
三、什么时候执行基线
业务分析师有时会对确定需求基线的时机感到困扰。这是一个重要的决定因为确定基线会有以下几个影响
正式的变更控制开始变更请求是对已确定的基线提出的。因此基线为每个提出的变更提供了参照点。在你确定任何项目基线之前需要确保变更控制流程及其参与者都已准备就绪。
项目经理确定所需的人员水平和预算软件项目需要管理五个维度特性、质量、时间表、人员和预算。一旦在基线中确定了特性和质量目标项目经理就会调整其余三个维度以完成项目的目标。它也可以反向操作。如果员工、预算和/或时间表是由外部力量预先设定的基线的内容必然会受限以适应那些限制的项目框架。
项目经理做出时间表承诺在确定基线之前需求仍然是不稳定和不确定的因此估计也同样是不稳定和不确定的。一旦建立了基线发布的内容应被足够理解以便管理者可以做出实际可行的承诺。管理者仍然需要预见需求的增长根据他们的需求管理计划并在他们承诺的时间表中包含合理的应急缓冲。
过早地确定需求基线可能会推动变更过程进入过度运行状态。实际上在定义基线后收到大量的变更请求可能是一个信号表明你的需求收集活动是不完整甚至无效的。另一方面等待太久才确定基线可能是分析瘫痪的一个迹象也许业务分析师过于努力地完善需求集然后再交给开发团队。
我们要注意需求的收集试图定义一套足够好的需求以让团队可以在可接受的风险水平下继续开发。可以使用表1中的清单来判断你何时准备好定义需求基线作为继续开发工作的坚实基础。
业务规则是否确定了影响系统的业务规则以及是否指定了执行或遵守这些规则的功能。变更管理请确认已建立了能有效处理需求变更的变更控制流程同时要确认所要使用的变更控制工具已经配置完成并对用户进行了相应的培训。客户意见与关键的客户代表进行确认了解是否在上次沟通后需求有所改变。是否有新的业务规则生效现有规则是否有所调整需求的优先级是否发生变动是否有新的客户他们的需求与旧的客户是否不同接口检查系统是否有足够的功能去管理和操作用户、其他软件系统、硬件组件和通信服务封外部连接和交互。模型确认和用户代表一起审核所有的分析模型并通过测试用例检查系统是否能允许用户执行他们需要的活动。原型如果制作了原型务必确保有合适的客户进行评估。需求规范说明是否已经根据这些反馈进行了调整一致性最后检查所定义的需求集能否实现项目的业务目标确保业务需求、用户需求和功能需求之间的一致性。审查确保所有下游的“需求消费者”进行了需求审查这些“消费者”包括设计师、开发人员、测试人员、文档编写人员、辅助编写人员、人因工程师以及其他依据需求进行工作的人员。范围确认所有考虑加入基线的需求都在当前确定的项目范围之内。因为项目范围在项目初期确认可能已经发生了变化。TBDs待定部分需要检查文档中是否有标记为”TBD”的部分”TBD”通常表示某些细节或需求尚未确定或尚未完全定义。模板确保完成了软件需求规范(SRS)文档模板的每一部分并检查是否有内容并不适用于本项目。常见的遗漏包括质量需求、约束和假设。用户类别核查所有用户类别的代表是否都给出了反馈。可验证性 需要有明确的方式来验证每个需求是否得到了准确的实现用户接受标准User Acceptance Criteria是非常有用的工具。
表 1. 定义需求基线前需要考量的因素
需求永远不可能百分之百完美。业务分析师和项目经理需要评估在已知的约束下是否能够实现所定义的客户需求而设定基线有助于确保所有利益相关者对项目的预期成果达成一致意见。
需求管理 需求管理指南
需求管理 需求管理主要内容 | 需求管理的重要性 | 采用敏捷方法进行需求管理 | 如何克服需求管理的 5 大挑战 | 更多
需求编写 功能需求的示例和模板 | 采用 EARS 方法来改进需求工程 | 如何编写一份优秀的产品需求文档PRD | 功能性需求与非功能性需求的区别 | 有效需求的特征 | 更多
需求收集和管理流程 需求工程概述 | 产品团队的需求分析指南 | 敏捷产品团队的 11 种需求收集技巧 | 定义和实施需求基线 | 更多 需求的可追溯性 什么是需求可追溯性 | 可追溯性在现代产品和系统开发中的关键作用 | 如何创建和使用需求追溯矩阵 | 更多
需求确认和验证 产品团队的需求验证和确认 | 更多
需求管理领域文章 做好需求分析的4大关键认知 | 盘点国内9款热门需求管理系统 | 构建产品路线图的方法与工具 | 做好需求优先级判断的7种主流模型 | 采用敏捷方法进行需求管理 | 更多
