如何编写一个好的需求.docx

如何编写一个好的需求 如何编写高质量需求 Karl E iegerrocess Impact很多软件需求说明书（SS）写得特别糟糕。任何产品的质量须要其原始材料的质量保证，糟糕的软件需求说明书不行能产出优秀的软件。不幸的是，几乎没有开发人员受过与需求的抽象、分析、档、质检有关的教化。而且，没有特别多的需求可以借鉴学习，部分缘由是很少有工程可以找到一个的借鉴，其他缘由是公司不情愿将其产品说明书放在公共区域。这篇章描述了高质量需求叙述和说明的几个特性（特点）。我们将用这些观点检查一些有缺陷的需求，带着痛楚重新编写。而且我会谈一些如何编写的需求的提示。你或许想通过这些质量标准评估你的工程需求。对于修订，或许迟了，但你会学到一些有用的东西，并帮助你的小组在下次编写出更的需求。不要期望能够编写出一份能体现需求应具备的全部特性的SS。无论你怎么细化、分析、评论和优化需求，都不行能达到完备。但是，假如你牢记这些特性，你就会编写出更的需求，生产出更的产品。一、高质量需求说明书的特性我们如何从一些有问题的需求中辨别出的软件需求？推断每个需求是否具备应有的特性的一种方式是由持有不同观点的工程资金管理人所作的正规检查。另一种有力的方法是在编写代码前依据需求编写测试例子。测试例子能够明确显现在需求中描述的产品德为（特性），能够显现缺陷、冗余和模糊之处。? 正确：每个需求必需精确描述要交付的功能。正确性依据于需求的来源，如真实的客户或高级别的系统需求说明书。一个软件需求与其对应的系统需求说明书相抵触是不正确的（当然，系统需求说明书本身可能不正确）。只有用户的代表能够确定用户需求的正确性，这就是为什么在检查需求时，要包括他们或他们的代理的关键所在。不包括用户的需求检查就会导致开发人员的：“这是没意义的”，“这可能是他们的意思”等众所周知的揣测。? 可行性：在已知的实力、有限的系统及其环境中每个需求必需是可实现的。为了避开需求的不行行性，在需求分析阶段应当有一个开发人员参加，在抽象阶段应当有市场人员参加。这个开发人员应能检查在技术上什么能做什么不能做，哪些须要须要额外的付出或者和其他的权衡。? 必要性：每个需求应载明什么是客户的确须要的，什么要顺应于外部的需求，接口或标准。每个需求源于你认可、具有权说明需求的原始资料，这是考虑必需的另外情形（译注，此句翻译不顺，请参照原：nother way to think of “necessary” is that each requirement originated from a source you recognize as having the authority to specify requirements）。跟踪每个需求回溯到出处，如用例，系统需求，规章，或来自其他用户的看法。假如你不能标识出处，可能需求只是个镀金的例子，没有真正的必需。? 优先权：为了表明在一个具体的产品版本中应包含哪些要点，须要为每个需求，特征，或用例安排实现的优先权。客户或其代理都应有剧烈的责任建立优先权。假如全部的需求都被视为同等重要，那么由于在开发中，预算削减，安排超时或组员的离开导致新的需求时， 项目经理将不能起到作用。优先权的作用是供应给客户的价值，实现的相关费用，实现相关联的有关技术风险。我是用3种级别的优先权：高优先权表明需求必需体现在下一个产品版本中，中优先权表明需求是必需的，但是假如须要可以推迟到晚一些的产品版本中，低优先权表明有它很，但我们必需相识到假如没有足够的时间或资源，它可以被放弃掉。? 明确：需求叙述的读者应只能从其得到唯一的说明说明，同样，一个需求的多个读者也应达成共识。自然语言极易导致模糊。要避开运用一些对于SS作者很清晰但对于读者不清晰的主观词汇，如：用户友性，简单，简洁，快速，有效，几个，艺术级，改善的，最大，最小等等。每写一个须要都应简洁，简洁，直观的采纳用户熟知的语言，不要采纳计算机术语。检查需求模糊的有效方式包括需求说明书的正规检查，依据需求写测试，建立用户的假想来说明产品某个特定部分预期的特性。? 可证明：看你是否能够做出测试安排或其他验证方式，如检查和实证，来确定在产品中每个需求是否正确的实现。假如需求是不行验证的，确定需求是不是正确的实现就成了推断的事。需求之间不一样，不行行，不明确也能导致不行证明。任何需求假如说产品将要支持什么也是不行证明的。? 完整：不应当遗漏要求和必需的信息。完整性也是一个需求应具备的。发觉缺少的信息很难，因为根本不存在。在SS中将需求以分层书目方式组织，将帮助评审人员理解功能性描述的结构，使他们很简单指出遗失的东西。在需求抽象时，相对于系统功能，你过多的留意用户的业务，将导致在需求的全局观和引进不是真正必需的需求上显得不足。在需求抽象上，应用用例方法会发挥很的作用。能够从不同角度察看需求的图形分析模型也可以检查出不完整性。假如你知道已缺少一些信息，运用B（to be determined）标准标记可以突出这些缺陷，当你在构建产品的相关部分时，就可以从一个给定的需求集中解决全部的缺陷。? 一样性：一样性需求就是不要于其他的软件需求或高级别的系统（商业）需求发生冲突。需求中的不一样必需在开发起先前得到解决。只有经过调研才能确定哪些是正确的。修改需求时肯定要谨慎，假如只审定修改的部分，没有审定于修改相关的部分，就可能导致不一样性。? 可修改性：当每个需求的要求修改了或维护其历史更改时，你必需能够审定SS。也就是说每个需求必需相对于其他需求有其单独的标示和分开的说明，便于清楚的查阅。通过良的组织可以使需求易于修改，如：将相关的需求分组，建立书目表，索引，以及前后参考（照）。? 可追踪：你应能将一个软件与其原始材料相对应，如高级系统需求，用例，用户的提议等。也能够将软件需求与设计元素，源代码，用于构造实现和验证需求的测试相对应。可追踪的需求应当具有独立标示，细密和结构化的编写，不应过大，不应是叙述性的字和公告式的列表。二、需求质量的评审这些有关需求质量的特性的描述在理论上都是特别的，但一个的需求究竟是个什么样子的呢？为了体现得更切合实际，我们做个小练习。下面有几个从实际的工程选出的需求，依据上面的质量标准，评估每个需求，看看有什么问题，然后用更的方式重写。我将对每个例子都提出自己的分析和改进的建议。也欢迎你提出不同的见解。我所占优的只是我知道每个需求的出处。因为你我都不是真正的客户，我们只能揣测每个需求的意图。例1“产品应在不少于每60秒的正常周期内供应状态信息”这个需求是不完整的：状态信息是什么，如何显示给用户。这个需求有几处模糊。我们在谈论产品的哪部分？状态信息间隔真的假定为不少于60秒？，甚者每10年显示一条新的状态信息也可以？或许它的意图是消息间隔不应超过60秒，那么1毫秒是不是太短？“每”这个词导致了不确定性。问题的后果，就是需求的不行证明。弥补缺陷，重写需求的一种方法：“1、状态信息1.1后台任务管理器因该以误差上下不超过10秒的60秒间隔，在用户界面的指定位置显示状态信息1.2假如后台进程处理正常，那么应当显示任务已完成的一百零一分数/比1.3任务完成时，应显示相关的信息1.4后台任务出错应当显示错误信息为了分别测试和追踪，我将其分成了多个需求。假如将几个需求串接在一节中，在构造和测试时就很简单漏掉一个。例2. “产品应瞬间在显示和隐藏不行打印字符间切换”计算机在瞬间不能做任何事，所以这个需求不切实可行。它的不完整性表现在没有声明触发状态切换的条件。软件要在某些条件下更改自己？或者用户为了仿照更改要做一些动作？而且，在档中变更显示的围是多大：选中的本，完全的档，或其他的？这也是个模糊的问题。不行打印字符合隐藏字符一样吗？或者是一些属性标记或一些限制字符？问题的后果，就是需求的不行证明。象这样编写需求或许更一些：“用户能够在一个由特定触发条件激活处于编辑的档中在显示和隐藏全部L标记间切换”。现在就很清晰，不行打印字符是L标记。由于没有定义触发条件，需求对设计没有约束力。只有设计人员选定了触发条件后，你才能编写测试验证触发的正确操作。例3 “L分析器可以产生L标记错误报告，帮助L入门者快速解决错误”。单词“快速”使其模糊，没有加进错误报告的定义也是其部完整。我不知道，你怎么验证这个需求。找一个自称为L的入门者，看看能不能依据错误报告快速解决错误？试试这个：“L分析器可以产生一个错误报告，错误报告包含有在被分析件中出错的L本和行号以及错误的描述。假如没有错误，就不会产生错误报告”。现在我们知道了，什么会被加到出错报告中，但是出错报告是个什么样子，则留由设计人员确定。我们还指定了一个例外：假如没有发觉错误，不产生错误报告。例4 “假如可能，主管号码应通过联机校验，而不是通过主全体主管号码列表校验”。真到无望，什么是“假如可能”：假如技术上可行？假如主全体主管号码列表可以联机获得？要避开象“应当”的这类不准确的词。客户是须要这个功能性还是不须要。我曾看过一些需求说明书，采纳诸如：应，将，应当/将要等一些词描述优先级的微小差别。但我更喜爱用“应”清晰的说明需求的意图，指明优先级。这是修改后的：系统应校验输入的主管号码而不通过联机的主全体主官号码列表。假如在列表中没有发觉主管号码，将会显示一条错误信息，也不接受指令。在理解各个已完成的糟糕需求上，开发人员将会遇到的难题是：开发人员与客户将会在审核需求，未达成共识前发生激烈的争辩。具体检查大的需求档不是一件轻松的事情。我清晰有人做过，而且他们花在检查上的每一分钟都是值得的。相对于开发阶段和用户的埋怨电话，在这个阶段修补缺陷是便宜的，编写质量需求的方针编写优秀的需求是没有公式化的方法的。这须要大量的阅历，要从你在过去的档中发觉的问题学习。请在组织软件需求档时，严格遵从这些方针。? 句子和段落要短。采纳主动语气。运用正确的语法，拼法，标点。运用术语，要保持一样性，并在术语表或数据字典中定义它们? 要看需求是否被有效的定义，可以以开发人员的观点看看。在内心将“当你们做完了找我”这句加到档尾部，看看能不能是你惊慌起来。换句话说，你是否须要SS的编写者的额外说明帮助开发人员很的理解需求，以便于设计和实现？如果是的话，在接着工作前，需求还须要细化。? 需求编写者还要努力正确地把握细化程度。要避开包含多个需求的长的叙述段落。有帮助的提示是编写独立的可测试的需求。假如你认为一小部分测试可以验证一个需求的正确，那么它已经正确的细化了。假如你预想到多种不同类的测试，几个需求可能已挤到了一起，须要拆分开。? 亲密关注多个需求合成了单个需求。一个需求中的连接词“和”/“或”建议几个需求合并。不要在一个需求中运用“和”/“或”。? 通篇档细微环节上要保持一样。我曾望见过多个需求说明书前后不一样。如：“对于红色合法的颜色代码应是”及“对于绿色合法的颜色代码应是G”就有可以以分散的需求分别开，而“产品应能对来自语音编辑指示做出反应”应作为一个子系统，不应作为单个的功能性需求。? 避开在SS中过多的申述需求。在多处包含相同的需求可以使档更易于阅读，但也会给档的维护增加困难。档的多份本要在同一时间内全部更新，避开不一样性。假如你遵从了这些方针，你能够尽早地常常正式或非正式的审查需求，这些需求对于产品的构造，系统测试以及最终的客户满足，都会成为的奠基石。并且要记住，没有高质量的需求，软件就象一个巧克力的盒子，你不会知道你将要得到什么。上一篇：如何养成良好的写作习惯(改)下一篇：如何练出好作文写作实力第10页 共10页第 10 页 共 10 页第 10 页 共 10 页第 10 页 共 10 页第 10 页 共 10 页第 10 页 共 10 页第 10 页 共 10 页第 10 页 共 10 页第 10 页 共 10 页第 10 页 共 10 页第 10 页 共 10 页