如何撰写高质量的业务需求说明书

第一篇：如何撰写高质量的业务需求说明书

如何撰写高质量的业务需求说明书

作者：渤海银行资讯科技部张保军 原文刊登于《金融电子化》

在日常工作中，银行业务部门经常提出不同的业务需求，有新产品研发需求，有对现有系统功能改 进需求，有提取数据需求，有反映生产问题需求。这些需求提交给科技部门在信息系统中实现，科技部门经常说业务部门提交的业务需求涵义表达不清、内容描述不 完整等，科技人员难以按照业务部门要求实现。业务需求说明成为业务与科技经常扯皮、推诿、口舌之争之标靶，影响了软件项目研发进度和质量。

撰写一份高质量的业务需求说明书真的很难吗？本文就此与大家探讨如何撰写高质量的业务需求书。

一、说明书常见问题

（1）需求过于简单。有的只是一句话，如在现行的企业网银系统中增加批量代发工资功能，可以说，只给了一个需求题目，没有内容描述，具体业务处理流程和要求没有任何说明。

（2）需求内容不完整。业务需求书洋洋洒洒写了不少，但仔细一看，整个需求说明书内容缺东少西，不是少了会计分录，就是少了统计分析;不是少了界面输入项目，就是少了业务处理过程及要输出的结果等。

（3）需求内容描述不清晰。想要什么，业务流程如何处理，定义不清，概念界定模糊，有很多疑问。如需求书中对于统计报表只是画出一个大概表样，没有给出统计口径、数据来源等详尽资料。

（4）业务需求说明书本是很严谨的文书形式，但撰写人重视程度不够。需求说明书普遍存在错别字、语句涵义表达不清楚，口语化浓厚，引用图表不准确，主题表达不够清晰。

（5）需求说明书照搬照抄。为了图省事，把一些软件公司提供的产品功能介绍文档改头换面，作为业务需求说明书提交，业内人员一看就知道不是自己写的，很多地方根本不符合本行业务处理流程和系统功能。

（6）需求说明书没有统一撰写格式，不管是研发新产品、对现有系统功能改进、还是提取数据和生产问题需求，都没有一个简单实用的需求格式，随意书写，或者提供的格式完全不符合业务人员要求，大家不愿意或根本无法使用。

二、质量不高原因分析（1）撰写业务需求说明书时，业务部门没有很好组织人员对其需求进行认真讨论、分析，匆忙撰写，完成后没有很好斟酌修改完善，又匆匆忙忙提交给科技部门研发，事先也顾不上与科技部门做沟通，多听听科技人员的意见。（2）业务需求通常由银行各个职能部门提出，业务部门只从自己负责的业务角度出发考虑，缺乏与其他业务部门之间必要的沟通交流，缺少整合 性。许多需求仅仅是出于单个专业的需要，而不是全行整体需要，造成业务做法不能很好相互借鉴，有的甚至产生矛盾。在信息系统中相互制肘，重复又各成体系，形成不必要的内耗。

（3）业务人员对信息系统及整个银行业务处理流程及制度要求，缺乏深入了解掌握，造成撰写的需求内容描述不清楚，不准确。

（4）需求说明书没有模版，业务部门没有参照，或是科技部门提供的模版实用性不强，不符合业务要求。或更多是科技部门从技术要求方面出发，按照软件功能说明书内容格式让业务部门撰写需求。业务部门对很多技术要求不熟悉，不知道如何下手撰写。再有，模版过于教科书化。文档模版编写时，没有很好 依据公司自身现状，从实际出发并实地征求业务部门意见，造成业务部门不愿意或无法按照科技部门提供的需求撰写模版撰写需求，达不到预期效果。（5）业务与科技部门缺少需求交流机制、交流平台，大家都无法积极主动交流，无法倾听相互之间的意见。

三、提高撰写质量的措施

提高业务需求撰写质量，就要真正反映业务真实想法，和业务保持一致，并能提供科技部门软件研发需要的业务需求，确保在软件项目研发过程中，各项研发工作和需求之间的一致性，是需求管理的一项重要内容。

（1）业务与科技要建立良好的交流与合作关系。优秀的软件产品是建立在优秀的业务需求基础之上的，高质量的软件产品来源于业务人员和技术人 员相互之间有效的交流与合作。业务与科技部门要建立一个良好的业务需求交流沟通渠道和机制，解决工作中有关需求不清、推诿扯皮现象的发生，以面对面交流为 主，邮件、电话为辅。业务人员撰写完成业务需求后可以通过邮件的形式发给科技人员，让科技人员提出修改完善建议，相互之间交流沟通后，经过对业务需求说明 书反复多次修改后再提交。

（2）科技部门要做好角色的转变，帮助业务部门其实就是帮助自己，不要认为业务需求与科技部门无关。科技部门不能只关心技术，更应该关心产 品，跟踪产品应用情况，参与业务需求制订，与业务部门一起做好市场调研，参加前端性产品的研究和发展，帮助业务部门优化需求，可以提供业务需求说明书样本 让业务人员参照学习。

（3）业务需求要分类管理。业务需求通常可以分为新产品研发需求、功能变更需求、数据提取需求、生产问题需求等，针对不同业务要求设计不同 的业务需求撰写格式。新产品需求需要设计详细的需求撰写格式。功能变更需求、数据提取需求和生产问题需求要专题专述，变更那里则提出那里的数据，哪个系统 出现了问题、出现的问题现象是什么等内容，要重点突出，内容描述简单明了。（4）业务需求说明书撰写基本要求。①标准化：他山之石，可以借鉴，善于学习运用CMMI标准及其他软件公司好的做法，针对不同的业务需 求，都要给出一个符合公司实际，行之有效的撰写标准。②易用性：业务部门撰写的业务需求说明书要便于不同岗位人员进行阅读、理解、学习和使用。③简洁性： 业务需求书中描述的内容要突出主题，只反映要描述的问题，不包含其他不必要的东西，语言表达简明扼要，一清二楚，可以配以适当的图表，以增强其清晰性。④ 针对性：业务需求说明书要按不同的需求类型、面对不同的业务对象，实行差异化编制，根据实际需要进行编写。⑤一致性：业务需求说明书中的文字描述应当十分 确切，对于同一业务描写，不能出现多义性的描述，应当是一致，相互之间没有矛盾。⑥完整性：业务需求说明书都应当是完整的、独立的，没有遗漏和丢失的内 容。对于需求内容相同的部分，这种重复是必要的，不要图省事避免在文档中出现“见XX文档XX章节"的现象。⑦灵活性：不同的新产品研发需求，因其复杂程 度和规模不同，在保持需求格式不变的情况下，也需要对需求说明书内容中不同部分描述详细程度做调整。⑧可追溯性：业务需求说明书作为软件项目研发的一个重 要文档，并不是孤立的，而是与各个阶段完成的工作有密切的关系，随着研发工作的逐步延伸，具有一定的继承关系，体现出了可追溯的特性。如需求变更说明是在 原来业务需求说明书基础之上的变更，软件需求说明书会在详细设计说明书、测试案例等文档中有所体现。

（5）做好业务人员的培训学习。在工作交流过程中，业务人员经常讲，“科技人员总说业务需求写得不清楚，怎样写才能符合科技要求？”因此，针对如何撰写高质量的业务需求设计开发培训课程，有针对性地对业务人员进行培训，引导和教会业务人员撰写业务需求说明书，通过工作不断沟通交流、完善修 改，写出一份业务与科技都满意、高质量的业务需求也不是一件难事。

第二篇：如何编写高质量“软件需求说明书”.doc

如何编写高质量“软件需求说明书”2003-01-27· · ··天极论坛 2 下一页

你的工程应该有个好的起点。一个小组要带领客户进入需求启发阶段而且你要写软件需求说明书。这份说明有些大，但客户会很重视，所以说明必须得到赞同。

现在你正在设计其中的一个特性，已经发现了需求的一些问题。你可以用多种不同的方式解释需求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秒？，甚者每10年显示一条新的状态信息也可以？也许它的意图是消息间隔不应超 过60秒，那么1毫秒是不是太短？“每”这个词导致了不确定性。问题的后果，就是需求的不可证实。

弥补缺陷，重写需求的一种方法：

1、状态信息

1．1后台任务管理器因该以误差上下不超过10秒的60秒间隔，在用户界面的指定位置显示状态信息

1．2如果后台进程处理正常，那么应该显示任务已完成的百分数/比

1．3任务完成时，应显示相关的信息

1．4后台任务出错应该显示错误信息

为了分别测试和追踪，我将其分成了多个需求。如果将几个需求串接在一节中，在构造和测试时就很容易漏掉一个。

例2．“产品应瞬间在显示和隐藏不可打印字符间切换”

计算机在瞬间不能做任何事，所以这个需求不切实可行。它的不完整性 表现在没有声明触发状态切换的条件。软件要在某些条件下更改自己？或者用户为了模仿更改要做一些动作？而且，在文档中改变显示的范围是多大：选中的文本，整个的文档，或其他的？这也是个模糊的问题。不可打印字符合隐藏字符一样吗？或者是一些属性标志或一些控制字符？问题的后果，就是需求的不可证实。

象这样编写需求也许更好一些：“用户能够在一个由特定触发条件激活处于编辑的文档中在显示和隐藏所有HTML标记间切换”。现在就很清楚，不可 打印字符是HTML标记。由于没有定义触发条件，需求对设计没有约束力。只有设计人员选定了触发条件后，你才能编写测试验证触发的正确操作。

例3．“HTML分析器可以产生HTML标记错误报告，帮助HTML入门者快速解决错误”。单词“快速”使其模糊，没

有加进错误报告的定义也是其部完整。我不知道，你怎么验证这个需求。找一个自称为HTML的入门者，看看能不能根据错误报告快速解决错误？

试试这个：“HTML分析器可以产生一个错误报告，错误报告包含有在被分析文件中出错的HTML文本和行号以及错误的描述。如果没有错误，就不 会产生错误报告”。现在我们知道了，什么会被加到出错报告中，但是出错报告是个什么样子，则留由设计人员决定。我们还指定了一个例外：如果没有发现错误，不产生错误报告。

例4．“如果可能，主管号码应通过联机校验，而不是通过主全体主管号码列表校验”。真感到绝望，什么是“如果可能”：如果技术上可行？如果主全 体主管号码列表可以联机获得？要避免象“应该”的这类不确切的词。客户是需要这个功能性还是不需要。我曾看过一些需求说明书，采用诸如：应，将，应该/

将 要等一些词描述优先级的细微差别。但我更喜欢用“应”清楚的说明需求的意图，指明优先级。这是修改后的：系统应校验输入的主管号码而不通过联机的主全体主 官号码列表。如果在列表中没有发现主管号码，将会显示一条错误信息，也不接受指令。

在理解各个已完成的糟糕需求上，开发人员将会遇到的难题是：开发人员与客户将会在审核需求，未达成共识前发生激烈的争论。详细检查大的需求文档 不是一件轻松的事情。我清楚有人做过，而且他们花在检查上的每一分钟都是值得的。相对于开发阶段和用户的抱怨电话，在这个阶段修补缺陷是便宜的，编写质量需求的方针

编写优秀的需求是没有公式化的方法的。这需要大量的经验，要从你在过去的文档中发现的问题学习。请在组织软件需求文档时，严格遵从这些方针。

句子和段落要短。采用主动语气。使用正确的语法，拼写，标点。使用术语，要保持一致性，并在术语表或数据字典中定义它们

要看需求是否被有效的定义，可以以开发人员的观点看看。在内心将“当你们做完了找我”这句加到文档尾部，看看能不能是你紧张起来。换句话说，你 是否需要SRS的编写者的额外解释帮助开发人员很好的理解需求，以便于设计和实现？如果是的话，在继续工作前，需求还需要细化。

需求编写者还要努力正确地把握细化程度。要避免包含多个需求的长的叙述段落。有帮助的提示是编写独立的可测试的需求。如果你认为一小部分测试可以验证一个需求的正确，那么它已经正确的细化了。如果你预想到多种不同类的测试，几个需求可能已挤到了一起，需要拆分开。

密切关注多个需求合成了单个需求。一个需求中的连接词“和”/“或”建议几个需求合并。不要在一个需求中使用“和”/“或”。

通篇文档细节上要保持一致。我曾看见过多个需求说明书前后不一致。如：“对于红色合法的颜色代码应是R”及“对于绿色合法的颜色代码应是G”就有可以以分散的需求分离开，而“产品应能对来自语音编辑指示做出反应”应作为一个子系统，不应作为单个的功能性需求。

避免在SRS中过多的申述需求。在多处包含相同的需求可以使文档更易于阅读，但也会给文档的维护增加困难。文档的多份文本要在同一时间内全部更新，避免不一致性。

如果你遵从了这些方针，你能够尽早地经常正式或非正式的审查需求，这些需求对于产品的构造，系统测试以及最后的客户满意，都会成为好的奠基石。并且要记住，没有高质量的需求，软件就象一盒巧克力，你永远不知道你会得到什么。

第三篇：如何编写高质量的“软件需求说明书”

如何编写高质量“软件需求说明书”

你的工程应该有个好的起点。一个小组要带领客户进入需求启发阶段而且你要写软件需求说明书。这份说明有些大，但客户会很重视，所以说明必须得到赞同。

现在你正在设计其中的一个特性，已经发现了需求的一些问题。你可以用多种不同的方式解释需求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秒？，甚者每10年显示一条新的状态信息也可以？也许它的意图是消息间隔不应超过60秒，那么1毫秒是不是太短？“每”这个词导致了不确定性。问题的后果，就是需求的不可证实。

弥补缺陷，重写需求的一种方法：

1、状态信息

1．1后台任务管理器因该以误差上下不超过10秒的60秒间隔，在用户界面的指定位置显示状态信息

1．2如果后台进程处理正常，那么应该显示任务已完成的百分数/比

1．3任务完成时，应显示相关的信息

1．4后台任务出错应该显示错误信息

为了分别测试和追踪，我将其分成了多个需求。如果将几个需求串接在一节中，在构造和测试时就很容易漏掉一个。

例2．“产品应瞬间在显示和隐藏不可打印字符间切换”

计算机在瞬间不能做任何事，所以这个需求不切实可行。它的不完整性表现在没有声明触发状态切换的条件。软件要在某些条件下更改自己？或者用户为了模仿更改要做一些动作？而且，在文档中改变显示的范围是多大：选中的文本，整个的文档，或其他的？这也是个模糊的问题。不可打印字符合隐藏字符一样吗？或者是一些属性标志或一些控制字符？问题的后果，就是需求的不可证实。

象这样编写需求也许更好一些：“用户能够在一个由特定触发条件激活处于编辑的文档中在显示和隐藏所有HTML标记间切换”。现在就很清楚，不可打印字符是HTML标记。由于没有定义触发条件，需求对设计没有约束力。只有设计人员选定了触发条件后，你才能编写测试验证触发的正确操作。

例3．“HTML分析器可以产生HTML标记错误报告，帮助HTML入门者快速解决错误”。单词“快速”使其模糊，没

有加进错误报告的定义也是其部完整。我不知道，你怎么验证这个需求。找一个自称为HTML的入门者，看看能不能根据错误报告快速解决错误？

试试这个：“HTML分析器可以产生一个错误报告，错误报告包含有在被分析文件中出错的HTML文本和行号以及错误的描述。如果没有错误，就不会产生错误报告”。现在我们知道了，什么会被加到出错报告中，但是出错报告是个什么样子，则留由设计人员决定。我们还指定了一个例外：如果没有发现错误，不产生错误报告。

例4．“如果可能，主管号码应通过联机校验，而不是通过主全体主管号码列表校验”。真感到绝望，什么是“如果可能”：如果技术上可行？如果主全体主管号码列表可以联机获得？要避免象“应该”的这类不确切的词。客户是需要这个功能性还是不需要。我曾看过一些需求说明书，采用诸如：应，将，应该/将要等一些词描述优先级的细微差别。但我更喜欢用“应”清楚的说明需求的意图，指明优先级。这是修改后的：系统应校验输入的主管号码而不通过联机的主全体主官号码列表。如果在列表中没有发现主管号码，将会显示一条错误信息，也不接受指令。

在理解各个已完成的糟糕需求上，开发人员将会遇到的难题是：开发人员与客户将会在审核需求，未达成共识前发生激烈的争论。详细检查大的需求文档不是一件轻松的事情。我清楚有人做过，而且他们花在检查上的每一分钟都是值得的。相对于开发阶段和用户的抱怨电话，在这个阶段修补缺陷是便宜的，编写质量需求的方针

编写优秀的需求是没有公式化的方法的。这需要大量的经验，要从你在过去的文档中发现的问题学习。请在组织软件需求文档时，严格遵从这些方针。

句子和段落要短。采用主动语气。使用正确的语法，拼写，标点。使用术语，要保持一致性，并在术语表或数据字典中定义它们

要看需求是否被有效的定义，可以以开发人员的观点看看。在内心将“当你们做完了找我”这句加到文档尾部，看看能不能是你紧张起来。换句话说，你是否需要SRS的编写者的额外解释帮助开发人员很好的理解需求，以便于设计和实现？如果是的话，在继续工作前，需求还需要细化。

需求编写者还要努力正确地把握细化程度。要避免包含多个需求的长的叙述段落。有帮助的提示是编写独立的可测试的需求。如果你认为一小部分测试可以验证一个需求的正确，那么它已经正确的细化了。如果你预想到多种不同类的测试，几个需求可能已挤到了一起，需要拆分开。

密切关注多个需求合成了单个需求。一个需求中的连接词“和”/“或”建议几个需求合并。不要在一个需求中使用“和”/“或”。

通篇文档细节上要保持一致。我曾看见过多个需求说明书前后不一致。如：“对于红色合法的颜色代码应是R”及“对于绿色合法的颜色代码应是G”就有可以以分散的需求分离开，而“产品应能对来自语音编辑指示做出反应”应作为一个子系统，不应作为单个的功能性需求。

避免在SRS中过多的申述需求。在多处包含相同的需求可以使文档更易于阅读，但也会给文档的维护增加困难。文档的多份文本要在同一时间内全部更新，避免不一致性。

如果你遵从了这些方针，你能够尽早地经常正式或非正式的审查需求，这些需求对于产品的构造，系统测试以及最后的客户满意，都会成为好的奠基石。并且要记住，没有高质量的需求，软件就象一盒巧克力，你永远不知道你会得到什么。

第四篇：如何撰写高质量论文

如何撰写高质量论文

一看论文的选题是否有创新

所谓选题，就是要确定文章的主题，明确文章要写些什么，要阐述什么思想观点。古人说，“意在笔先”，也就是说，只有确定好了主题。才好动笔。还有人说，“确定一个好的主题，等于完成论文工作的一半”。因此，确定论文主题是撰写论文的第一要务。

那么，怎样才能选好主题呢?最关键的就是主题要有新意。创新是文章的灵魂，论文的好坏就取决于此。我们评价一篇文章有没有价值，就看这篇文章有没有新意。“文贵出新”，这是最根本的要求：那么，什么是“新”呢?主要表现为新的思想、新的见解、新的视角。一是观念要新。就是说，文章写作的指导思想要正确，要符合新的教育思想和教育观念。如果你文章讲的仍然是旧的观念、旧的培养模式、旧的教学方法，那就不行了。比如，我们对教学观的探讨，就经历了一个从“知识本位”到“能力本位”，再到现在的“以人为本”的过程。现在，你写文章讲教学观，就要讲以人为本，以学生为本，千万不要讲以知识为本位。二是角度要新。就是说，论文选题的角度要别具一格。“一树梅花万首诗”，“横看成岭侧成峰，远近高低各不同”，讲的就是观察事物的新视角。选题同样有个角度问题、找切入点的问题。同样的问题，同样的材料，不同人来选就有不同的感受、不同的主题。因为他们看问题的角度不同。我们在选题时必须坚持：“老问题要有新角度，常规的东西要有特色。”如《融“逗”于数学教学中》一文，通过相声能逗大家乐这二现象启示，把相声“逗”的艺术应用到数学教学中，来激发和保持学生的学习兴趣，作者选题的角度就比较独特。又如《在数学教学中如何培养学生的阅读能力》、《浅谈在课堂教学中合作技能的培养》，选题也比较好，很有新意。

在选题时，中小学教师要注意两个问题．一是陈旧雷同，二是贪大求全。选题陈旧雷同和贪大求全都有悖创新，写出来的论文也谈不上有什么价值，论文题目小，观点集中，以小见大，就容易做到厚积而薄发。题目小的对立面就是大而空，贪大求全。如《素质教育浅谈》、《素质教育中的数学教育》、《职业教育之管见》、《谈语文教育中的思想教育》、《浅谈创新教育》等。这些题目的概念外延都很大、很全，尽管有的在“谈”前冠以“浅”字，或者缀以“之管见”，但那都是客套话。关键是贪的面大，要谈的问题根本没谈清楚。在实际中，初学写作的人比较喜欢用全景式、统览式、鸟瞰式的题目来写文章，这些文章可能涵盖的内容多，比较容易写。殊不知，有不少这类文章，因为没谈清楚而被编辑“枪毙”。

二看论文的题目是否恰当

题目是什么?《说文解字》中是这样解释的：“题”，就是额头，“目”，就是眼睛。人们常说，器宇轩昂、眉目清秀是帅哥靓女的“题目”，给人留下的印象是潇洒和漂亮。文章的题目亦然。如果第一眼见你的文章题目不行，那就完蛋了。如《抓关键，提质量》一文，明显缺少一个副标题，一看题目，不明白文章的主题到底是什么。

“文章要好，题目要巧”。有的文章题目好，令人拍案叫绝，过目不忘，甚至终生难忘。例如，马克思的《哲学的贫困》、《路易.波拿巴十八日》，恩格斯的《反杜林论》、《社会主义从空想到科学的发展》，列宁的《宁肯少些，但要好些》、《进一步，退两步》，毛泽东的《星星之火，可以燎原》、《反对本本主义》、《别了，司徒雷登》，邓小平的《两个“凡是”不符合马克思主义》、《尊重知识，尊重人才》、《科学技术是第一生产力》，江泽民的《创新是民族进步的灵魂》、《面向新世纪的中国共产党》等等，都是十分好的题目。有些理论家、学者的文章题目也起得非常好，如胡乔木的《西藏的革命和尼赫鲁的哲学》、《中国共产党怎样发展了马克思主义》，胡绳的《马克思主义是发展的理论》，郭沫若的《甲申三百年祭》、《科学的春天》等等，堪称题目的典范。至于鲁迅先生，更是文章高手，他的文和题，极具创造力和个性，诸如《一件小事》、《辱骂与恐吓决不是战斗》、《战士与苍蝇》、《中国人失掉了自信心了吗?》、《骂杀和捧杀》、《老调子已经唱完》等等，清新隽永，回味无穷。

那么，怎样的题目才算好呢?有三点是共识的：第一，贴切、醒目、生动，不能太平淡；第二，题目要小一些、短一些、简洁-些，题目不能太长，不要超过20个字。第三，要有爪．1生，切忌似曾相识，人云亦云。总的来说，文章的题目要令人耳目一新。如，《融“逗”于数学教学中》、《课堂导语的设计》、《班主任的“糊涂艺术”》等，就是很好的题目。

三看论文的观点是否有吸引力

在中小学教师撰写的论文中，很多观点都是照搬有关杂志上文章的观点，没有自己的体会和特色。也就是说，观点一般化，没有吸引力。如《让学生主动参与学习，真正成为学习主人》一文，写了四个观点：创造情境；动手操作；质疑问难；交流讨论。主题很好，但观点缺乏新意，太一般化了。又如《在创新中求发展----对小学数学课堂教学的几点探讨》一文，讲了四个观点：改进课堂教学结构；改革课堂教学方法；改进课堂教学的组织形式；突出学生的主体作用，优化课堂练习过程。观点覆盖面太大，每一个观点都可以写一篇大文章。又如《浅谈数学课堂教学与素质教育》一文，讲了5个观点：素质教育的主体性；素质教育的发展性；素质教育的差异性；素质教育的创造性；素质教育的渗透性。虽然作者结合教学实践谈了素质教育的“五性”，但以这“五性”为二级标题，就不贴切，针对性和吸引力都不强。

一篇优秀的教学论文，它的观点应该语言精练，紧扣中心，并且能准确地概括自己所写的内容。有一位同志写了一篇《写字教学断想》的文章，这篇文章总共谈了三个观点。原先的三个观点是：1．重视教师的写字基本功；2．平时写字也要有练字意识；3．抓好“一寸”是关键。这三个观点概括每段的内容本来是准确的，但他觉得比较一般化，不能给人留下深刻的印象。于是，他反复琢磨，作出了如下修改：1．打铁还得自身硬；2．提笔即是练字时；3．牵牛要牵牛鼻子。意思还是那个意思，但用的是熟语。熟语大家经常说，生动形象，表现力强，读者看一篇就记住了，表达的效果就不一样。

四看论文是否有自己的感受

写论文要有自己的感受和个性，千万不要盲目地照搬照抄。教学论文如果写得实在，让人读后就会感到所举例子来自自己的教学实践，不虚假且操作性强。这样的文章，读者读起来才有亲切之感，才会津津有味，永读不厌。因此，教学论文的“实”主要体现在实践性和应用性上。如有篇《感受古诗语言的精练与优美》的论文，讲了五点：一是比较辨析，感受语文的精确性；二是品味推敲，学习语言的精练性；三是拓展描述，体悟语言的丰富性；四是朗读背诵，体会语言的音韵美；五是角色表演，体会语言的情感性。文章从五个方面来论述古诗语言的精练与优美，一看感受就很实在，又让人知道怎样操作。每一点下面又都有具体例子，一点也不空洞。这是一篇既有实践性，又有应用性的好论文。

每年中小学教育教学优秀论文的评选，发现不少论文纯粹是定义、概念、观点加上一些例子的简单组合，缺乏自己的分析、综合、提炼、推理，看不出到底是作者本人的感受，还是别人的感受，不能给人以深刻的印象。有的论文引用经典和名言过多，缺乏自己的见解和分析。诚然，恰当地引用经典和名言能给文章起到画龙点睛的作用。但引用要恰到好处，适可而止，如果过多过滥，则适得其反。一篇教学论文真正能打动读者、启迪读者的，往往并不一定是经典和名言的力量，而是论文作者对教学领域中某些方面、某些问题深邃而独到的见解和缜密精辟的分析。因此，教学论文要反映对教育或教学现象的一些真实认识和感受。只有认识深刻，感受才能新颖；是自己的感受，才能有个性，才能给人以新知。

五看论文的思路是否清晰，结构是否严谨

许多中小学教师的论文存在论述欠完整，层次不清，思路混乱，缺乏逻辑性的现象。这是撰写教学论文最忌讳的。要克服这一毛病，写论文时就必须重视布局谋篇。所谓布局谋篇。就是筹划采用怎样的结构，选择哪些材料，才能有效地表达主题。布局谋篇，是写好文章的一个重要问题，是必不可少的一个准备过程。如果说一篇文章的主题犹如人之“灵魂”，一篇文章的材料好比人之“血肉”，那么一篇文章的结构，正恰似人之“骨骼”。没有灵魂只能是一个躯壳；没有血肉就只剩了一个空架子；而没有坚实、健壮的骨骼，血肉就无所依附，灵魂也无处寄托。因此，布局谋篇这个工作做好了，就会思路畅通，顺理成章．否则，心中无数，边想边写，就难以写好文章。

第五篇：招标需求说明书

竞争性谈判-需求说明书

（参考）

行政部：

为配合**开业庆典活动筹备安排，特向贵部提出庆典活动项目招标（竞争性谈判）需求，具体说明如下：

一、招标（竞争性谈判）内容：

**开业庆典系列活动项目承办单位招标（竞争性谈判）。

二、招标（竞争性谈判）项目的基本需求：

（一）活动整体安排：

根据改制工作进度安排，**拟于2009年**月中下旬获批成立，并拟于**月**日举行开业仪式庆典活动，活动内容拟包括：

1、开业庆典仪式：

（1）时间安排：**月**日上午（时长约为1小时）。

（2）地点安排：**大厦东广场

（3）出席人数：拟邀请省、市各级领导和重要嘉宾合计约250人。

（4）主要流程：A、省、监管单位、市、农商行领导分别致辞。

B、主要领导共同揭牌仪式。

C、**公益捐赠仪式。

2、开业庆典晚宴：

（1）时间安排：**月**日晚上（时长约为2小时）。

共 5 页·第 1 页

（2）地点安排：拟于**香格里拉大酒店（**厅）或**路**酒店（国际宴会厅）。

（3）出席人数：拟邀请省、市各级领导和重要嘉宾合计约500人。

（4）主要流程：A、省、市领导致辞。

B、主要领导祝酒仪式。

C、表演助兴（如歌舞、魔术、杂技等）及现

场抽奖环节。

（二）承办工作要求：

1、本次庆典活动项目执行工作中的客户邀请、礼品购置、宴席餐饮、媒体投放等均由我单位另行安排，承办单位提交的投标方案内容应包括：

（1）对活动整体流程的策划，并提供相应的策划方案书、时间进度和分工安排表等书面材料。

（2）对会场宣传布置的构思，要求宣传布置范围以**大厦为中心、辐射周边1000米内主要路段，包括各项平面设计、物料设计、舞台设计等，并提供相应的平面设计稿、三维效果图、物料清单等。

（3）对节目和演员的建议，包括歌舞、杂技、魔术等，并提供相应的节目和演员情况介绍、费用报价等；中标后可根据我单位实际要求进行调整变更，并负责具体联系邀请和彩排协调等工作。

（4）对司仪和导演的推荐，包括开业仪式司仪1人、晚宴司

仪2人、晚宴导演1人，并提供相应的个人介绍材料、费用报价等；中标后可根据我单位实际要求进行调整变更，并负责具体联系邀请和彩排协调等工作。

（5）对公益捐赠举措的建议，包括与国内外知名慈善机构、官方组织等的捐赠合作，提供相关机构情况、捐赠模式等情况介绍，中标后协助我单位联系沟通。

（6）对活动执行协调措施的说明，包括户外活动可能涉及的消防、环保、治安等公共安全问题，及施工质量、效率和安全性问题，提供相关解决措施说明；中标后需负责执行消防、城管、环保、公安等相关申报程序。

（7）除上述内容外，对我单位临时补充要求的回复。

2、针对上述要求，我单位制定了“宣传策划基本要求说明”（见本需求附件1），各投标单位须以此基本要求说明为基础制定整体活动方案，并在投标方案中对开业庆典仪式和开业庆典晚会分别进行报价（含税），报价表应列明估算的相关尺寸、数量、材质等内容，各项报价应合理、真实、具备可操作性。

3、中标单位须适应我单位内部的法律文书审核和财务报批支付等流程规定，并统一提供中标公司发票。本次庆典活动项目费用将按30%预付、30%二期、40%尾款方式分三次支付，其中预付款于合同签定后五个工作日内支付，二期款于实施当天前五个工作日内支付，尾款将于活动结束后十个工作日内结清。

（三）投标公司资质要求：

1、投标单位应为国内综合实力较强、行业信誉较好的公关策划/品牌传播/广告制作公司，注册资本需折合人民币200万元（含）以上，登记在职员工30人（含）以上；

2、投标单位应具备成熟完善的分工架构和服务流程，自有专职策划及客服人员5人以上、高级设计人员5人以上、专业工程人员10人以上，有曾为三家以上国内知名大型企业策划执行各类大型庆典活动的成功案例。自设大型制作工厂或具备国内4A评级（含）以上的广告公司将优先考虑；

3、投标单位主要办公场所应在本市区范围内。

4、投标单位应根据上述要求提供相关证明文件、文字和图片介绍资料。

三、招标建议：

1、每一投标单位必须同时承办开业庆典仪式和开业庆典晚会两项活动；

2、中标单位数量：壹个。

3、建议评标方式：投票法。由我单位开业庆典活动领导小组组成评委会，根据投标单位的综合实力、策划创意、整体报价等，投票选出中标候选单位，报单位领导审批确定后公布。

4、我单位可根据实际需要对“宣传策划基本要求说明”的项目内容进行增减。

5、投标单位须提交资料包括：

（1）开业庆典活动整体策划方案（含报价）；

（2）投标单位相关资质证明文件、文字和图片介绍资料；

（3）我单位要求的其他资料。

6、考虑到庆典活动筹备时间较紧，建议本次招标（竞争性谈判）流程于**月**日前完成并公布结果。

附件：**庆典活动宣传策划基本要求说明

**办公室年月日