06软件需求之编写需求规格说明

软件需求之编写需求规格说明XXXX公司XXXX年XX月XX日目录1.需求编写过程说明 22需求规格说明书模板 63项目驱动与问题描述 83.1目目标 83.2客户、顾客和其它利益相关方 103.3产品的用户 104产品限制条件的确定 114.1强制的限制条件 114.2命名惯例和定义 124.3相关事实和假定 125.功能性和非功能性需求的描述 125.1工作的范围 135.2产品的范围 135.3功能性需求和数据需求 135.4非功能性需求 146.阐述项目问题 156.1开放式问题 156.2立即可用的解决方案 156.3新问题 156.4任务 167需求文档编写的若干建议 167.1产品需求规格说明书参考模板 167.2善于书写良好的文档 23现在到了出成果的时候。我们必须以文档的形式编写完整的软件需求规格说明（SoftwareRequirementsSpecification，SRS）。这个规格说明将作为开发、测试以及客户验收的依据。本章将沿着如下图所示思路逐渐展开。1.需求编写过程说明由于需求编写内容繁多，牵涉到大量的人力物力，在很多情况下是多人共同编写。因此需要定义一个完整需求编写过程，以保证多人共同编写的时候相互协调和一致。1.1为什么要研究需求说明书的编写1）需求是指的从业务的观点把产品的描述放在一起编写需求是指的从业务的观点把产品的描述放在一起的任务，通常这种描述被称之为规格说明。经典项目过程编写需求规格说明是必需的。即使在敏捷模型下，如果是大型多维度小组开发，也需要写出整体框架上的一级子系统的需求规格说明。所以，研究规范性的需求规格说明的编写方式十分重要。2）在发现需求的时候可能已经完成了大部分编写需求的工作编写需求其实不是一项单独的活动，而是在需求获取和制作原型的活动中，在发现需求的时候就完成了大部分编写需求的工作，但是在前面的章节中，更多的是讨论相应活动的思维方式，是讨论这个活动的本身，这里作为一章来表述的原因在于，需要专门来讨论需求编写的一些问题。3）我们需要研究如何书写需求现在是出成果的时候了，我们需要把所有需求活动中收集的材料，以一种条理性、规范性的方式书写出来，形成在软件开发中最重的一个文档：软件规格说明书（SRS）。需求过程是包含了所有的问题定义、模型建立、需求收集以及对产品的思考。需求过程的成果全部落实到最后的规格说明当中。当然规格说明只是需求文档的一个而不是全部，在前面的过程中所有的工作文档，都是需求文档的内容之一。1.2需求编写过程需求编写过程如下图所示，对这个过程我们可以作简要描述，但是其中大部分细节已经在前面讨论过了。1）确定潜在需求（过程3.1）设置上下文范围并进行逻辑上的、相互关联的划分，得到的成果并不能发现全部的需求，许多单个的需求是通过对知识的网罗发现的。本过程分析潜在的需求，这些需求是通过网罗发现的，针对每项潜在需求：用“产品应该……”的格式写下一段描述，后面跟上产品必须执行的动作；用一个唯一的编号标识该需求；复查产品上下文范围，看看是否能确定与该需求有关的用例；记录下该需求的来源（最好是认得姓名）；记录下该需求的根本原因，问一个问题，为什么该需求对业务来说是重要的？本章会继续讨论编写需求的更多细节。2）确定功能性需求（过程3.2）如果用例很大，或者很复杂，或者不熟悉，直接从用例跳到需求是困难的。在这种情况下，用例的步骤提供了迈向需求的垫脚石，从参与者的视角来编写场景，既列出所有步骤清单，这些步骤是产品为了完成用例定义的工作必须执行的。针对每一个用例步骤，通过将每个用例步骤分解为可测试的一句话说明来发现功能性需求。问一下为了完成这一步工作，产品必须做什么，下面是一些有帮助的问题：该产品必须接收怎样的数据？该产品必须产生怎样的数据？产品必须记录怎样的数据？产品必须做怎样的检查？产品必须做怎样的判断？产品必须做怎样的计算？上述每个问题都可能产生一个功能性需求，针对每项需求：用“产品应该……”的格式写下一段描述，后面跟上产品必须执行的动作。用一个唯一的编号标识该需求。附上该需求的用例号。记录下该需求的来源（最好用人名）。记录下该需求的理由，问一个问题，为什么该需求对业务来说是重要的？在上一章，我们已经对功能性需求问题作了足够详细的讨论。3）确定组合需求（过程3.3）一项组合需求（也称之为“高层需求”）没有自己的可测试的验收标准，而是一组其它的单独可测试的需求的“小结”。对于讨论一组单独的可测试需求的组合效果，组合需求是一种有用的方式。有时候，一项组合需求意味存在模糊或者不确定的地方。对每个用例有意向高层次需求是很有用的，这样就可以在用力这一层对需求进行总结，同时又保持组成该用例的可测试需求之间的联系。当确定一项组合需求的时候，应该确保这样做有足够的理由，而不只是把这种泛泛而谈作为一种逃避的理由。4）把需求规范化（过程3.4）根据需求模板中的需求项框架，针对每项需求，用这个需求项框架作为指导，把需求规范化。5）把系统限制条件规范化（过程3.5）根据需求模板中的需求项框架，针对产品目标和项目限制条件，每项需求，用这个需求项框架作为指导，把系统限制条件规范化。6）确定非功能性需求（过程3.6）可以把功能性需求作为帮助发现非功能性需求的触发器，发现的过程如下：1，针对每个用例A，针对每项功能性需求1）针对需求模板中列出的每种类型的非功能性需求a．是否存在一个或者多个非功能性需求来支持该功能性需求也可以使用站在更高层次的方法，通过比较用例与每种非功能性需求，来寻找非功能性需求。7）编写功能性验收标准（过程3.7）这个过程的目标是根据一项需求，运用工作知识，得到功能性需求的验收标准，这个标准必须是无二义性的，这样就可以把对需求的解决方案归结为两类：“满足需求”和“不满足需求”。我们已经讨论了关于验收标准的有关问题，它采取如下形式：指定取得的数据将与输入数据相符；指定检查过的数据将与检查规则相符；计算的结果将与指定的算法相符；指定记录的数据将与指定取得的数据相符。也就是说，如果术语已经有了无二义性的定义，它将作为功能性需求验收标准定义的一个部分。也可以考虑编写测试用例，作为功能性需求验收标准的一部分。8）编写非功能性验收标准（过程3.8）这个过程的目标是根据一项需求，运用工作知识，得到非功能性需求的验收标准，这个标准必须是无二义性的，这样就可以把对需求的解决方案归结为两类：“满足需求”和“不满足需求”。我们已经讨论了非功能性需求验收标准的有关问题，它采取如下形式：判断正在处理哪种类型的需求；它真是一项需求吗？如果需求被错误的表述为解决方案，就需要询问利益相关方，真正的需求到底是什么，真正的需求是独立于解决方案的。如果需求是以某种可以触摸到、看到、闻到或者听到的方式提出的，那么就比较容易发现一个客观的度量标准。如果一个名词不是可以触摸到、看到、闻到或者听到的东西，那它就是一个名词化的词。当一个动词用于描述一个正在执行的过程时，就变成了一个名词。假设遇到了这样一项需求：维护必须可靠。“维护”就是一个名词化的词。可以通过界定它的意义来阐明它。把名词化的词还原成动词，并且问一下：“谁”把“什么”名词化了？他们将“怎样”做到这一点？这个技巧有助于确定需求的真正意义，从而定义一个合适的验收标准。某些需求是模糊的名词化的词，因为没有人知道他们的意义或者意图究竟是什么。9）确定顾客价值（过程3.9）要求顾客从两个角度来看需求，以此来确定顾客价值：顾客满意度：如果我给您的解决方案满足了需求的验收标准，您会有多高兴？（5分制打分）。顾客不满意度：如果我给您的解决方案不能满足需求的验收标准，您会有多不高兴？（5分制打分）。我们的目的，是理解顾客真正的优先级，并引导顾客说出对他们来谁真正最重要的事情。这样我们就可以用一个合理的依据来判断如何选择/何时需要实现哪些需求。当有几组不同的顾客，他们的优先级各不相同时，也运用相同的过程，我们的目标是记录下不同的优先级，然后可以做合理的选择和折衷。10）确定依赖关系和冲突之处（过程3.10）不论何时，当一个需求与另一个需求有冲突的时候，都应该把冲突之处记录下来。如果两项需求不能同时实现，或者说实现一项需求会妨碍另一项需求的实现的时候，就发生了冲突。解决冲突的第一步是认识到冲突的存在，并且分别从“引发”冲突的需求的人的角度来考虑问题。在这个阶段，可能不会发现所有的冲突，在这以后，在复查需求规格说明书的时候，会对冲突之处作更正式的检查。2需求规格说明书模板需求分析师需要一份编写需求的指南，这样就会更容易，更方便，这就需要一个模版。需求规格说明书模板就像一个容纳需求的容器，通过检查需求文档，把需求分成类型，这有利于我们识别和提取需求。每个类型在模板中占据一部分，它一共包含了5个大的部分内容。在研究前面章节的时候，如果仔细浏览这个模版，就会发现关于编写需求的许多内容，以及收集各种需求的一些思考方向，典型的需求规格说明模版如下：项目驱动：描述项目的理由与动机。1，项目的目标：投资创建产品的理由以及希望取得的业务上的好处。2，客户、顾客和其它利益相关方：产品涉及他们的利益以及对他们的影响。3，产品的用户：预期的最终用户，以及他们对产品可用性的影响。项目限制条件：加在项目和产品上的约束条件。4，需求限制条件：项目的局限性和产品设计的约束条件。5，命名标准和定义：项目的词汇表。6，相关事实和假定：对产品产生一定影响的外部因素。功能性需求：产品的功能。7，工作的范围：针对的业务领域。8，产品的范围：定义预期产生的边界。9，功能与数据需求：产品必需作的事情以及所操作的数据。非功能性需求：产品的品质。10，观感需求：预期的外观。11，易用性和人性化需求：产品让预期用户使用应该是什么样子的。12，执行需求：速度、大小、精度、人身安全、可靠性、健壮性、可伸缩性、持久性和容量等需求。13，操作和环境需求：产品预期的操作环境。14，可维护性和支持需求：产品的可改动性必须达到什么水平，以及需要什么样的支持。15，安全性需求：产品的信息安全、保密性和完整性。16，文化与政策需求：人和社会因素。17，法律需求：满足适用的法律。项目问题：这些是适用于构建产品的项目。18，开放式问题：那些尚未解决的问题，可能对项目的成功有影响。19，立即可用的解决方案：利用已有的组件，而不是重新开发。20，新问题：引入新产品而带来的问题。21，任务：把产品投入使用必须要做的事情。22，迁移：从现有系统转换的任务。23，风险：项目最有可能面对的风险。24，费用：早期对构建产品的成本或者工作量的估计。25，用户文档：创建用户指南或者文档的计划。26，后续版本需求：可能在产品将来发行版本中包括的需求。27，解决方案的想法：我们不想错失的设计想法。下面我们对书写规格说明书的各个方面，比如需要注意的问题、思考问题的重点、一些容易混淆的问题等加以说明。3项目驱动与问题描述项目的目标和问题描述是需求文档的第一部分，这是对产品整体方向和价值的描述，必须认真对待。3.1目目标这部分描述的是客户希望构造一个新产品的原因，也就是说描述客户所面对的业务问题，并解释产品将如何解决问题。1，用户的业务或项目工作的背景这里需要描述用户所作的工作，以及为什么他没有像期望的那样顺利进行，一定存在某些重要的改进机会，否则不会要求开发一个新产品。这段描述可能非常简要，比如：道路管理部门对由于结冰引发的道路事故数量不满。也可能完整描述操作上的问题，常常对严重问题作了最多的陈述，以及目标产品要解决的主要问题，比如：道路冬天结冰引发交通事故，我们需要预测和市道路可能结冰，然后我们的车库可以及时调度除冰卡车来防止道路结冰。除了气象预报以外，我们还希望使用地区的热象图以及设置在公路上的气象站发出的道路温度数据。我们希望新的系统能够发出更精确的冰清预报，使我们比现在更及时地进行除冰，从而减少交通事故。我们也希望能不加选择的化学除冰，因为那样会浪费除冰化合物，同时也污染环境。也可能并没有什么问题，但是有一个重要的商业机会，客户希望抓住它，在这种情况下，可以对该商业机会进行描述，比如：道路除冰情况对许多国家都是一个问题，目前没有准确的预报办法，道路除冰的处理方式极不科学，极为随意。如果我们能开发一个准确冰情预报和处理调度的产品，将会有很大的市场。我们的市场部门已经找到了25个国家愿意立即购买这样的产品。或者，产品的目标是做一些探索或者可行性调查，在这样的情况下，项目的提交产物不是新产品，而是一份文档，指出一项产品的需求可能或者不可能满足，比如：冰情预报和卡车调度过去一直是有不同的实体完成，如果把冰情预报和卡车调度结合在一起，我们预计调度工作会有效的多。通过共享策略和优化策略，这两项活动都会受益。我们希望调查是否存在为我们组织开发一个新产品的机会。2，项目目标这部分描述我们想做的事情，或者产品将对工作的总体目标做什么贡献。不要让这部分篇幅过长（对产品目标作简要解释，比作长而且离题的论述要有价值）。一个短的、明显的目标，会使利益相关方更清楚，因此也就更可能在目标上取得一致意见。比如：通过精确预报结冰道路的除冰工作来减少交通事故。如果目标是有价值的，就需要表达它所提供的利益，一般说有3种利益：在市场上的价值。减少运作成本。增加客户价值或服务。好处必须是可度量的，否则就不能认为是一个有价值的目标，下面的写法只能认为是一个胡言乱语：需要一个分布式的、以质量为中心的、委托式的群体协调机制和分阶段的、动态的联盟监视解决方案。一般来说，建议是用我们已经讨论过的PAM（目标、好处、度量标准）来描述，例如：目标：精确预报道路结冰时间并分排除冰卡车。好处：通过预报道路结冰情况来减少道路事故。度量标准：因结冰而发生的事故数将低于冬季发生的事故总数的15%。目标：在冬季道路养护支出上节省费用。好处：减少除冰道路养护的费用。度量标准：除冰费用将在目前道路养护费用的基础上降低25%，冰对道路的损伤将降低50%。这些度量是可测试的，它提供了一种指导，帮助项目团队把注意力集中在对目标有最大贡献的需求上。项目目标是一个整体目标，而不是每个需求的罗列。目标是在项目启动阶段确定的，必须保证目标是合理的，可以达到的，表述简单的，有价值的，并且有度量目标，就可以对提交的产品进行测试，以确保它满足了目标。如果目标没有这些属性，那么历史已经告诉了我们，该项目不大可能提交任何有用的东西。3.2客户、顾客和其它利益相关方这部分描述利益相关方，利益相关方包括客户、用户、业务或需求分析员（负责收集客户需求并编写文档，以及负责客户与开发机构之间联系沟通的人）、开发人员、测试人员、用户文档编写者、项目管理者和客户管理者。也就是说，利益相关方是在产品中有利益关系的人，画一些时间来准确确定并且描述这些人是值得的，因为不知道他们是谁，所带来的惩罚将会很严厉。每个利益相关方都对产品有要求，他们都是需求的来源，如果没有找到所有的利益相关方，就有可能不能找到所有的需求。只要有可能，就给出利益相关方的名字和联系方式。3.3产品的用户产品用户是直接与产品交互的人，他们尽管是一种特殊类型的利益相关方，但由于他们在需求收集工作中的特殊重要性，我们在模板中引入单独的一节来描述。在网罗活动中确定了产品边界以后，用户是谁就清楚了，在需求规格说明的这一部分，需要说明他们的特征，他们的习惯和思维方式，对产品最后的表现有很大的影响。功能需求源自于研究用户的工作，所以重要的是正确的确定用户当前实际在做的工作。用户故事得越好，就越容易确定易用性需求（易用性对不同背景的人是不一样的）。记得要包括用户的任何不寻常的特征，他们是在发怒？还是在赶时间？在行走中？还是只用一只手（比如侍者）。规格说明书的这一部分详细记录对用户的了解，在需求过程中利用这部分的工作来确定与这些特定用户相关的需求。4产品限制条件的确定产品限制条件放在第二部分的原因，是因为这约束了所有问题的展开，也是至关重要的部分。4.1强制的限制条件限制条件是全局的需求，它是适用于整个产品的一些因素。产品必须在列出的限制条件下构建，有些限制条件是管理层确定的，这就需要认真考虑，它们限制了需求分析师可以做的事情，为产品定了型。限制条件包括以下几个方面：1）解决方案限制条件这是一些设计决定，例如产品必须使用某种语言，必须运行在某种计算机上，或者必须与原来的产品兼容。另外，如果使用某些商业或者开源的软件产品，它们必须正确的交互。尽管我们不希望分析阶段包含任何设计，但忽略这些组织上的指令是不现实的，从组织的观点看也是不可接受的。我们必须提醒检查所有的限制条件的动机，研究强调某种技术是带来了真实的好处吗？这类解决方案有真实的业务需要吗？是否仅仅为了描述业务，却给出了一些常见的解决方案呢？2）当前系统的实现环境有时候，限制条件反映出管理层不愿意购买一些新的硬件。比如，产品必须运行在现有的服务器上，因此，需求就不能给出一个需要不一样的计算能力才能实现的产品。3）伙伴应用或者协作应用几乎所有的软件项目都会不同程度的于其它产品交互，这些产品可能在组织内部，也可能在组织外部，本节告诉开发者，这些需要交互的产品是什么？并解释为什么他们被看作当前产品的伙伴应用。4）立即可用的软件指定采购的软件，有些产品提供的功能几乎可以满足某个领域的一切要求，通常利用这样的产品是有意义的。这里必须描述打算采用哪些采购的软件，可能还会指定相应的接口和特殊功能，不过，我们发现把这些功能和其它功能需求放在一起可能会更清楚一些。5）预期工作场地环境描述工作场地，不过只有工作场地对产品需求有影响的时候才包含这部分内容。6）时间进度限制条件指定构建产品允许的时间，这个时间会约束项目团队需求收集的时间，让需求的内容允许产品在规定的时间内构建出来。7）预算限制条件本节描述项目可用的资源（资金、人员、工作量）。目的是约束人们万丈的雄心，防止项目团队用只够一个小的项目资金预算，去收集一个庞大项目的需求。4.2命名惯例和定义建立命名惯例的字典，说明一些关键名词的含义。在需求规格说明中使用的名称应该是通常的业务名称，避免名称上的二义性甚至发生误导的名称。4.3相关事实和假定相关事实是一些外部因素，它们对产品产生影响，但不属于规格说明书的其它部分。他们不一定会转化为需求，但提醒开发者的一些需求要考虑的情况和约束。但是，软件开发有时候需要一些假定，这些假定很可能是项目团队做出来的，目的是提醒管理层注意那些对产品有影响的因素。这些假定往往牵涉到产品的目标操作环境，也可能是其它的事情，但是如果假定没有成为事实，将对产品的成功产生有害的影响。通过指明这些假定，分析师需要向所有的利益相关方说明这些假定，判断这些假定是不是有事实依据，例如假定：处理过的道路至少在2小时内不需要重新处理。如果这个假定与事实不符，需要及早纠正。5.功能性和非功能性需求的描述产品功能性与非功能性需求是软件规格说明的主体，也是篇幅最大的部分。在很多情况下这一部分是多人共同书写，很容易造成前后文和上下文的不一致。这一部分的书写决定了规格说明的质量，是最需要下功夫的部分。5.1工作的范围首先要建立的范围是工作范围，它确定了要研究的业务领域的边界，并概要性的描述它与环境的关系。当理解了工作以及它的限制条件的时候，就可以建立起产品的范围。我们可以使用一个上下文模型来描述工作范围以及围绕工作的相邻系统。建立正确的工作范围对于产品的成功很关键，值得投入精力和时间来确保这个上下文范围对于理解客户的业务是足够的，客户的业务将从产品中受益，如果不这么做，得到满意产品的机会就降低了。工作的范围往往比较大，需要对工作进行划分，这种划分可以通过事件列表完成，每个业务事件应该包括：事件编号；事件名称；输入或者触发数据流；输出数据流；对事件响应/业务用例的一句话总结。如果已经构建了对业务用例的响应模型，可以把模型放在规格说明的这一部分，可以用附录的形式，附上适当的事件编号。5.2产品的范围1）产品边界可以用多种形式描述产品范围，但是一般模型比文字更容易理解。在上下文图中，中间部分是产品，相邻系统是参与者。2）产品用例清单如果存在大量用例，那么产品用例清单比直接在文档上写出用例要好管理些。5.3功能性需求和数据需求1）需求收集卡片我们前面提到过的需求收集卡片式是非常有意义的，一次性的找出一项需求的所有部分以后再找下一项的做法是不切合实际的，所以建议做一些小卡片，把需求框架打印在卡片上，在研究问题的时候，发现一项就快速的记录下来，随着对需求理解的加深，逐步地完成这些卡片。这种做法给我们带来很大的灵活性，是我们在利益相关方那里收集需求的时候不至于带来很大的障碍。我们可以根据它所属的用例进行分组，“事件/用例”编号便于在桌面上查找某张卡片。需求编号：需求类型：事件/用例编号：描述：理由：来源：验收标准：顾客满意度顾客不满意度冲突优先级：支持材料：历史：2）原子需求一个单项、完整、形式化的需求应该有如下的构成，由于有关问题前面谈得很多，这里就不再详细叙述了：1）需求编号；2）需求类型；3）事件/用例编号；4）描述；5）理由；6）来源：首次提出这个需求的人，或者需求可以归因于他，这样需求就有了参考点。7）验收标准；8）顾客满意度和不满意度；9）优先级；10）冲突；11）支持材料：有些材料对需求来说是重要的，可以简单的在此处引用。12）历史：这里记录需求首次提出的时间、更改日期、删除日期、通过质量关的日期。如果有帮助，也可以加上负责人的名字。5.4非功能性需求对于非功能性需求我们已经作了很详细的讨论，这里就不再重复阐述，主要的是非功能需求需要仔细研讨可度量的标准，因为非功能性需求大多属与质量需求有关，而且还牵涉到验收标准，必要的时候，需要聘请相关技术人员参与研究。6.阐述项目问题有一些问题可能会对项目产生影响，需要提醒利益相关方，就要在这一部分阐述。6.1开放式问题这一部分主要描述已经发现，但还没有解决的问题。例如，当需求获取的时候，一些问题浮出水面，但不能立刻有答案。又比如利益相关方可能不能确定有些事情将来会如何发展。例如：气象中心的数据库可行性研究还没有完成，这影响到气象数据的处理。要知道变化时刻都有可能发生，这些变化中的一部分肯定会影响到产品，开发式问题包括对预期变化点的预测，尽管结果不能确定，但这些预期对设计的影响很大。6.2立即可用的解决方案有时候会有一些现成的解决方案，但需要提醒客户构建产品与购买组件或使用开源代码的优劣分析，需要讨论3个方面的问题：是否有现成的产品，是否可以购买商业软件？现有的组件是否可以用于该产品？是否有一些我们可以复制的东西？针对每个问题，找出您觉得合适的替代方案，或者给出外购组件的原因。在这一部分，指出可能的费用、可得性、实现的时间以及其它可能影响决定的因素是有意义的。这里主要是提出将来的可选方式，而不是限制条件。6.3新问题改变原有的秩序可能会带来相反的结果，因此我们需要检查并指出安装新系统会带来的任何问题。例如，可能完成工作的方式发生改变，与现有系统的接口发生了改变，人们目前的工作习惯发生了改变等。我们并不需要描述一切方面，但也需要提醒客户他们可能面对的问题和机会。6.4任务为了交付产品，必须采用哪些步骤？本部分的意图是突出构建产品所需要的工作量，或者购买一个解决方案需要的步骤。不论计划采取何种途径把产品安装到用户的业务领域中去，都需要在需求阶段知道途径并且描述它。尽管组织有构建产品或者购买产品的标准方法，还是存在由产品需求导致的一些变化。管理层会利用这部分提供的信息来评估产品的可行性，考虑它所需的工作量和费用。7需求文档编写的若干建议需求文档是在前面所有工作的基础上编写的，如果没有这个基础和分析的结论，所编写的文档尽管格式良好但也一定的没有用处的。再一次提醒，文字是表达思想的，如果思想是匮乏的，那么再漂亮的格式都是没有用的。7.1产品需求规格说明书参考模板这里提供的产品规格说明书模板仅供参考。再重复一遍：好的文档在于思想深邃、善于表达、重点突出、逻辑清楚，而不仅仅是格式正确。在描述的时候要图文并茂，用图（例如UML）表达关系，用文字（例如场景）表达细节，问题之间的线索要清晰，层次要分明。这样书写出来的文档才可能真正发挥作用。{项目名称}产品需求规格说明书文件状态：[√]草稿[]正式发布[]正在修改文件标识：Company-Project-RD-PRS当前版本：X.Y作者：完成日期：Year-Month-Day版本历史版本/状态作者参与者起止日期备注0.文档介绍0.1文档目的0.2文档范围0.3读者对象0.4参考文档提示：列出本文档的所有参考文献（可以是非正式出版物），格式如下：[标识符]作者，文献名称，出版单位（或归属单位），日期0.5术语与缩写解释缩写、术语解释…1.产品介绍提示：（1）说明产品是什么，什么用途。（2）介绍产品的开发背景。2.产品面向的用户群体提示：（1）描述本产品面向的用户（客户、最终用户）的特征，（2）说明本产品将给他们带来什么好处？他们选择本产品的可能性有多大？3.产品应当遵循的标准或规范提示：阐述本产品应当遵循什么标准、规范或业务规则（BusinessRules），违反标准、规范或业务规则的产品通常不太可能被接受。4.产品范围提示：阐述本产品“适用的领域”和“不适用的领域”，本产品“应当包含的内容”和“不包含的内容”。说清楚产品范围的好处是：（1）有助于判断什么是需求，什么不是需求；（2）可以将开发精力集中在产品范围之内，少干吃力不讨好的事情；（3）有助于控制需求的变更。5.产品中的角色提示：阐述本产品的各种角色及其职责。各种角色的具体行为将在功能性需求中描述。角色名称职责描述、6.产品的功能性需求6.0功能性需求分类提示：将功能性需求先粗分再细分，下表中的FeatureA,FunctionA.1等符号应当被替换成有含义的名称。功能类别子功能FeatureAFunctionA.1FunctionA.2…FeatureBFunctionB.1FunctionB.2……6.mFeatureM提示：此处写一些承上启下的文字。6.m.nFunctionM.N名称、标识符功能描述优先级输入操作序列输出补充说明提示：此处也可以描绘每一个用例的场景，以用例图表达参与者各个用例以及用例之间的关系，对应每个用例，可以书写相应的场景，包括：名称、主要参与者、简述、前置条件、后置条件、主事件流、扩展流、补充说明等。在必要的时候，也可以描述各个概念对象之间的时序关系。不论是书写传统的功能操作序列，还是书写用例场景，所表达的信息是基本一致的，可以根据情况选用。……7.产品的非功能性需求7.1用户界面需求需求名称详细要求…7.2软硬件环境需求需求名称详细要求…7.3产品质量需求主要质量属性详细要求正确性健壮性可靠性性能，效率易用性清晰性安全性可扩展性兼容性可移植性…7.n其他需求附录A：需求建模与分析报告提示：建议用UML对产品需求进行建模与分析，也可以使用DFD进行数据流的过程分析，这要根据具体情况选用。A.1需求模型1A.n需求模型N附录B：需求确认提示：需求确认规程主要分两步：（1）需求评审，（2）需求承诺。对需求的评审应当采用“正式技术评审方式”，将产生一份“需求评审报告”，规程请参见SPP-PROC-TR。在获取责任人（Stakeholders）对需求的承诺之前，该《产品需求规格说明书》必须先通过需求评审。需求评审报告摘要需求文档输入名称，标识符，版本，作者，完成日期，…需求评审报告输入名称，标识符，评审日期，…评审结论[]工作成果合格，“无需修改”或者“需要轻微修改但不必再审核”。[√]工作成果基本合格，需要作少量的修改，之后通过审核即可。[]工作成果不合格，需要作比较大的修改，之后必须重新对其评审。评审意见评审小组成员输入评审小组成员需求承诺需求文档输入名称，标识符，版本，作者，完成日期客户承诺承诺…签字，日期项目经理承诺承诺…签字，日期7.2善于书写良好的文档1，书写良好的文档很常见的情况是，开发人员对于书写文档有种种非议，但是一个正规的软件项目，即使带来了表面上的工作效率降低，也必须花费精力书写文档，为什么呢？任何时候，只要是两个人以上参与项目，都离不开口头交流，但是每个人在传递这个口头交流的内容的时候，都会把原来的意思歪曲一点点，人类的记忆能力就是这样的。一个软件项目永远离不开口头交流，我们不必要去停止这种交流方式，但是当开发人员比较多的时候，就可能带来很多麻烦，某些情况需要大家都知道，需要其他人员与之交互等等，解决的办法就是把所有的情况记录下来，或者是要强调书写文档。利用文档记录有五个好处：1）拓展人脑所掌握的记忆范围在任何一个大到必须编写需求文档的项目中，信息的含量都会超过一个人可以掌握的规模，书面文字可以供将来参考，而不会像记忆一样慢慢的褪去。2）为项目团队所有成员提供相同的信息书面文档阅读的时候内容是相同的，所有的人员都阅读相同的材料，这是任何人对人的口头交流无法达到的效果。3）减少项目人员流动的困难项目中发生人事变动是正常的，当老成员离开，新成员加入的时候，任何口头交流都很难让人很快地掌握情况，一份很好的文档可以让他花更少的时间融入到团队中去。4）保护智力资产在大多数情况下，项目中只有少数的人理解问题域，他们知道是否需要变更，软件是否存在某些漏洞，内心中对软件是不是有什么新观点。如果这些人把他们掌握的信息以正规的方式记录下来，项目对他们的依赖就会减小，如果他们获得了更好的机会，他们的智力资产也不会被带走。5）帮助书写人员更好的理解问题域以书面形式描述需求和规格说明，将促使相关人员花精力以比口头交流更标准和更准确的方式表达。人们在写作过程中可以发现自己对需求理解存在漏洞，甚至概念上也是不完整的。难怪人们说：“文档本身并不重要，重要的是写文档的过程。”当然，这样写出来的文档对别人也是重要的。从长远的角度看，需求的整体文档都是重要的，而从短期来看，规格说明书是最重要的。规格说明书很明确的告诉程序人员和测试人员我们需要开发什么测试什么。如果没有这些背景知识，他们就没有办法权衡技术实现方法，也没有办法提出建设性的意见和建议。很多公司实际上是很严肃地对待文档的，但他们并没有从文档中得到好处，相反在实践中口头交流仍然是主要手段，其关键原因是所书写的文档并不是为了开发而是为了应付检查。从格式上看很漂亮，内容面面俱到，但在文档组织上把信息分散到各个地方，不容易查找，使文档提供的好处尽失。如果我们希望项目开发小组很好的使用文档中的信息，就需要考虑什么内容是开发小组最关注的，怎么组织文档才是对开发来说最容易查找，如何编写才是最容易阅读和有效的。2，走捷径及其风险确实在很多情况下可能需要走捷径，例如时间紧迫，由于需求分析占用了大量的时间而使编码发生延误，最终很可能影响整体质量。当然需求不足也会影响整体质量（bug增多），很多情况下这两者是需要权衡的，作为项目负责人就需要对走捷径的利弊进行分析和权衡，下面我们对常见的捷径与风险做一些讨论。1）省略问题域捷径：在需求文档中，省略掉对问题域的描述，也就是说只写需求陈述，这将使需求文档从篇幅上大大缩短，恐怕三页纸敲定需求文档也不是没可能。风险：当需求人员离开自己目前的岗位，恐怕就没有人理解客户为什么需要这些能力，也没有人能够理解客户的业务，对应用程序的维护将变得很困难，对项目的修改和优化也将会变得极其被动。不考虑问题域的描述，还会导致先入为主的解决方案。通过理解问题域，评审人员、设计人员可能会提出一些很好的建议，有时还可能提出新的需求，这些建议也可能使需求人员从没有想到的。如果没有对问题域的理解，那设计人员唯一能做的就是被动执行。另外一个风险在于，如果不是把需求与具体的业务背景关联起来，需求陈述本身很可能被错误的理解。2）省略需求分析文档捷径：把整个需求分析文档都省略掉，只是提供一个需求规格说明，描述软件与外部世界接口的行为。风险：没有明确的需求描述，只是依靠与外部世界接口的需求规格说明。设计人员就可以天马行空的设计他们认为够酷的功能了，只要符合规格说明描述的接口规定就行。这些功能对用户来说可能是毫无意义的，也可能省略掉对用户来说非常看重的功能，原因很简单：因为这种功能开发起来没意思，不够酷，不能反映水平。3）省略用户接口文档捷径：用户接口文档描述的是用户界面（包括屏幕和其它的人机交互方式），很多分析人员往往省略这种文档，而让程序员编写程序边设计用户接口。风险：用户接口是直接与用户打交道的，人类的天性就是这样的：程序员倾向于忽略单调乏味的、实现起来费时费力又不能表现水平的用户接口思想。但是细心的用户接口人员会花很多时间细心的体会用户的感受，会在几乎不被人注意的地方用某种技巧性的方式使产品易于使用。在用户接口文档中，会包括很多程序员不愿意考虑的、充满想象力的、不同寻常的特性，这些特性会大大提高产品的价值。4）省略规格说明与需求分析捷径：这是最极端的情况，但我确实见过这种捷径。也就是说在软件开发过程中，不去书写任何需求文档，让程序员一边做需求分析、一边做程序设计。只是通过传统的口头方式与用户方沟通需求，问清楚一部分实现一部分，因此，既使产品已经制造出来了，对需求还只是一个比较模糊的印象。风险：除了上面已经说到的风险外，这种捷径必然带来大量的bug。这是因为，缺乏规格说明，测试人员无法建立测试计划，如果你总是在走这条捷径，恐怕你就不需要任何测试人员了。我见过的类