需求及相关问题说明书.doc

需求及相关问题说明书版本号 V2010 需求定义：“需求”详细描述软件系统应该做什么，这是达成解决方案的第一步。“需求活动”也称为“需求开发/requirements development”、“需求分析/requirements analysis”、“分析/analysis”、“需求定义/requirements definition”、“软件需求/software requirements”、“规格书/specification”、“功能规格书/function spec”、“规格/spec”。成本：在大型项目中，如果在架构阶段检测到需求错误，那么修复它的成本通常是“在需求阶段检测并修改该错误”的成本的3倍。如果在编码阶段检测到需求错误，修复成本是5至10倍；在系统测试阶段，成本是10倍；在发布以后，成本陡增为10至100倍。原则：发现错误的时间要尽可能接近引入该错误的时间。缺陷在软件食物链里面呆的时间越长，它对食物链的后级造成损害就越严重。由于需求是首先要完成的事情，需求的缺陷就有可能在系统中潜伏更长的时间，代价也更加昂贵。在软件开发过程的上游引入的缺陷通常比那些在下游引入的缺陷具有更广泛的影响力。这也使得早期的缺陷代价更加高昂。神话：稳定需求的神话稳定的需求是软件开发的最高目标(但也暗示希望渺茫)。需求像水。如果冻结了，就容易在上面开展建设。开发过程能够帮助客户更好地理解自己的需求，这是需求变更的主要来源。计划严格依照需求行事，实际上就是计划不对客户的要求做出回应。平均水平的项目在开发过程中，需求会有25%的变化。在典型的项目中，需求变更导致的返工占到返工总量的75%到85%。在构建期间处理需求变更在构建期间，要最好地应对需求变更，有以下一些可以采用的方式。1、使用需求核对表来评估你的需求的质量 如果你的需求不够好，那么就停止工作，退回去，先把它做好，再继续前进。当然，因为在此期间你会停止编码，所以感觉似乎进度会落后。不过，假设你正开车从芝加哥到洛杉矶，突然看到纽约的路牌，那么停下来查看路线图是浪费时间吗？当然不是，如果没有对准正确的方向，那就要停下来检查一下路线。2、确保每一个人都知道需求变更的代价 客户只要想到一个新功能就会很兴奋。在兴奋时血液会涌向大脑，人会晕头晕脑，他会把所有你们开过的讨论需求的会议、签字仪式，以及已经完成的需求文档统统抛诸脑后。最简单的对付这种新功能中毒症患者的办法是说：“咦，这听起来是一个很不错的主意。不过由于它不是需求文档里的内容，我会整理一份修订过的进度表和成本估计表，这样你可以决定是现在实施，还是过一阵子再说。”“进度”和“成本”这两个字眼比咖啡和洗冷水澡都要提神，许多“必须要有/must haves”很快会变成“有就最好/ nice to haves”。3、假如你的组织对于“先做需求分析”的重要性并不敏感，那你就指出在需求阶段进行修改，要比之后进行修改的代价低得多。使用本章“关于构建之前要做前期准备的绝对有力且简明的论据”。4、建立一套变更控制程序 如果你的客户激情不减，那就要考虑建立一个正式的变更控制委员会，评审提交上来的更改方案。客户改变他们的想法，认识到他们需要更多的功能，这不是坏事。问题是他们提出更改方案太频繁了，让你跟不上进度。如果有一套固定的变更控制程序，那么大家都会很愉快你知道自己只需在特定时候处理变更；而客户知道你打算处理他们的提议。5、有需求变动，需要做过记录，系统有bug,也要有人follow，下一个版本要做那些事情，都有凭有据。把每个人的工作写出来，文档化，可以改善沟通的效率.6、使用能适应变更的开发方法 某些开发方法让你“对需求变更做出响应”的能力最大化。演进原型(evolutionary prototyping)法能让你在投入全部精力建造系统之前，先探索系统的需求。演进交付(evolutionary delivery)是一种分阶段交付系统的方法。你可以建造一小块、从用户获得一点反馈、调整一点设计、做少量改动，再多建造一小块。关键在于缩短开发周期，以便更快地响应用户的要求。7、放弃这个项目 如果需求特别糟糕，或者极不稳定，而上面的建议没有一条能奏效，那就取消这个项目。即使你无法真的取消这个项目，也设想一下取消它之后会是怎样的情况。在取消它之前想想它有可能会变得多糟糕。假如在某种情况下你可以放弃这个项目，那么至少也要问问自己，目前的情况和你所设想的那种情况有多大距离。8、注意项目的商业案例 在提到实施这个项目的商业理由的时候，许多需求事项就会从你眼前消失。有些需求作为功能特色来看是不错的想法，但是当你评估“增加的商业价值”时就会觉得它是个糟透了的主意。那些记得“考虑自己的决定所带来的商业影响”的程序员的身价与黄金相当不过我更乐意为此建议获得现金报酬。需求变更和设计变更在开发过程中，你一定会有很多关于如何改善系统的想法。如果每产生一个想法就实施相应的变更，你会发现自己走上了软件开发的treadmill(一系列似乎永不完结的工作)虽然系统在发生变化，但却没有向着“完成”的方向迈进。 以下是一些用于控制设计变更的指导原则：遵循某种系统化的变更控制手续。当你面临很多变更需求时，系统化的变更控制手续宛如天赐之物。通过建立一套系统化的手续，你就能将变更放在“在对系统整体最为有利”的环境下进行考虑。 成组的处理变更请求。人们倾向于一有想法就去实现那些较容易的变更，因此类变更消耗了资源，会导致更好的变更因资源不足而被丢弃。应该记下所有的想法和建议，不管它实现起来有多容易。把它记录下来，直到你有时间去处理它们。到那时，把所有变更当做一个整体来看待，从中选出最有益的一些变更来加以实施。 通过“分诊”会议安排问题的优先级，并且决定每个问题如何去解决。关于“分诊(Triage)”，这是一种根据紧迫性和救活的可能性，在战场上决定哪些人优先治疗的方法。战地医学的基本原则之一是，将伤者划分为3类：(1)无论是否接受医疗都会死亡；(2)无论是否接受治疗都没有生命危险；(3)只有及时地接受医治才能促使性命。抛开它的病理本质，分类本身极其重要，只要你希望的是最大限度地保存有生力量。如果你不进行分类，结果将会比你做分类时要糟糕得多。评估每项变更的成本。评估变更成本时要仔细考虑所有环节的代价，而不仅仅是编码。 提防大量的变更请求。变更请求数量太大是一个很关键的警报信号，这表明需求、架构或者上层设计做得不够好，从而无法有效的支持构建活动。 成立变更控制委员会或者类似机构。变更控制委员会是一项“设定需求变更的优先级”和“控制需求变更”的最佳实践。如果规范书需要变更，需要提出“规范书变更请求(Spec Change Request,SCR)”或称为“设计变更请求(Design Change Request,DCR)”，经变更控制委员会批准后生效。 警惕官僚主义，但也不要因为害怕官僚主义而排斥有效的变更控制。缺乏规范的变更控制是当今软件业面临的主要管理难题之一。不要去考虑“未做跟踪但却同意执行的变更”。但变更控制有滋生官僚主义的倾向。变更控制的实质就是确定什么最重要，所以不要因为害怕官僚主义就不去享受变更控制的诸多益处。需求核对表这张需求核对表包含了一系列的问题问问自己项目的需求工作做得如何。该表并不会告诉你如何做出好的需求分析，所以列表里面也不会有这样的问题。在开始构建之前，用这份列表做一次“心智健全”检查，看看你的地基到底有多坚固用“需求里氏震级”来衡量。 并不是核对表中所有的问题都适用于你的项目。如果你做的是一个非正式项目，那么你会发现有些东西根本就不需要考虑。你还会发现一些问题你需要考虑，但不需要做出正式的回答。如果你在做一个大型的、正式的项目，你也许就要逐条考虑了。针对功能需求：1是否详细定义了系统的全部输入，包括其来源、精度、取值范围、出现频率等？2是否详细定义了系统的全部输出，包括其目的地、精度、取值范围、出现频率格式等？3是否详细定义了所有的输出格式(如：web页面、报表等)？4是否详细定义了所有硬件及软件的外部接口？5是否详细定义了全部外部通信接口，包括握手协议、纠错协议、通信协议等？6是否列出了用户想要做的全部事情？7是否详细定义了每个任务所用的数据，以及每个任务得到的数据？针对非功能需求（质量需求）1.是否为全部必要的操作，从用户的角度，详细描述的期望的响应时间 ？2.是否详细描述了其他与计时有关的考虑，如处理时间、数据传输率、系统吞吐量等？3.是否详细定义了安全级别4.是否详细定义了可靠性，包括软件失灵的后果、发生故障时需要保护的至关重要的信息、错误检查与回复的策略等？5.是否详细定义了机器内存和剩余硬盘空间最小值？6.是否详细定义了系统的可维护性，包括适应特定功能的变更、操作环境的变更、与其他软件接口变更的能力？7.是否包含对“成功”的定义，“失败”的定义？需求的质量1. 需求是用用户的语言书写的吗？用户也这么认为吗？2. 每条需求都不与其他需求冲突吗？3. 是否详细定义了相互竞争的特性之间的权衡-例如，健壮性与正确性之间的权衡？4. 是否避免在需求中规定设计(方案)5. 需求是否在详细程度上保持相当一致的水平？有些需求应当更详细的描述吗？有些需求应该更粗略的描述吗？6. 需求是否足够清晰，即使转交给一个独立的小组去构建，他们也能理解吗？开发者也这么想吗？7. 每个条款都与待解决的问题及解决方案相关吗？能从每个条款上溯到它在问题域中对应的根源吗？8. 是否每条需求都是可测试的？是否可能进行独立的测试，以检验