怎样编写高质量“软件需求说明书”样本.doc

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