本文目录
产品需求文档模板
首先告诉你产品需求文档肯定是有的！一个经过实际工作检验、经历过“质疑”、“挑战”和“斗争”之后沉淀下来的模板，肯定是已经吸收了各类人的偏好、意见，固化了很多符合实际业务必须的内容要求，能够起到很好的业务承接作用。格式化、标准化本身是一个很好的思维、工作方式，可以让你在文档和接受文档的双方关系中建立一种“标准”的沟通机制和预先定义的沟通基础，减少额外的沟通成本，提高效率。
不过，在享受别人智力和经验梳理好的模板进行需求编写的同时，还是应该了解模板形成的原因，并在此过程中形成自己对于模板的理解，进而形成对于产品需求文档的理解，在理解中使用，裁剪和优化。
要理解和分析模板，理解和分析产品需求文档，可以运用以下几个方法：
一、描述-解释-预测-监控
描述，是对观察过程和观察结果的描述。观察的对象因不同的研究而有差异，其目标是尽可能完整地将观察者根据自己的观察得到的现象、由此现象所产生的思想和感觉，以及在观察过程中选择纳入的过程参与者对现象的反应等信息进行描述。
解释，是回答 “为什么”，是对于描述的理解、归类、定义和解释。其目标是将描述内容背后的成因、原理、动机，内容中各部分之间的相关，依存、依赖和影响关系等进行说明，以便对于描述内容有更清晰、更细致、全面的了解。
预测，根据以因果关系为内容的内在联系，相互影响来推导未来的发展或者将要发生的事情。通过研究解释内在的联系，准确地表达内在联系，从中推导出正确的预测。
监控，是对于预测行为、现象的观察和监督，包括了观察到的预测中的行为、现象的发生或者预测以外的行为、现象的外发生，以及因此而采取的对应的反映动作；这些反映动作是预测过程中根据内在联系制定的“响应”机制，并任其自然发生或者通过提供“系统”的自制能力来实现。
二、需求准备、编写和检查
回归到产品经理的日常工作中，在时间占比上较为集中的就是产品需求管理了，包括了需求的准备、分析、编写和检查过程。在这个过程中，描述——解释——预测——监控这个通用的科学分析过程也同样使用，且可以贯穿其中，并可以帮助理解、形成并固化成我们前文提到的需求文档的模板。这个科学分析的过程、方法在不同阶段运用的侧重点会有所不同。
1. 描述
描述的过程是客观的进行“需求向”描述的过程，是一个“背景”信息的补充，用来说明，这个需求文档的源出是什么，是针对什么问题，这个问题是在具体什么领域，在怎样的范围内，涉及到的是那些人；在需求相应的功能设计实现之前，当前的解决方案存在的问题是什么，参与者是怎么解决的，解决的情况怎么样，是好，还是不好，还是勉强可以，对于新的需求的紧迫性是什么样的。此外，描述的过程还需提供一个基础的概念和流程的解释，用来统一作为背景去理解一个现实的业务场景和“沟通字典”，避免在沟通中因为误解而产生不必要的偏差。
需求准备的过程：了解需求来源（管理部门、市场部门、运营部门等），需求背景（行业、同业规则现状等）；
需求分析的过程：了解需求目标、预期效果（时间、结果等）、使用者习惯、相关人影响；
需求编写的过程：描述需求目的、背景、时间和结果要求、业务流程、交互过程、系统架构、干系人角色和影响范围；
需求检查的过程：需求的背景、目标、过程、干系人、结果预测和预防的完整性检查；
2. 解释
解释在需求来源的基础上描述了 “为什么”接下来这个需求可以解决遇到的问题，同时还加入了“是什么”和“怎么样”的部分。就是这个需求是通过怎么样的方法解决了“描述”过程中提到的问题，这个新的解决方法需要要做什么，对于原有的业务过程有哪些改变，会提升什么，会降低什么，会影响哪些人、哪些业务部分、哪些业务系统以及哪些数据的产生。这个部分，是需求文档的最主要、最核心的内容部分，也是在内容上占比最大的一部分。
这里的解释根据产品需求面向的要解决的问题不同，而可能存在多个层面，多个维度的层面，比如对于运营的影响，对于前端市场的影响，对于用户的影响，对于财务、法务的影响；从技术开发、技术实现维度，比如对于前端开发的影响、对于服务端开发的影响、对于数据平台的影响，还可能涉及到对于运维资源的影响等；因此对应到实际的产品需求工作中：
需求准备的过程：了解需求可能涉及的相关业务系统及系统对应的数据流程和逻辑、了解需求可能涉及的外部服务的数据流程和逻辑；了解面向的内外部用户的产品使用水平、学习能力和使用习惯；
需求分析的过程：选择和制定最有效的，满足时间、资源投入等要求的方案；
需求编写的过程：详细描述需求的业务流程，通过各种图表格式说明新的解决方法在各服务系统之间、各业务部门之间、用户与产品，产品与后服务之间的数据、文件和行为的交互过程、详细的信息输入、信息处理和信息输出；每个业务节点明确的输出物和节点标志，重要性和优先级；系统架构、干系人角色和影响范围；
需求检查的过程：需求的流程、用户交互动作、系统信息交互等完整性检查；
3. 预测与监控
预测与监控在产品需求文档的管理上是联动的，是对于预测的事件发生的时候，进行管理的机制，监控=预测+干预。在产品需求文档的管理上，对于设计好的业务流程、使用功能，在实际过程中可能会出现这样或者那样的 “非规划”的使用，也就是我们通常说的“用户并不总是按照产品设计的方式来使用产品，而且，往往相反。”因此，这部分内容很大的比例需要来对于用户的行为进行预测和监控，并提供“预防”或者“解决”方案。其中：
预防在于，预测产品的用户在使用的过程中，可能会进行的一些超过产品使用半径的操作，一旦进行这些操作，操作的任务流程会中断，掉出，进入其他业务流程中且无法回滚，从而使得操作无法进行下去，功能使用失败，使用者会感觉产品、功能没有包容性，缺乏引导性，导致了最后操作的失败，预想的结果没有实现，而且造成了一定的挫败感，甚至造成了一定的损失。预防的具体方法多采用导航、提示等，不同的系统都有各自标准化的控价，我们在这里不做展开。
解决在于，预测产品的用户在使用产品的过程中，因误解、操作手误而进行了“非标”、“超规”使用“掉出”原本设计的业务流程和操作流程的情况下，需要提供额外的流程和控制来“回转”用户的操作，来帮助用户回到预先设定和他所需要的流程上来。解决的具体方法多通过“导航”引导“跳转”和“返回”、“回退”来实现。对应到实际的产品需求工作中：
需求准备的过程：了解用户特征和使用水平、评估、比较不同方式实现需求对于用户行为的可控性和“非常规”操作的危害程度；
需求分析的过程：选择和确定需求实现方案，评估行为管理方式和管理机制；
需求编写的过程：详细描述需求的业务流程和交互过程中可能出现的用户异常操作，相应异常操作中系统反应，系统对应的控制和引导；
需求检查的过程：需求“异常”流程和相应引导、控制地完整性检查；
在需求管理的过程中，就可以按照这个 描述——解释——预测——监控流程来进行。这四个既是步骤，是需求文档内容的组成部分，也是需求编写完成之后的检查。
四个模块构成了需求文档的完整性，且同时有各自独立，有对应的说明，引导、要求和标准。所谓标准文档，就可以按照这四个模块作为框架、内容和格式。
写在最后
产品需求文档作为产品经理同视觉设计、交互设计以及技术开发人员进行需求沟通的一个载体，我平时用的比较多的是摹客的服务进行创作。一个完整的、充分沟通确认，并最终达成多方理解和共识的产品需求文档，能够最大限度的还原产品、功能的设计，保证产品、功能的实现，最大限度的减少因为各方理解的偏差而造成的时间、人力和经济资源的浪费及复工。
软件工程需求分析的模板
需求规格说明阐述一个软件系统必须提供的功能和性能以及它所要考虑的限制条件,它不仅是系统测试和用户文档的基础，也是所有子系列项目规划、设计和编码的基础。它应该尽可能完整地描述系统预期的外部行为和用户可视化行为。除了设计和实现上的限制，软件需求规格说明不应该包括设计、构造、测试或工程管理的细节。 1)采用软件需求规格说明模版: 采用需求规格说明书模板在你的组织中要为编写软件需求文档定义一种标准模板。该模板为记录功能需求和各种其它与需求相关的重要信息提供了统一的结构。注意，其目的并非是创建一种全新的模板，而是采用一种已有的且可满足项目需要并适合项目特点的模板。许多组织一开始都采用IEEE标准830-1998(IEEE 1998)描述的需求规格说明书模板。要相信模板是很有用的，但有时要根据项目特点进行适当的改动。1 2 3 4 5 6 A引言 目的 文档约定 预期的读者和阅读建议 产品的范围 参考文献 B综合描述 产品的前景 产品的功能 用户类和特征 运行环境 设计和实现上的限制 假设和依赖附录 C外部接口需求附录 用户界面附录 硬件接口 软件接口 通信接口 D系统特性 说明和优先级 激励/响应序列 功能需求 E 其它非功能需求 性能需求 安全设施需求 安全性需求 软件质量属性 业务规则 用户文档 F其它需求 G附件 词汇表 分析模型 待确定问题的列表 表2 需求规格说明模板 a. 引言 引言提出了对软件需求规格说明的纵览，这有助于读者理解文档如何编写并且如何阅读和解释。 a . 1 目的 对产品进行定义，在该文档中详尽说明了这个产品的软件需求，包括修正或发行版本号。如果这个软件需求规格说明只与整个系统的一部分有关系，那么就只定义文档中说明的部分或子系统。 a.2 文档约定 描述编写文档时所采用的标准或排版约定，包括正文风格、提示区或重要符号。 a.3 预期的读者和阅读建议 列举了软件需求规格说明所针对的不同读者，例如开发人员、项目经理、营销人员、用户、测试人员或文档的编写人员。描述了文档中剩余部分的内容及其组织结构。提出了最适合于每一类型读者阅读文档的建议。 a.4 产品的范围 提供了对指定的软件及其目的的简短描述，包括利益和目标。把软件与企业目标或业务策略相联系。可以参考项目视图和范围文档而不是将其内容复制到这里。
如何进行需求分析（教科书式的回答）
一、什么是需求调研？ 需求调研对于一个应用软件开发来说，是一个系统开发的开始阶段，它的输出“软件需求分析报告”是设计阶段的输入，需求调研的质量对于一个应用软件来说，是一个极其重要的阶段，它的质量在一定程度上来说决定了一个软件的交付结果。怎样从客户中听取用户需求、分析用户需求就成为调研人员最重要的任务。 需求调研是为需求说明书撰写做前期工作，需求说明书是从需求调研表中得到或抽取而出；是了解实际工作中真正需要什么样的程序的过程，再把这些需求细节整理由设计部开发，给用户使用。 需求调研，特别是合同额已经确定的项目的需求调研，就像外交一样，实际上是一种策略艺术，它是在和客户相互尊重、平等互利的基础上，不卑不亢的去交流沟通，守住我方底线，尽可能的争取有利于我方条件，在完成任务的同时，还能赢得客户的理解和尊重。 需求调研，简而言之就是和客户进行谈话沟通，把客户的想法和要求记录下来，最后整理成为《用户需求说明》，以便进行下一步的需求分析、系统设计等，正因为后面的需求分析、系统设计，乃至开发等等都以需求调研的内容为依据，那么需求调研质量的好坏直接就决定了软件系统的好坏，也即项目的成败。 通常我们一提到某个系统，感觉上应该始终就是一个东西，但其实在不同人眼里，可能是不一样的，比如按照一般软件开发过程来说，就有如下几种： 1.客户实际需要的软件 2.客户头脑中想要的软件 3.调研人员调研后的软件 4.设计人员设计出来的软件 5.开发人员开发完成的软件 （这里特别注意客户实际要的软件和客户头脑中想要的软件可能并不是一个东西） 如果上述中间各个过程都有理解偏差，那么很可能就出现最终开发完成的软件和客户实际需要的软件差异较大，一个失败的或者做的不好的项目，往往原因就在这里。 而且还有一点，上述过程中，越往后，修改这些偏差要付出的代价就越大，直到你无法承受。那么，保证你调研出来的需求和客户实际的需求以及客户头脑中想要的三者保持一致，并且这个需求在开发上是能够实现并且容易实现，就是每一个需求调研人员努力要做到的。 二、项目类需求调研的特点 1.《需求规格说明书》的出具比较仓促，质量低 (1).不切实际的工期（需求调研成了走过场） (2).用户方怕担责任的心态（模棱两可的说法） (3).认知程度的限制（项目达到的预期是什么？调研人员错误的理解，怕引出额外诉求） (4).迫于工期压力，各方妥协签字了（没有争取广泛的支持） 2.大部分需求是《需求规格说明书》出来以后出来的 (1).程序被迫使用，与切身利益相关，被迫重视（流程、易用性、工作量全来了） (2).用户认知程度逐渐被引导，使用积极性提高，提出更多的功能诉求 注意把握这些问题要点，在实际操作中注意规避相关错误要点，正确很好的引导客户，把需求调研向良性的方向发展。 三、需求调研的前期准备 1.确定调研工具 选取需求调研过程中的一些辅助工具，选取要求是自己（本组）熟悉的工具， 工具最好也是要求是普通流行的，因为要考虑交流的问题。 如：原型、草绘图、WORD、EXCEL、PPT、POWERDESIGNER、STARTUML等。 这里只强调原型化方法，原型化方法就是尽可能快地建造一个粗糙的系统，这系统实现了目标系统的某些或全部功能。建造这样一个系统的目的是为了考察某一方面的可行性，如算法的可行性、技术的可行性或考察是否满足用户的需求等。如：为了考察是否满足用户的要求，可以用某些软件工具快速的建造一个原型系统，这个系统只是一个界面，然后听取用户的意见，改进这个原型。以后的目标系统就在原型系统的基础上开发。 原型主要有三种类型：探索型、实验型、进化型。 探索型：目的是要弄清楚对目标系统的要求，确定所希望的特性，并探讨多种方案的可行性； 实验型：用于大规模开发和实现前，考核方案是否合适，规格说明是否可靠。 进化型：目的不在于改进规格说明，而是将系统建造得易于变化，在改进原型的过程中，逐步将原型进化成最终系统。 在使用原型化方法时有两种不同的策略：废弃策略、追加策略。 废弃策略：先建造一个功能简单而且质量要求不高的模型系统，针对这个系统反复进行修改,形成比较好的思想，据此设计出较完整、准确、一致、可靠的最终系统。系统构造完成后，原来的模型系统就被废弃不用。探索型和实验型属于这种策略。 追加策略：先构造一个功能简单而且质量要求不高的模型系统，作为最终系统的核心，然后通过不断地扩充修改，逐步追加新要求，发展成为最终系统。进化型属于这种策略。 2.调研项目前期情况 对象：售前人员、商务人员、项目经理； 内容：招标书、答标书、合同、以及其他与用户交流的口头或书面材料（包括宣传、承诺等） 甲方行业情况的了解、最好看一些行业方面的书籍，学习业务领域知识。 了解客户、项目的背景，如果事先客户给过类似的《软件初步思路》之类原始需求文档，那么首先弄懂这个文档，了解客户的目的，为什么要做这个软件，主要想解决什么问题，涉及的业务有哪些等等，这些调研准备的基础。 根据了解的初步用户需求，分析可能的难点在什么地方，列出这些难点。做到心中有数，并且记录前面了解需求的过程中不明白的地方，便于到现场后及时和客户沟通。 3.建立需求调研规范 一定建立一个专门的设计环境（文档目录）来为本项目服务，进行一定的资源分配，进行必要的文件管理。 (1).统一项目所用工具 (2).统一项目文件模版 (3).其它资源列表（资料，相关网站，资询电话） 4.明确客户方组织结构 用户单位的组织机构是什么，哪些部门和人员岗位参与本系统的使用？上下级关系如何？为项目组建立起外部联系通讯录。 了解客户的组织机构，涉及软件使用的部门，参与调研的部门和人员，客户关键人是谁等等，尽可能获得客户上层的支持，自上而下的开展需求调研会使调研工作更容易推动。客户需求小组成员要尽可能多的代表客户不同的用户层次。 5.制定项目的调研计划 调研计划制定目的：对调研活动序列进行划分、评估、资源分配。 在制定计划时考虑到分析时间。计划在公司内部评审通过后，及时提交给客户，让客户对调研计划有充分的了解。 调研计划包含的内容： (1).调查什么？通过什么方式调查？何人何时调查？ (2).明确项目组人员分工（培养我们的专家） (3).调研中大家遵循的约定（如：需不需要签字？何时召开例会等） (4).针对需求中的功能模块，客户方有明确的唯一配合联系人 注意事项： 项目任务书下达给后，项目经理及调研人员应该对合同中软件范围认真审阅，虽然只大概写了需求范围，但这些信息及为重要，它是调研计划制定的一个依据。 计划制定后最好召开项目启动会议，相关领导和业务部门参与，确定双方项目组成员，确定客户方的配合人（唯一联系人）、领导（唯一协调人），介绍项目组的人员安排、总计划、需求调研计划将行程和计划通知客户. 四、需求调研内容 1.需求调研要收集的内容 需求分析报告的读者有客户、设计人员、开发人员，在编写时一定要考虑到文档的可读性。需求调研形成的成果具体如下： (1).收集用户需要产生的单据和报表 ；表单及报表的适用对象； (2).画出业务流程图，并认真检查和核对每条路径中是否完备，异常情况怎样处理（系统的动态特性）； (3).依据流程图收集每个步骤需要的使用和操作的数据，确定数据的类型和范围（系统的静态特性）； (4).画出业务实体及其关系，并估计业务实体的产生频率和数据量； (5).评估业务流程和实体中需求变化的可能性； (6).用户权限； (7).信息系统建设现状； (8).收集用户对系统界面风格、版式、颜色的偏好和需求； (9).对系统将来使用的硬件、操作系统、网络情况进行了解； (10).收集系统初始化数据，或者要求客户进行收集和整理，明确期限时间； (11).编制简单界面原型（该步骤也可放在需求分析之后完成，再次和用户进行沟通）; 2.需求调研成果 (1).《需求规格说明书》 (2).系统详细原型 五、如何做好需求调研 1.要做什么就要先了解什么 如果对客户业务不熟悉，在调研前要先做好充分的准备。 如果做的项目是你所不了解的行业（专业），最好要有专家——最终用户做专家是最好的，调研要了解这个专业，不是要你成为专家，但最少要了解一定的专业知识（最少专来词汇你要知道），否则就不知道去问什么或如何去问他们，甚至于人家在说什么你也不知道。 相应的专业资料是必须的，最少要有专业入门书籍和对应的资料，也需要更深入的一些资料。当然有专家的参与就另当别论。 如果行业的难度不是很大，可以通过分析人员的自我学习在短时间内了解行业，也许可以不用专家，否则专家是必须的。 2.采用多种手段挖掘需求 重视调研资料的准备：调研资料（Rose图、Ppt、原型准备）一般客户图形化界面感兴趣，最好是采用图的方式把东西展示给用户，可以意思转换为用例图、用户界面、流程协作图、状态图等。 需求调研过程有选择的确定调查方式，例如： 1).与客户交谈，向用户提问题; 2).参观用户工作流程，观察用户操作; 3).向用户发调查问卷; 用户通常没有耐心回答论述题，所以应当以选择题和是非题为主。 4).与同行、专家交谈，听取他们的意见; 5).分析已经存在的软件产品，提取需求; 6).从行业标准、规划中提取需求; 7).上网搜索相关资料 3.站在用户的立场上考虑系统功能 1).设身处地的成为用户，考虑适用型和用户体验； 2).用户的语言与用户交流; 3).总结以往的实施经验，提出建议; 4).总结以往的实施经验，引导需求; *以上各条也是尽量减少需求变更的手段之一； 4.5W + 1H方法 5W：why、what 、who、when、where 1H：How to accomplish(实现) the system? WHY定律：WHY就是为什么用户要引入系统，引入新的信息系统对用户有什么帮助，在总体工作效能上如何实现一个最终的结果？WHY定律是要求在需求开始时，项经理就应该明确的，这个项目是为了改进用户工作效率；提高部门间的协作机制；加快对客户反应的体系服务；提升企业的竞争力等等。有了这么一个WHY引入思想，项目经理就可以理清用户最终要的是可以提供给他们什么样的系统，在系统的定位和建立上，就有一个明确目标。 WHAT定律：有了一个总体的目标性，从各业务流程的要求入手，引入第二个W定律__-WHAT定律，WHAT则是这个系统要做什么？实现什么？提出各业务流程问题、流程局限性问题、系统要解决的问题等，在这个WHAT的基础上，把系统划分成各功能模块，逐步弄清模块流程需求、功能需求、结构需求。引入WHAT定律可以让我们了解到系统的初步需求。 WHO、WHEN、WHERE定律：这个阶段是需求细化阶段，在WHAT定律的基础上，细分系统的用户需求：分析什么人，在什么时间，什么阶段可以或必须操作这个功能，结合前面的WHAT定律，理清系统的流程阶段划分，记录并分析系统功能实现的细节，在这个阶段就可以产生系统需求的用例图（Use Case），作为下阶段设计的依据。 HOW定律：就是怎样实现系统了，在前面的WHY、WHAT、WHO、WHEN、WHERE基础上，已经搭建了一个非常好的系统需求基础框架，如何在这些用户需求的基础上，分析系统的需求，如何进行需求规格的分析与下阶段的设计、实现工作，就是How to accomplish(实现) the system? 引入这5W+1H的定律，在一定程度上保证了系统需求的准确性，使得项目经理或需求分析人员可以有序、有条理地开展需求挖掘和调研活动，这样的安排用户在配合上也非常清晰，知道如何与项目人员配合。 5.需求调研注意事项 (1).按照计划有步骤的调研 提前约定调研活动的计划，达到的目标，时间安排，参与的人员，并根据用户安排，适当调整计划。最忌参加会议时目标不明确、汇报人员不明确。 按照事先和客户商量好的调研计划稳步进行，如果现场临时出现变化，比如参与调研的客户临时有事，或者调研的内容出现变化，那么及时和客户确定新的调研安排，列出总的调研顺序。切忌想到哪说到哪，调研内容杂乱无序，很有可能就会出现遗漏而不能及时发现。 (2).掌控调研进程，推动调研工作顺利进行 因为调研工作实际就是和客户聊天谈话，很可能就会经常跑题，越扯越远，另外客户的精力一般也容易不集中，跑神，这时候，调研人员要能够掌控整个进程，什么时候及时把客户的思路拉回到正题上，什么时候适当的聊聊其他的话题调节气氛，都需要调研人员灵活掌握，总之一个目的，尽快的推动调研工作朝前进行。 (3). 认真仔细的倾听，及时的记录 仔细的倾听就是要明白客户的完整的表达，不要觉得有些你已经懂了，经常打断客户来急切表达自己的看法，每次在客户完整的把话说完再表达自己的想法。及时记录涉及客户业务、实际工作、客户想法的内容，不能以为当时听明白了就不去记录。一定要有记录的习惯，谈上几个小时，很多细节是记不住的。 (4).先了解宏观需求，再了解细节需求 遵从由总到分、由粗到细、由简单到复杂的调研过程，无论是让客户介绍他们的业务还是谈他们的想法，都要先从总的大的方面说起，然后再是细节。如果直接进入细节，往往并不能很好的抓住他的要点，不能把握总体的要求。 (5).挖掘客户最原始的需求，而不是仅仅只是记录 客户跟你说的内容只是他的一个理解，他的理解可能也有偏差，而且现在有的客户因为对软件比较了解，往往告诉你的不是需求，而是他的设计思路，比如直接跟你说“你做个这样的功能，我一点就能出来什么什么”，对我们来说，就需要多问几个问什么，“你为什么会这样做呢？”“你想看的结果是什么呢？目的是什么呢”等等，一定要想办法了解到客户没有经过转化的最原始的需求，因为往往很多时候客户告诉你的他的想法并不能实现他原本的目的，而他以为能实现，所以就直接告诉你想法。需求调研人员如果没有了解到最原始的需求而只是把客户的想法记录下来，那么就会出现做出来的东西解决不了客户实际的问题。 这个过程往往同时也能够帮助我们缩小需求范围，比如客户开始想的好好的一些功能，但是在我们深入分析思考后发现因为存在某些问题这些功能无法实现，或者即使实现也会大幅增加工作量比开始想象的复杂的多，那么在这样一个基础上说服客户放弃这个想法。这也是在合同额确定的情况下砍功能的一种方式。 (6).引导客户的潜在需求 大部分客户对自己要做成一个什么样的软件并没有一个完整的规划或者想法，很多时候都是在谈的过程中逐步的清晰。调研的过程也不会是客户滔滔不绝的谈他的想法，而是靠你一点点的去问客户，那么到底问什么，就需要你掌握，除了不懂的业务以外，重要的是在已经了解的客户需求的基础上分析、扩展，带出其他潜在的客户没有说出来的需求。比如说客户想做一个领用办公用品的功能，开始想的很简单，填一个领用申请，一审批就行了，但是经过仔细分析后，就会衍生出“物品管理”“类别管理”“库存管理”等潜在需求。如果不考虑这些，那么无论是你还是客户都会认为这个功能很简单，那么对完成时间和工作量的估计都会出现问题。防止出现在做系统设计甚至是开发时才发现“当时没想到这个地方没那么简单，还需要再跟客户沟通一下”这种情况。 这里面，潜在需求如果细化的话还分为两个部分：1）系统必须的；2）系统不必须的。“必须的”就是像上面例子一样，如果不挖掘潜在需求，客户已经提出的需求就无法实现，就是把看上去简单的复杂问题，实际上他还是个复杂问题。“不必须的”，就是对已经提出的客户需求影响不大，相对独立，相当于再和客户沟通的过程中又了解到的新的需求。对这部分，就需要根据调研时项目的合同额是否确定，工作量大小，和客户的关系如何等等有需求调研人员灵活掌握，可以提也可以不提。但是提出就肯定会增加工作量和系统的复杂度。 (7).规避客户不合理的要求和较难实现的要求 客户需要的不一定的是客户真正所需要想要的。客户永远没有错，错的只有我们没有真正理解客户的需要。 调研时要把握主题的能力，分清有用功能、可选功能用、无用功能及不可实现功能，及时表达我们的观点，让谈话接近主题。 调研的过程中，不可避免的会出现客户提出一些我们现有条件下根本无法实现或者即使实现也非常困难的要求。这种情况就需要需求调研人员的聪明的头脑和快速反应能力，同时也需要调研人员的良好的沟通技巧，要能巧妙地说服客户放弃这种方式并且还要客户能够理解，而不致认为你在逃避问题不想解决。一般可以采取这些方式：1）客户提出这些要求后能马上了解客户提出这个要求的真实目的，然后快速思考出另外的简单的方式同样能实现客户的这个目的。这是最好的方式； 2）必要时直接告诉客户无法实现并且给出合理的理由，特别是在客户说某某系统已经实现了这个方式时，比如他们用的是什么什么平台支持，这个平台支持需要另外付费等等； 3）直接告诉客户虽然能实现，但是需要很大的精力和成本，而这个可能是客户无法承受的，当然你一定要能说出客户听起来合理的理由。 这些都不是绝对的，需要调研人员丰富的软件开发经验和灵活的头脑较好的表达能力临场发挥。 (8).注意需求调研的覆盖面，防止需求不具代表性 需求调研开始时，客户明确的唯一配合联系人既是我们每个模块的一把手！我们要做的就是“拿着鸡毛当令箭”！找对人才能办好事。 同时也要防止提供需求的客户方面只有一个人，使实际软件需求变成个人需求。受制于这个人的所处层次，以及掌握的业务知识，与领导意图的符合度等等限制，给我们带来较大的需求风险，稍有不慎就会给后面软件需求变更埋下伏笔。避免这种风险，一方面调研人员依据以往的经验和业务知识自己判断客户提出的需求是否合适，有没有过于强烈的个人特征等等，另一方面，在调研开展的最初想办法和客户的上层明确类似风险的存在，让客户领导在人员安排上避免这种情况，同时也是让他明白会存在这种情况，以后一旦真的出现，客户也不会说是我们的责任。 (9).及时总结整理已经完成的调研内容 需求调研、相关会议纪要及时转发，及时总结成果，让客户听听你的理解是否他们提的需求一致。 每次调研回去后，及时把白天调研的内容及时整理出来，当时没来的急记的内容及时补记，同时再深入的分析、过一遍，确保有没有遗漏的问题，列出所有的疑问待到第二天调研时询问客户。 定期汇总的成果：什么情况下？什么人？做了什么决定？产出了什么？ (1).警惕不明确因素 实现某一个功能的前提条件是什么？如果没有哪个先决条件，哪些工作是无法开展的？责任划分清楚。 (2).成本，成本还是成本 高水平的设计师高就高在设计出“恰好”满足客户需求的软件，并且在开发方和客户方获取最大的利益，而不是不惜代价设计出最先进的软件。 (3).避免片面听取了某些用户的需求而忽视其他用户的需求六、什么是成功的需求调研 1.需求规格说明书具备的特性 正确、清楚、无二义性、一致（各个需求之间不产生矛盾）、必要（不画蛇添足增加开发成本）、完备（不遗漏必要的功能如权限配置）、可实现性、可验证性（提供交付依据）、明确优先级（不被细节拖死比如UI）、阐述“做什么”而不是“怎么做”。 2.覆盖合同中所有合理的需求 对待需求工程的态度可以分为“被动型”、“主动型”和“领先型”三种，只有后两种才有可能开发出成功的产品。 在实际工作中，可以建立合同与需求规格说明书对应章节对应表、合同与软件功能对应表。时刻提醒需要提供实现的业务范围。 3.成本风险在控制之内 4.挖掘潜在的需求 适当站在商务的立场上思考，为项目的寻找出路，申请更多的财力物力。七、签字画押 我们编写完的需求分析报告，最终要展示给客户，让他们对我们的分析结果进行认可。其实这个过程非常重要，对于客户和我们同样的重要。将业务需求与用户进行确认（采用会议讲解的方式），用户领导签字。 这个挺难的。 八、需求调研人员能力 1.熟悉客户业务 对于客户主要想让软件来解决他哪一部分的业务，事先最好能通过一些手段尽可能多的了解。即使事先并不能非常深入，那么也要利用调研的机会尽可能多的了解，调研完成后，没有理由你不是个半个业务专家。 2.熟悉软件开发 调研的过程中一方面你要随时对客户提出的要求的合理性、难易性作出判断，同时你还要在客户想法不成熟时提供给客户好的实现方式，这一切都需求你对软件开发非常熟悉，很多时候，需求调研人员至少曾经是一个优秀的软件开发人员。因为随着用户使用电脑的增多，对各种软件有一定的了解，往往会直接提出一些功能要求，比如在任务发起时提出需要给多人发送，那么对这样的一个功能会对我们的设计和开发有什么样的影响，那就需要现场需求调研人员根据自己的经验作出判断，然后思考出有利于自己的方式并巧妙的说服客户接受。 3.头脑聪明，反应敏捷 对客户表达的内容要能很快的、充分的理解，并且能迅速的思考及时应对。同时因为客户的水平也有高低，特别是对那些不善表达的客户，更需要你从不清楚的表达中分析出实质。 比如对于税务系统预警的调研，客户本身事先并没有完善的预警规则，很多都是调研现场临时思考出来的，那么这样的一个规则敲定后，你敢拿这样的内容去设计开发吗？那么就需要调研人员根据掌握的业务知识，在现场时及时根据客户提出规则迅速的在脑子里发散、扩展、分析、思考，找出规则是否还有漏洞，和客户继续深入探讨下去。 4.善于表达，思路清晰 能够把你的想法清晰的传达给客户，特别在一些难以理解的地方，能够灵活的用各种可能的方式让客户明白你的意图。当你在解释半天客户都没有明白的时候，一定要想想你在什么地方没有解释清楚了。 5.善于观察，精于总结 和客户打交道的过程中，善于观察每个细节，分析这些细节是否对你的工作有影响，每次阶段性调研完成后及时总结，来帮助更好的进行下一次的调研。比如在调研间隙观察客户的实际工作内容和工作流程，攀谈了解相关情况，观察客户是否还在使用其他系统，了解其他系统的情况；观察客户群体中的关键人物；观察客户各有什么爱好、特点等等。当天调研完成后，及时回顾整理一天的调研内容，筛选出疑问，便于第二天调研时向客户了解清楚。 6.善于记录，文笔流畅 一直强调，在客户现场，把你听到的看到的能记多少就记多少，尽可能的多记，，特别是客户在讲述自己实际的工作业务工作内容和方法等时，不要管他回去以后有没有用，千万不能因为当时听明白了就不记了，即使一时没有时间，那么事后也要及时补记下来。这些一手材料里有很多都是能够帮助你和没有参加调研的人理解业务需求的内容。防止出现，1）当时听明白了但没记录的内容，回来后某些细节又忘了；2）当时虽然记了，但写的内容太简单，回来后看当时记得内容已经想不起来是怎么回事了。
需求分析应包括哪些内容
需求分析就是对客户提出的“要求”或者“需求”进行深入细致地调研和分析，准确理解用户和项目的功能、性能、可靠性等具体要求，将用户非形式的需求表述转化为完整的需求定义，从而确定系统必须做什么，为系统设计、系统完善和系统维护提供依据。
需求分析是项目计划阶段非常重要的环节，该环节决定了需要“实现什么”，为下一步如何去“实现”提供了明确的方向。
进行需求分析需要做到以下几点：
（一）需求获取：在准备阶段，我们首先要确定需求获取的目标及范围，根据你的目标来选择对应的方式获取需求。
（二）需求分类：一般情况下，我们会根据对象的不同，将需求分为业务需求、用户需求、功能需求等。
（三）需求筛选：有些需求是伪需求，有些需求则不具备实现价值，我们可以通过真实性、价值性、可行性三个维度来筛选需求，过滤掉虚假的、不可行的、没有价值、价值不大或投入产出比不理想的需求。
（四）需求提炼：对剩下的需求进行提炼，目的在于从获取的表面需求中提炼出客户的本质需求。找出“为什么要做”比“做什么”更重要。
（五）需求优先级排序：挖掘到客户的真实目的后，我们需要根据不同维度的需求归类方法，如KANO模型分析法、投入产出比ROI等，对其进行归纳整理并排出优先级，帮助产品有条理地安排开发秩序，避免盲目排序。
（六）产出需求文档：通过以上的分析，我们需要将收集到的需求进行分析、汇总、归类，输出产出需求文档，为接下来的工作做好铺垫。
以上是对需求分析的一些理解和思路，做好需求分析工作之后，就可以对可实现的需求进行落地方案的跟进。
项目需求分析怎么写
项目需求分析的概念 需求分析是指理解用户需求，就软件功能与客户达成一致，估计软件风险和评估项目代价，最终形成开发计划的一个复杂过程。（这个和我在微软体验到的又不太一样，微软的需求分析大多是市场人员和用户协助小组的人去评估用户的接受程度，这一点也可以理解，因为公司的性质有根本差别）在这个过程中，用户的确是处在主导地位，需求分析工程师和项目经理要负责整理用户需求，为之后的软件设计打下基础。需求分析阶段结束后，要求得到：1.SRS文档(System Requirement Specification); 2.DRM 文档；3.Acceptance Plan. 从广义上理解：需求分析包括需求的获取、分析、规格说明、变更、验证、管理的一系列需求工程。 狭义上理解：需求分析指需求的分析、定义过程。 一、为什么要需求分析 需求分析就是分析软件用户的需求是什么.如果投入大量的人力，物力,财力,时间,开发出的软件却没人要,那所有的投入都是徒劳.如果费了很大的精力,开发一个软件,最后却不满足用户的要求,从而要重新开发过,这种返工是让人痛心疾首的.(相信大家都有体会)比如,用户需要一个for linux的软件,而你在软件开发前期忽略了软件的运行环境,忘了向用户询问这个问题,而想当然的认为是开发for windows的软件,当你千辛万苦地开发完成向用户提交时才发现出了问题,那时候你是欲哭无泪了,痕不得找块豆腐一头撞死. 需求分析之所以重要,就因为他具有决策性,方向性,策略性的作用,他在软件开发的过程中具有举足轻重的地位.大家一定要对需求分析具有足够的重视.在一个大型软件系统的开发中,他的作用要远远大于程序设计. 二、需求分析的任务 简言之,需求分析的任务就是解决"做什么"的问题,就是要全面地理解用户的各项要求,并准确地表达所接受的用户需求.三、需求分析的过程 需求分析阶段的工作,可以分为四个方面:问题识别,分析与综合,制订规格说明,评审. 问题识别 就是从系统角度来理解软件,确定对所开发系统的综合要求,并提出这些需求的实现条件,以及需求应该达到的标准.这些需求包括：功能需求(做什么),性能需求(要达到什么指标),环境需求(如机型,操作系统等),可靠性需求(不发生故障的概率）,安全保密需求,用户界面需求,资源使用需求(软件运行是所需的内存,CPU等),软件成本消耗与开发进度需求,预先估计以后系统可能达到的目标. 分析与综合 逐步细化所有的软件功能,找出系统各元素间的联系,接口特性和设计上的限制,分析他们是否满足需求,剔除不合理部分,增加需要部分.最后,综合成系统的解决方案,给出要开发的系统的详细逻辑模型(做什么的模型). 制订规格说明书 即编制文档,描述需求的文档称为软件需求规格说明书.请注意,需求分析阶段的成果是需求规格说明书(好象软考曾经考过这个问题),向下一阶段提交. 评审 对功能的正确性,完整性和清晰性,以及其它需求给予评价.评审通过才可进行下一阶段的工作,否则重新进行需求分析。 四、需求分析的方法 需求分析的方法有很多.这里只强调原型化方法,其它的方法如:结构化方法,动态分析法等(个人认为,对初学者不必深究这些方法,实际上我也从来没用过这些方法)在此不讨论. 原型化方法是十分重要的(是软考等常考的知识点).原型就是软件的一个早期可运行的版本,它实现了目标系统的某些或全部功能. 原型化方法就是尽可能快地建造一个粗糙的系统,这系统实现了目标系统的某些或全部功能,但是这个系统可能在可靠性,界面的友好性或其他方面上存在缺陷.建造这样一个系统的目的是为了考察某一方面的可行性,如算法的可行性,技术的可行性,或考察是否满足用户的需求等.如,为了考察是否满足用户的要求,可以用某些软件工具快速的建造一个原型系统,这个系统只是一个界面,然后听取用户的意见,改进这个原型.以后的目标系统就在原型系统的基础上开发. 原型主要有三种类型(软考考过):探索型,实验型,进化型.探索型:目的是要弄清楚对目标系统的要求,确定所希望的特性,并探讨多种方案的可行性.实验型:用于大规模开发和实现前,考核方案是否合适,规格说明是否可靠.进化型:目的不在于改进规格说明,而是将系统建造得易于变化,在改进原型的过程中,逐步将原型进化成最终系统。 在使用原型化方法是有两种不同的策略:废弃策略,追加策略.废弃策略:先建造一个功能简单而且质量要求不高的模型系统，针对这个系统反复进行修改,形成比较好的思想,据此设计出较完整,准确,一致,可靠的最终系统.系统构造完成后,原来的模型系统就被废弃不用.探索型和实验型属于这种策略。 追加策略:先构造一个功能简单而且质量要求不高的模型系统，作为最终系统的核心,然后通过不断地扩充修改,逐步追加新要求，发展成为最终系统。进化型属于这种策略.
怎么编写用户业务需求分析
需求分析格式1 引言1.1 编写目的【说明】目标：对用户的需求进行收集、整理与分析，弄清楚系统究竟要 “干什么”及“由谁干”，并用合乎规范的文字及图表予以描述。不需要说明“怎么干”，因为那是设计阶段的事情。有关文字与图表应尽量让用户便于理解。 预期读者：用户方的相关业务人员、双方的开发人员和系统维护人员。 作用：实现开发方与用户方的双向沟通，是把业务需求计算机化的关键步骤。 为下一阶段的概要设计工作提供依据。当用户的需求发生变更时，应添写补充说 明；如变动过大可形成新版本。软件需求说明（Software Requirements Specification）的主要作用为： 为用户方与开发方建立共同协议奠定基础。 提高开发效率、强化进度控制。 为项目的的评测与验收提供依据。 便于移植。 作为系统不断提高的基础。1.2 编写背景1.2.1 系统名称及版本号【说明】形如“网银三期***系统V3.0.0”。其中，版本号的格式为“XX.XX.XX”，X为阿拉伯数字，左“0”可省略。1.2.2 使用者【说明】适应对象和范围。主要指预期读者，也供有关领导审阅。1.2.3 与其它系统的关系【说明】在用户现有的及预期的整个应用系统中，给本系统准确定位。用示意图及相应的文字予以说明。2 用户的基本情况2.1 系统建设背景【说明】项目背景与依据、现有基础、项目规模、预期目标等。可繁可简，格式自定。2.2 组织机构与职能【说明】用层次示意图及相应文字表示(如果需要开发的系统与部门没有直接依赖关系此节可省略,本章随后的小节数将顺次减1)，加注：组织机构的层次数、数目、各个机构的职能简述。2.3 用户特点【说明】所在行业特征、操作人员与系统维护人员的数量、学历与水平、数据量大小、使用频度等。2.4 用户业务分析【说明】在本部分，希望系统分析人员能够对用户业务现状进行分析、对用户对本系统的未来发展方向作出一定的预测等。以便设计人员对业务及其发展有所了解，增强系统设计的前瞻性。2.5 计算机应用现状【说明】可繁可简，格式自定。3 业务需求3.1 项目概述【说明】第一、 指明项目的开发意图、应用目标（总目标、分期目标）、作用范围、预期效益等。第二、 指明在输入信息转变为输出信息的过程中，为了满足用户的业务需求，应用软件必须完成的基本功能(采用自然语言叙述)。但此时不要求对基本功能进行分解。第三、 如果本系统与其他系统相关联，则应确定本系统的基本功能边界（可采用图示+文字说明的形式，用蓝色标示出本系统的功能，用绿色标示出相关系统的功能）。3.2 约束条件3.2.1 费用约束【说明】 预计投资金额概算、其中软硬件费用的比例、资金分期到位计划。3.2.2 进度约束【说明】预计完成日期、分步实施期限。3.2.3 其它约束【说明】场地面积限制、通信设施基础、其它干扰因素。 注意：任何计算机系统都不是包罗万象的；用户自身的能力也是有限的。轻诺必寡信。故应特别指出：由于哪些条件的约束，本系统不能满足哪些业务需求与系统需求。本章主要介绍项目的总体业务功能,要求站在客户的角度把握系统需求.3.3 性能需求【说明】依据ISO9000标准及我们的理解，下面列出了软件的6组性能，共涵盖21个子特性。这些性能/子特性的相对重要性并不是等同的。编写时，可以基于具体项目的实际需求，对下述标题或内容进行取舍/侧重。事实上不可能做到面面俱到，往往要作出某些折中。本节说明系统在性能方面的预期目标，不要求提供实现上述目标的具体实施方案。3.3.1 功能性【说明】指与软件实现的各项功能及其指定性质有关的一组属性。这些功能都是满足规定需求和潜在需求所必需的。它包括5个子特性：适用性：与指定业务所需各项功能的实现及其适合程度有关的一些软件属性。准确性：与保证正确（或符合要求的）结果（或效果）有关的一些软件属性。互操作性：与软件同一些指定系统交互作用能力有关的一些软件属性。复合性：使软件遵守相关的标准、约定/法律或类似规定有关的一些软件属性。保密安全性：与针对蓄意（或无意）而非法存取程序和数据的预防能力有关的一些软件属性。这里主要指的是保护软件的要素，旨在防止各种非法访问、修改、破坏、泄密及感染计算机病毒等。3.3.2 可靠性【说明】指在规定的条件和期限内，与软件保持其性能水平有关的一组软件属性。成熟性：与软件故障引起的失误频率有关的一些软件属性。容错性：在软件故障发生或其规定界面被破坏的情况下，与软件仍能保持规定性 能水平的能力有关的一些软件属性。可恢复性：在失效的情况下、在限定的期限和强度范围内，与软件重建性能水平 并恢复直接受影响的数据的能力有关的一些软件属性。3.3.3 易使用性【说明】指与规定用户（或潜在用户）使用软件所需的努力程度、对这种使用所做的评估有关的一组软件属性。它包括3个子特性：易理解性：与用户为理解其逻辑概念及适用范围需做的努力有关的一些软件属性。易学习性：与用户学习其应用（例如操作控制、输入、输出）需做的努力有关的一些软件属性。易操作性：与用户操作及运行控制需做的努力有关的一些软件属性。3.3.4 高效性【说明】指在特定的运行环境中，描写软件性能水平与所用的资源量之间关系的一组软件属性。它包括两个子特性：时间特性：在完成软件功能时，与响应时间、处理时间、吞吐率有关的一些软件属性。资源特性：在完成软件功能时，与所用资源量及占用时间有关的一些软件属性。3.3.5 可维护性【说明】与对软件进行指定的修改所需的工作量有关的一组软件属性。它包括4个子特性：易分析性：与诊断故障、确定失败原因、在需要修改的部位进行标识等所做努力有关的一些软件属性。易修改性：与实施修改、排除故障、环境改变所做努力有关的一些软件属性。稳定性：与修改的意外影响带来的风险有关的一些软件属性。易测试性：与对经过修改的软件进行检验/确认做努力有关的一些软件属性。3.3.6 可移植性【说明】指软件从一个环境转移的另一个环境时，与其适应能力有关的一组软件属性。它包括4个子特性：适应性：除已有手段外，无须采用其它措施或手段，软件便应能适应指定的环境。与这种能力有关的一些软件属性称为适应性。易安装性：在指定环境内，与安装软件所需努力有关的一些软件属性。一致性：软件从一个环境转移的另一个环境时，应符合一定的标准和约定。与这种符合程度有关的一些软件属性，称为一致性。易替换性：有时会出现这种需求：在某个其它软件的运行环境下，要用本软件来置换那个软件。与这种可能性及所需努力有关的一些软件属性。4 用户需求【说明】本章下面介绍的是一般规模软件系统的书写格式。在书写过程中可能要以业务名称划分小节(例如:5.1 代收电话费)。每个业务小节包含两个部分：第一部分是对此业务中角色和功能的定义；第二部分是此业务的图形分析方法。 在本章开始未分节的部分，应当绘制一个总体结构图，依据这个总体结构图进行一个总体描述，使得阅读者对下面分节描述的各个功能形成一个整体印象。这个总体结构图不一定是指在ROSE工具中绘制的用例总图， 而是根据需要可以选择包括“用例总图”、“适当级别的数据流图”、“IDFF图”、“数据流程图”或其他专业图形分析图示等。 每个小节中的第二部分采用rational公司的rose2000作为工具绘制用例（use case）图和顺序（sequence）图。在这里采用rose工具是作为绘图分析工具使用，对需求的描述和分析并不代表我们的设计采用UML标准和面向对象的设计，具体分析人员应当根据实际的用户需求描述绘制顺序图，而并不着重考虑对象的分析限制。需求变更的处理原则：获得批准的需求变更，需要在《需求分析》中有所体现。增加的需求，需直接从本章尾部顺序添加，相应的小节编号也需要依次增加。例如：本章小节为5.1—5.5，增加的需求小节编号则为5.6。删除的需求，不需要将相应需求直接从《需求分析》中删除，而只需在相应需求小节上注明删除，并标出《需求变更单》编号。修改的需求，可在相应的需求小节直接修改。所有对《需求分析》内容的修改必须在修改历史中留有记录。4.1 业务名称14.1.1 角色/功能定义【说明】根据会议纪要、小组讨论，确定系统中的角色（角色可以为外部系统或系统用户），和功能，并给出相应的定义或解释。4.1.2 图形分析【说明】本节主要描述相应业务的用例图和顺序图的内容 统一建模语言（UML）是一个通用的可视化建模语言，用于对软件进行描述、可视化处理、构造和建立软件系统制品的文档。它记录了对必须构造的系统的决定和理解，可用于对系统的理解、设计、浏览、配置、维护和信息控制。UML适用于各种软件开发方法、软件生命周期的各个阶段、各种应用领域以及各种开发工具，是一种总结了以往建模技术的经验并吸收当今优秀成果的标准建模方法。在本需求模板中我们选取的是UML视图来辅助进行图形需求分析，选用Rational公司的ROSE工具完成。在需求分析过程需要完成结构分类中的用例分析，绘制用例图；对用例的动态行为进行交互分析，描述执行系统功能的各个角色之间相互传递消息的顺序关系，绘制顺序图。在这里请作者将制作的用例图和顺序图拷贝到本文档中。基本成分：用例（use case）、用例视图（use case view）、角色（role、actor）、顺序图（sequence diagram）、协作图（collaboration diagram）。模板和命名：为更好地使用ROSE图形分析工具，我们设定一个基本的分析模板，文件名为lansoftmdl.mdl。该文档涉及项目开发的需求、概设和详设3个阶段，在需求阶段主要完成模板中用例视图（use case view）规定完成的部分。在项目中使用该模板后生成的mdl文件纳入文档的配置管理，具体命名参照SEMP体系的命名规定。修改历史记入文档开始部分的“mdl文档修改历史表”中。【ROSE使用要求】1、 要求使用ROSE工具时必须完成模板和使用要求中规定完成的内容，在完成基本内容的基础上，可以根据需要增加部分内容。2、 在公司没有购买确定版本的ROSE以前，使用的ROSE版本应在项目开始前在项目组规定好，并由配置管理员负责配置。3、 在用例视图（use case view）中建立一个名称为main的主用例图（use case diagram），具体内容应当包括所有用例图的全部内容，具体应用时还可以根据情况建立多个用例图（use case diagram）。4、 在用例视图中请采用中文对所有的角色（actor\role）进行命名。其中角色必须在双击该对象图后，详细填写该角色的描述（documentation）和该角色代表的角色数量（detail-multiplic）。5、 在用例视图中请采用中文对所有的用例（use case）进行命名。命名中在一般的中文概括前应增加代表本节编号的部分，如“1.用户认证”，顺序编号。其中用例必须在双击该对象图后，详细填写该用例的描述（documentation）。6、 在每个用例下必须组织建立相应的顺序图（sequence diagram），对于一个用例可以包含多个顺序图（sequence diagram），各个顺序图（sequence diagram）的命名需在一般的中文概括前增加代表本节编号的部分，如“1.1用户认证”，顺序编号，其中第一个1代表所属的用例，第二个1代表顺序图（sequence diagram）的编号。产生顺序图的数量根据说明需求的具体要求设定。其中顺序图中的各个对象消息（object message）必须在双击该对象图后，详细填写该对象消息（object message）的描述（documentation）。4.1.3 数据存储需求【说明】根据会议纪要、小组讨论，对于在需求调研中有关的数据实体对象或数据实体信息，应当根据需要提出可能数据类型和数据长度以及单位量纲的记录或建议。5 运行环境【说明】本章只提出运行环境的逻辑结构，物理结构将在《概要设计说明书》中给出。 容许提出几种可选方案。5.1 硬件平台【说明】指出本应用软件适用的主机/服务器与终端/工作站的技术指标、基本配置、接口特点、特殊约定等。应尽可能地说明上述设备在各级用户机构预计的分布状态。5.2 网络平台【说明】选型标准、网络类型、基本部件、接口情况、对综合布线的要求、限制条件等。应画出网络（广域网、局域网）的拓扑结构图，说明后者对前者的接入方式。5.3 软件平台【说明】操作系统的名称、生产厂家、版本号等。 数据库的名称、生产厂家、版本号等。 数据库设计工具的名称、生产厂家、版本号等。 网络通信协议的名称、生产厂家、版本号等。 前端开发工具的名称、生产厂家、版本号等。 测试开发工具的名称、生产厂家、版本号等。 现场运行时需要的工具软件的名称、生产厂家、版本号等。 配置管理工具软件的名称、生产厂家、版本号等。6 附录【说明】列出基础素材中的文件、报表、单据等的样张，再附上必要的注释。如果条件成熟，可以把数据字典（data dictionary）作为附件列于后。6.1 电子文档编写方式与使用工具【说明】编写要求、工具名、版本号、操作系统平台。使用多种工具时，应分别说明。形如： Microsoft Word 97 for Windows 95/98 Power Designer 6.0 for Windows 95/98 Rational Rose 98 for Wintel Visio或Power Point 97 for Windows 95/986.2 定义说明与符号【说明】包括对专用术语及缩略语的解释、所用到的图（如use case、sequence图）之图符的表示与解释等。6.3 参考资料【说明】格式：作者， 。其中，《质量保证计划》是必选的参考资料。6.4 有关表格清单【说明】列出用户提供的素材，加上我们积累的有关文件，作为系统分析的基础。在这里除系统内部没有用户参与的需求分析工作外，必须包括一个以上的用户访谈纪要、用户确认签名文件以及用户访谈计划等文件的列表。在列表中的文件应当作为附件与需求文档共同纳入配置管理
需求分析如何来做
1．引言 31.1编写目的 31.2项目背景 31.3定义 31.4参考资料 32．任务概述 42.1目标 42.2运行环境 42.3条件与限制 43．数据描述 53.1静态数据 53.2动态数据 63.3数据库介绍 63.4数据表 63.5数据采集 64．功能需求 74.1功能划分 74.2功能描述 74.2.1采购管理 74.2.2器具管理 84.2.3检定管理 84.2.4台帐管理 94.2.5维修管理 94.2.6环境因素管理 95．性能需求 105.1数据精确度 105.2时间特性 105.3适应性 106．性能需求 106.1用户界面 106.2硬件接口 106.3软件接口 106.4故障处理 107．其它需求 11
大话软件工程：需求分析与软件设计（二十二）
将前述所有章节的交付物成果进行汇总，形成一套包括各个阶段的分析与设计资料的规格书，建立起软件工程的各个阶段与交付物的关联关系。 需求调研阶段的成果汇总为需求调研资料汇总，也就是将所有的调研成果汇总成册，主要内容如下（不限于此）。 （1）背景资料：通过从客户的网站、印刷资料、人员交流等方式获得的客户相关资料。 （2）问卷资料：调研前向客户发出的问卷。 （3）现状构成图：客户提供的或是根据客户现状绘制的业务框架图、流程图等。 （4）访谈记录：用文字记录的客户需求（目标／业务／功能需求、难度、痛点等）。 （5）既存表单：收集客户日常用各类报表、单据以及分析资料等（电子、纸质）。 （6）需求4件套：针对部分已知的功能需求做的详细记录。其中，（3）～（6）项为需求分析阶段的正式输入资料。 现状构成图包括业务和管理两个方面的内容 1．现状构成图 记录客户现状的模型主要有两类，即： （1）业务类（业务架构模型）：框架图、分解图和流程图； （2）管理类（管理架构图） 2．现状构成图一览 对于收集和绘制的现状构成进行整理，形成现状构成图一览 文字记录的资料重点有调研前的问卷和访谈记录两类。 1．需求调研问卷（模板）问卷模板可以采用两种形式，一种是以填写为主，另外一种是以选择为主。根据内容判断采用哪一种 2．访谈记录一览（模板）访谈记录用的模板与记录一览可合为一体，形成访谈记录一览。 1．资料收集 将收集到的原始资料在现场进行分析，并给出关系分析图。 2．既存表单一览 将收集到的既存表单汇总成一览 在现场对既存表单等进行详细记录（采用需求4件套的形式） 需求调研阶段的交付物是需求规格说明书，也就是将所有的调研成果汇总成册，主要的内容如下（不限于此）。 （1）需求规格说明书／解决方案。 （2）功能需求一览。 （3）需求调研资料汇总：需求调研的阶段成果。 （4）需求分析过程资料：目标需求→业务需求→功能需求的转换过程记录。 其中，（1）～（3）项为概要设计阶段的正式输入资料；（4）为参考资料，它的转换结果已经归入到功能需求一览中。 需求工程的结束是以完成需求规格说明书为标志的。需求规格说明书是基于需求调研和分析的成果汇总而成的，它是客户和软件开发者双方之间关于待开发系统的共同认知，它是后续系统的设计、开发以及验收的依据。一般来说，需求规格说明书中要包含对软件和硬件两方面的要求，由于本书的主题是分析与设计，因此只涉及在需求工程中讲到的内容和成果。另外，需求规格说明书对于不同的软件企业有不同形式的模板，但不论是什么样的模板，处于模板核心位置的都是需求工程中介绍到的内容。这部分内容是客户投资信息化系统的核心需求，也是后续设计工程中主要的设计对象，是带来最大客户价值的部分。以下需求规格说明书的框架中主要包括与软件的业务设计、应用设计相关的需求。这个框架仅作为参考，实际使用时需要另行加入其他部分（包括：技术、硬件）的内容。需求规格说明书至少要包含4个核心部分，各部分的重点如下。 第一部分 引言：所有需要在事前声明的内容，如前言、原则、定义、范围等信息。 第二部分 背景：直接来源于客户的主观信息，如背景、现状、目标、期望等信息。 第三部分 需求：对需求的综合描述，这些内容是设计工程的辅助参考信息。 第四部分 功能：对需求分析成果的罗列，它们是设计工程的主要依据信息。 注：需求规格说明书与设计规格书的区别 需求规格说明书是需求工程完成时的交付物，这个阶段只是对需求进行了梳理、汇集、分析，但是并未对需求按照软件设计的标准进行设计。它是设计规格书的输入。设计工程的设计规格书是对需求规格说明书的内容按照软件设计标准进行的设计成果。它是对后续技术设计、开发的输入。 解决方案，重点是针对有“定制”的需求做出的特殊说明，项目整体是定制的对象，也可以是项目中某个部分内容的是定制的。解决方案的重点在于说明： （1）客户最为关心的内容，如创新、难点、痛点、高价值的功能等。 （2）开发者比其他同行的优越之处。 （3）对客户需求的解决思路、对客户价值的认知、设计思路／理念等。 解决方案与需求规格说明书两者的区别如下。 （1）需求规格说明书是对需求的“规格”级说明，而且是全面详细的。而解决方案是针对咨询结果做出的“概要”级说明，只对客户关心的重点进行说明。 （2）两者形成的时间顺序，通常是先有解决方案（作为原则性的粗稿），在获得客户认可后，再进行深入调研之后，再继续做出需求规格说明书。特殊情况下，也可以是在有了需求规格说明书后，从中抽取部分内容形成解决方案，向客户介绍他们特别关心的内容。 需求分析完成后，最重要的输出之一就是功能需求一览，这个表给出了需要开发的功能需求参考，也是后期在设计、开发时判断工作量、难度、资源以及进度计划的主要参考依据。 进入设计工程后，第一阶段的设计就是概要设计，概要设计阶段的交付物概要设计规格书中包括三层的内容：架构、功能和数据，主要内容包括以下三种。 （1）架构概要规格书：业务架构图（拓扑图、分层图、框架图、分解图、流程图）。 （2）功能概要规格书：功能的分类与分类图、功能的规划与关联图、业务功能一览等。 （3）数据概要规格书：数据规划、编号标准、数据标准、主数据。 1．理念、主线与标准 架构的概要设计包括整体设计的理念、主线，以及各类交付物的标准和规范。理念：设计师对系统的顶层设计的构想、方向。主线：以价值为目标，串联起达成目标的功能。标准：架构模型在架构设计中需要遵循的要求。 2．业务架构图 架构图主要采用5种模型。 3．业务架构图一览 将完成的业务架构图汇总成业务架构图一览 功能概要规格书主要包括两个资料：一是功能关联图，二是业务功能一览。 1．功能关联图 按区、线、点等进行功能规则，绘制功能关联图。 2．业务功能一览 业务功能一览可以根据内容的多少和复杂度，将业务功能全部归为一个表（包括：活动、字典、看板和表单），也可以按照不同的业务功能各成一表。 1）业务功能一览（合成） 合成的业务功能一览 2）业务功能一览（业务功能类别） 按不同业务功能划分的业务功能一览 活动功能一览 字典功能一览 看板功能一览 表单功能一览 1．数据规划图 数据规划主要分为三个粒度：整体、领域和模块 2．数据标准 （1）业务编号的标准：用文字说明编制标准。 （2）业务数据的标准：用文字说明编制标准。 （3）主数据的选择：用文字或表说明选择标准和结果。 详细设计阶段的交付物详细设计规格书的内容包括三层的内容：架构、功能和数据，以及业务用例。 （1）业务流程规格书：业务流程的详细设计（流程5件套）。 （2）业务功能规格书：业务功能的详细设计（业务4件套）。 （3）业务数据规格书：包括数据关系表、数据模型（关联图、勾稽图、数据线）等。 （4）业务用例：对概要、详细和管理设计成果的验证用例。 业务流程的详细设计成果是业务流程规格书（流程5件套） 对于业务功能（活动、字典、看板和表单）的描述是基于需求工程的“需求4件套”进行的详细设计，形成“业务4件套”。 数据的详细设计成果主要有两个：一是数据表关系图，二是数据模型。 1．数据表关系图 2．数据模型 对概要设计、详细设计以及管理设计的成果，用业务用例的方式进行验证。主要模板有两个，一是用例导图，二是用例数据推演表 应用设计阶段的交付物应用设计规格书的内容包括三层的内容：架构、功能和数据，以及应用用例。 （1）架构应用规格书：业务流程机制、业务架构的转换等。 （2）功能应用规格书：对业务组件的设计（组件4件套），业务组件一览。 （3）数据应用规格书：数据复用、数据共享、数据格式转换（文字→数字）。 （4）应用用例：对应用设计成果的验证用例。 架构的应用设计的成果主要分为两类：一是对业务架构图的转换，二是架构层面的各类“机制”图设计。 1．业务架构图的转换 2．架构的机制设计图 架构的机制设计图根据项目的复杂度而定，不是必做的内容 对于业务组件的描述是基于功能的详细设计“业务4件套”进行的应用设计，形成“组件业务4件套”。 数据的应用设计的成果主要根据系统的内容而定，不是必需的，例如可以设计数据的复用机制、数据的共享机制，以及数据的转换机制等内容 对应用设计以及管理设计的成果，用应用用例的方式进行验证。主要模板有两个，一是应用用例导图，二是数据关系图
