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