软件的需求分析需求分析017

下载第一章，在进行变更请求管理软件流程评估后，我们询问项目团队成员如何接受产品的变更要求，其中一个人说：“每当市场代表对B r u c e或S a n d y提出变更请求时，我们都必须同意。”回答说。他没有正面回答我的问题。未控制的变更是项目混乱、未按进度执行或软件质量低的常见原因。为了使开发组织能够严格控制软件项目，必须仔细评估建议的更改。选择决定变更的合适人选。变更必须立即通知所有相关人员。项目必须按照一定的程序采用需求变更。项目风险承担者只有在开发过程中能够控制变更的情况下，才能知道要传达什么，以及哪个会诱导与目标的差异。您对项目了解得越多，就越知道更改要求条件有多困难。您的原则是，在需求文件中一定要反映专案变更，并在需求文件中准确说明要交付的产品。如果软件要求文档与产品不匹配，就像没有软件要求文档指导开发组开发一样，没有任何用处。如果需要进行变更，则必须从较高层次到较低层次处理受影响的需求文件。例如，建议的变更可能会影响使用实例和功能要求，但业务要求不受影响。变更高层次的系统需求可能会影响多个软体需求。如果更改最低级别的要求(通常是性能要求)，则要求可能与较高级别的文档不匹配。17.1项目范围扩大的Capers Jones(1 9 9 4)在报告中声称，需求扩大会给管理信息系统项目的80%和军事软件项目的70%带来风险。扩展要求是在确定了软件要求基线后，添加新功能或进行重大更改。问题不仅仅是需求变更本身，如果需求变更晚，会对已执行的工作产生重大影响。如果采用了每个建议的要求，项目发起人(s p o n s o r)、参与者和客户将永远无法完成。在许多项目中，对某些要求的改进是合理的，是不可避免的。业务流程、市场机会、竞争产品和软件技术在系统开发过程中可能会发生变化，管理部门也将决定对项目进行一些调整。项目日程上要留有变更必要要求的馀地。如果不扩大范围，持续采用新功能，持续调整资源、进展或质量目标将是非常有害的。这里有一些变化，那里有一些附加，很快项目就不能按照顾客预期的进度和预期的质量交付了。管理范围扩展的第一步是使用新系统的视图、范围、文档限制和业务要求的一部分，如第6章所述。评估每个建议的要求和属性，并将它们与项目的视图和范围进行比较，以确定是否应采用它们。强调客户参与的有效需求获取方法只有在提交承付款和分配资源后，才能减少缺少的需求数(Jones 1996a)。控制需求扩展的另一有效技术是原型方法(Jones 1994)，它帮助用户与开发人员沟通，准确了解用户的实际需求。事实上，扩大范围的方法是敢于说不。(we n b e rg 1995)。很多人不喜欢说“不”，因此开发者不得不在各种压力下接受各提案的要求。“客户总是对的。”“我们会完美地满足客户。”这句话在哲学上是对的。一旦这样行动，就要付出代价。无视代价也不能改变“改变不是免费的”的事实。我知道一家成功的业务开发公司，Ceo习惯于提出新的特征，但是开发经理总是说：“现在不行。”“现在不行”的话比单纯拒绝的时候灵活多了。因为在后期版本中隐含着采用其特性的希望。采用客户提出的所有特性可能会错过提交日期，导致质量下降(s l I p s h o d)增加开发者的疲劳。客户并不总是对的，但他们是上帝，必须尽可能在下一版本中满足他们的要求。理想情况下，在开始配置之前收集所有新系统的要求，默认情况下，在开发时不会更改。这就是瀑布式软件开发寿命模型的前提，但实际上并不奏效。当然，在某些方面，您必须冻结对特定版本的要求，不要进一步更改。但是，如果提前了解这些要求，开发人员可能不知道客户需要什么，因此，开发人员必须响应这些要求更改。为了应付这种实际情况，有必要以变更过程为基础采用。17.2变更控制进程良好的变更控制进程为项目风险承担者提供正式的建议要求变更机制。通过此收购过程，项目负责人(l e a d e r)可以控制产品生命周期成本，从而在充分的信息条件下做出决定，以增加客户和业务价值。您通过变更控制进程跟踪建议变更的状态，以确保建议的变更不会丢失或被忽略。确定需求集的基线后，必须遵循所有建议变更的变更控制进程。变更控制流程不会妨碍变更。相反，通过确保采用最合适的更改，将更改带来的负面影响降至最低的通道和过滤器。变更进程必须文档化，并尽可能简单。当然，最重要的是有效性。如果变更进程效率不高、时间长且复杂，则最好使用前面的方法来做出变更决定(可能需要这样做)。需求变更控制与项目中的其它配置管理决策密切相关。管理需求变更类似于跟踪错误和做出适当的决策过程，同一工具可以支持这两种活动。但是请记住，这是工具，不是过程。使用业务问题跟踪工具管理建议的要求变更并不能取代记录变更要求内容和处理的过程。17.2.1变更控制策略条目管理必须实现描述如何处理要求变更的策略。战略只有现实、可行和加强，才有意义。变更需求的下列策略很有用：所有要求变更必须遵循的进程；如果按照此过程未采用一个变更要求，则以后的进程将不再考虑。对于未批准的变更，除可行性论证外，不能再进行其他设计和实施工作。简单请求变更并不意味着变更可以实现。要实施的变更由项目变更管理委员会(C C B)决定(本章介绍C B)。项目风险承担者必须能够理解变更数据库的内容。不能从数据库中删除或修改变更请求的原始文档。140第三部分软件要求管理下载集成的每个要求变更必须能够跟踪批准的变更请求。当然，大变更对专案有重大影响，小变更则可能没有影响。原则上，所有变更都必须通过变更控制进程处理。但实际上，部分具体的需求决定权可以交给开发人员决定。但是，只要更改涉及多个更改，就必须通过控制进程进行处理。有两部分项目：用户集成接口应用程序和内部知识库，但变更进程不足。如果知识库开发人员更改了外部接口，但没有将此更改通知应用程序开发人员，则会发生此问题。在测试过程中，有些项目发现开发人员应用了新修改的功能，但没有通知其他团队，重新处理了测试程序和用户文档。使用集成变更控制方法可以避免这些问题导致的错误、开发返工和时间消耗。17.2.2变更控制步骤图1 7-1是描述可应用于需求变更和其它项目变更的变更控制步骤的模板。以下是流程如何处理要求变更的主要说明。输入标准(entry criteria)-执行流程或步骤前必须满足的条件，这四个元件和一些流程说明可能会很有用。负责完成进程和步骤中包含的各种任务(t a s k)和项目中的任务。验证(v e r I f y)操作正确完成的阶段。退出条件(exit criteria)-指示过程或步骤完成的条件。a .简介A.1目的a.2范围a.3定义b .角色和责任c .变更请求状态d .启动条件e .任务e.1变更请求创建e.2变更请求评估e.3决策e.4变更请求评估e . 3决策e . 4变更负责人通知f .验证g .终止条件h .变更控制状态报告附录：存储的数据项图17-1简单变更控制步骤模板a如果步骤仅适用于特定产品的变更，则应在简介中明确指出。简介还指示是否忽略特定类型的更改。例如，对于在项目开发过程中发生的过渡或临时产品，您可以定义必要的条款，以忽略变更并了解文档的其馀部分。b .下载角色和责任列表(按角色而不是按名称顺序分类)参与变更控制活动的项目组成员及其责任第一章管理变更请求141。表1 7-1提供了一些相关角色。根据自己的环境和需要调整这些角色及其相应的责任，并尽可能保持过程简单。不需要一个人扮演一个角色。例如，项目经理也可以接收已提交的变更要求。对于某些较小的项目，有几个或全部-一个角色。表17-1变更管理活动中可能的项目角色说明和责任变更控制委员会主席变更控制委员会主席，在c b意见不一致的情况下，单独决定c b可以决定采纳或拒绝项目的建议变更请求的组评估人可以根据项目经理的请求分析建议变更的影响，负责执行已经批准的请求变更。按时更新更改状态的人员提案人提交新更改请求的人员项目经理向分配评估人和修改量的人员请求接收人接受更改请求提交的人员验证人确定更改是否正确执行的人员c .更改请求状态更改需要寿命，相应地需要不同的状态。如图1 7-2所示，可以使用状态转换图表示这些状态的变化，并且仅在满足特定条件的情况下才能更新状态。d .启动条件变更控制阶段的默认启动条件是通过适当的渠道接受法律变更请求。所有潜在提议者都必须知道是以书面形式提交变更请求、通过基于We b的表格提交变更请求、发送电子邮件，还是使用变更控制工具。将所有变更控制传送至单一联络点，并为每个变更请求提供一致的识别标签。e .当任务收到新的变更请求时，下一步是评估建议的技术可行性、成本、业务要求和资源限制。变更控制委员会主席要求评估者进行系统影响分析(见第一章)、风险分析、风险分析和其他评估。通过这些分析，您可以很好地了解接受更改的潜在影响。评估者和变更控制委员会都必须考虑拒绝变更所带来的业务和技术影响。做出决策的人员必须进入变更管理委员会，决定是采用还是拒绝请求的变更。C C B为每个采用的变更要求设置优先级或变更实施日期，或将其分配给指定的产品。变更控制委员通过更新请求状态并通知所有相关团队成员来传达变更决定。可能需要对工作产品进行变更，如软件要求规范文档、要求数据库、设计模型、用户界面部件、代码、测试文档和用户文档。修改量必须根据需要更新相关的工作产品。f .验证验证要求变更的一般方法是检查更新的软件要求规范手册，使用实例文本文件，确保分析模型正确反映变更的所有方面。使用跟踪功能信息查找受变更影响的系统部分，然后验证变更是否已实施(请参阅第1章)。属于多个组的成员可以通过下游工作产品测试或检查操作参与验证变更操作。验证后，修改器安装更新的工作产品的一部分，并通过调试使其与其他部分正常工作。g .要完成终止条件更改控制执行过程，必须满足以下终止条件：142第3部分软件要求管理下载图17-2更改要求状态转换图请求状态为拒绝、终止或取消。所有修改过的工作产品都安装在适当的位置。提案者、变更控制主席、项目经理和其他相关项目参与者已注意到变更的详细信息和当前状态。需求可追溯矩阵已更新(请参阅第1章)。h .变更控制状态报告使用报告、图表汇总变更控制数据库中按内容和状态列出的变更请求数。说明生成报告的步骤。项目经理通常使用这些报告来跟踪项目状态。附录：“已保存的数据项”(saved data items)表1 7-2列出了每个变更请求保存的一些数据项。定义您自己的列表时，请指明必需的和可选的项目。此外，在变更控制工具中是否自动修改每个值，或提交指定人员的第1章第7章变更请求管理143下载变更请求评估人，以确定影响分析CCB接受变更并指定版本。接受更改并完成验证请求完成评估提交拒绝CCB更改不应用更改取消更改取消更改取消更改产品验证器安装产品验证器验证更改验证无验证要求，产品验证失败更正。如果您有经验，可能喜欢直接修改数据项，因此，使用电子表格或纸张实验处理过程后，请让自动工具启动它。表17-2一般变更请求资料项目资料项目名称变更来源变更请求功能区域、市场、管理、客户、软体工程、硬体工程与测试变更需求I D编号变更指定给每个请求的标签或序号变更型态需求变更、建议变更等请求型态。错误报告提交日期提交变更请求的日期更新日期最近变更请求更新日期说明以自由格式文本说明所请求变更实施的优先级。提交主要负责人姓名提议者变更请求的名称，以实施由变更控制委员会指定的每个变更的相对重要性(例如，低、中、高修正者变更)。您还可以存储与该人员相关的信息提议者设置的优先级。提议者授予每个变更的相对重要性。例如：低、中、高版本您可以请求文档名称更改，以反映计划中更改的产品版本号项目更改所需的项目名称更改。您可以使用与每个变更对应的变更文件来建立各种植入文件。必须保持所有变更请求的当前状态。您可以在图1 7-2中选择状态标题。变更的简短摘要(最好是单行)验证器可以使用确定变更是否正确实现的名称17.2.3变更控制工具自动工具，有效地执行变更控制进程(Wiegers 1996a)。许多人使用业务问题跟踪工具收集、存储和管理需求变更。使用这些工