怎样做需求分析之十七：分析之非功能性需求
作者: fangang发布时间: 2012-04-25 13:16
我曾经看过许多关于需求分析的书籍，老外写的，国人写的，都有。但我总体就是一个感觉：累。各种各样的分析、各种各样的视图，让人眼花缭乱。为什么会这样呢？不得不说，需求分析是一个太宽泛的概念了，不同的行业（商业的、管理的、游戏的），不同类型的软件（底层的、桌面的、网络应用的），不同的设计方式（面向过程的、面向对象的），需求分析的过程都存在着巨大的差异。要制订放之四海而皆准的方法谈何容易。即使同一类型的软件，它们也存在着各自的特点，有的问题大多数软件都不用考虑，而它必须考虑。正因为如此，许多关于需求分析的方法和书籍描述得挺复杂的。
但我要说，我们做需求分析应当化繁为简，不必去拘泥于那些过程。怎样化繁为简？寻找适合自己的，避免做过度分析和设计，这种思想也是敏捷开发的精髓。比如我所从事的管理软件的研发，关注业务流程、关注业务实体、关注规则约束，功能方面的需求就分析完成了大半。然后再关注查询报表、关注外部接口、关注打印导出等细小功能，功能方面就差不多了。
但是，我不得不说，需求分析人员最容易忽略的部分就是非功能需求。非功能需求更加靠近的是技术，是设计，是实现，是架构师关注的内容，是需求人员最不擅长的方面，这也是非功能需求为什么常常被忽略的重要原因。正因为如此，架构师应当尽早参与到项目中，参与到需求分析中，尽早分析需求的技术可行性，尽早考虑性能、安全性、可靠性等非功能需求，尽早开始架构设计。
在非功能需求分析中另一个非常常见的错误，就是将非功能需求仅仅归结为一些放之四海而皆准的原则，比如专门拿出一章来描述报表查询效率要怎样、系统易用性要怎样。诚然，这些原则性的东西是十分必要的，但许多非功能需求不能仅仅停留在这些基本原则上，要落实到对一个一个功能的分析中。
说这么多虚的，咱们还是上实例吧。还是这个考核系统，每天在上班后1小时内，将有90%的用户会上线查看自己的考核结果。因此，在进行考核结果查询功能的分析中，我们写下了这样的话：查询必须高效（预计查询数据量：xxx），并且支持高并发操作（预计并发用户峰值：xxx）。有了这些描述，设计和开发人员会着重注意该功能的性能问题，测试人员也可以着重进行该部分的性能测试。
在另一个项目中，用户需要对大量的数据进行选择，进而完成制作清册、下派、回退等操作。
在前期的需求分析中，需求人员没有仔细分析这些操作的易用性，没有提供给用户批量选择等功能，直到试运行时才发现。当时系统到各基层试运行时，激起了巨大的民怨，给项目带来了巨大的负面影响。多亏我们及时发现问题，加班加点完成了相关操作的批处理功能，才使项目得以顺利推行。如此看来，非功能需求对于一个软件项目是多么重要。因此，我建议，在需求分析的细化阶段，需求分析人员应当与架构师一起，一项一项地去分析每个功能的非功能需求，并在用例说明中记录下有特殊非功能需求的功能，使我们对非功能需求的分析落到实处。
那么哪些是非功能需求呢？我们可以简单归纳为“URPS+”，即可用性（Usability）、可靠性（Reliability）、性能（Performance）、可支持性（Supportability）以及其它（+）。而这5部分我们可以进一步细化。
可用性是一个非常宽泛的概念，它泛指那些能让用户顺利使用系统的指标，包括易用性（易操作、易理解）、准确性、安全性（权限体系、访问限制）、兼容性（服务器、客户端的兼容度），等等。
可靠性就是系统可以可靠运行，包括系统成熟度（数据吞吐量、并发用户量、连续不停机性能等）、数据容错度、系统易恢复性，等等。
性能，我认为是需求分析阶段最主要的分析内容。用户对性能的要求没有止境，但现实却是残酷的。性能受到许多因素的影响，包括业务需求、软件设计、数据库设计、系统部署方式，等等。其中，业务需求和部署方式，对性能的影响是最大的，我们必须在需求分析阶段就想清楚，解决掉。有一次，客户提出了一个数据导出的功能，这看似一个非常普通的功能。但是经过仔细地分析我们发现，客户在执行数据导出前的查询时，如果选择时间跨度数年，查出的数据量可能达到数十万。要将数十万数据一次性地导入到一个excel文件中，这不论从运行效率、系统稳定性，还是技术可行性分析都是不可取的。最后，我们经过与客户的协商，一次性导出数据最大不超过2万，同时提供了分页导出的功能，可以让他们选择导出从第几页到第几页的数据。这样，如果数据量大，客户可以经过多次将数据导出，数据导出的性能得以保证。
系统部署架构对性能的影响也是巨大的。一个管理系统，是市级集中，还是省级集中，甚至全国集中，对性能的考量是不一样的。市级集中不会过于担心性能的问题；省级集中就必须要考量并发访问量，是否要建立集群；全国集中就必须考量是否使用消息队列，所有流程是否有性能瓶颈，以及采用什么技术架构更适于并发访问等等。而这一切都是系统架构师应当考量的内容。
最后一个内容，也是最容易被忽略的一个内容，就是可支持性。可支持性，就是软件的可维护性、易变更性。可支持性对于客户是透明的，不可见的，因此客户通常不关心这个。由于时间紧、人员素质参差不齐，这部分也常常为管理者所忽略。但试问，谁没有维护糟糕系统的痛苦经历？谁们的系统维护了数年经过数次升级后还能维护？在需求分析与设计阶段，可支持性实际上体现在，我们是否能有效识别系统可变的需求，并能够提供合理的方案。这体现的也是架构师的功底。一次分析和设计ERP软件的时候，我发现应付单需要生成凭证，随后又发现应收单、采购单、销售发票都要生成凭证。既然这么多单据需要生成凭证，是否还有其它我们还不知道的单据也要生成凭证，是否可以有一个统一的接口。果不其然，核销单、工资单、固定资产核定都需要生成凭证。最后我们设计成了一个统一的生成凭证接口。还有一次，我们发现客户报表在查询SQL、过滤条件、显示列等部分经常变，因此设计成一套可配置的报表系统，大大提高了系统可维护性。
需求分析是一个撒大网的过程，而不是姜太公钓鱼的过程。功能需求固然重要，非功能需求同样重要。我们在进行非功能需求的分析时，除了制订整体的原则以外，还要落实到各个具体的功能中，将这些功能所潜在的、特殊的非功能需求挖掘出来，提前进行分析设计，对于可行性不高的应及时与客户商讨，才能有效地避免日后存在的这些方面的风险。
需求分析报告模板XXXXXXXXX 需求分析报告 XXXXXXXX SHANGHAI FUDAN JINSHIDA COMPUTER COLTD XXXXXVVV-003-XXX V.VV : XXXXXXXXXXXXX : 需求分析报告
XXXXXXXXX XXXX/XX/XX XXXXXXXXX XXXX/XX/XX XXXXXXXXX XXXX/XX/XX XXXXXXXXX XXXX/XX/XX XXXXXXXX需求分析报告上海复旦金仕达计算机有限公司 第一章引 言 ..................................................................... (1) 1.1 编写目 的 ..................................................................... . (1) 1.2 背 景 ..................................................................... (1) 1.3 术语定 义 ..................................................................... . (1) 1.4参考资 料 ..................................................................... ........................................................ 1 第二章系统概述 ..................................................................... .. (2) 2.1系统功能框 架 ..................................................................... (2)
1. 文档介绍 1.1 文档目的 为了明确客户的基本需求，更好地完成对客户需求的了解，并量化和明晰本系统的工作量和工作进度，特编写此说明书。 1.2 文档范围 该文档包括产品售后服务系统项目的介绍、面向的用户群体、系统的功能性需求及非功能性需求。 1.3 读者对象 本手册适用于与客户进行需求的沟通与确认，及所有《产品售后服务跟踪系统》的设计开发人员。 2 系统介绍 2.1 背景 随着信息技术的日益发展，产品售后服务的信息化已成为产品售后服务跟踪系统的必然趋势。产品售后服务系统的核心部分是对客户进行回访问卷调查，以确定客户对产品的评价，服务的满意度。为了更详细的了解产品售后服务过程中各项管理业务，调研人员和最终用户进行了多次讨论，并提出了双方认可的解决方案。 2.2 系统说明 产品售后服务跟踪系统主要为公司解决售后服务管理的需求，协助回访工作人员对客户进行日常回访调查和客户管理，提高管理效率，降低运作成本，增强 企业长期竞争力
通过该系统，公司系统管理人员能实现对回访用户、客户的动态管理；系统管理人员能随时了解回访用户的回访情况；回访用户能记录客户的回访记录；3. 系统面向的用户群体 系统面向产品公司的售后服务管理员，回访用户。 3.1 用户的特征 用户大都具备以下特征： ? 有IE 使用经验 ? 了解网络 ? 了解办公自动化 3.2 用户环境 用户的计算机环境大致如下： ? Microsoft Windows XP ?Microsoft Internet Explorer 6 或更高版本 ? MS Office 办公软件 ? Outlook 或Foxmail 邮件管理 ? Microsoft Windows .NET Framework 2.0 4. 系统的功能性需求 系统包含的功能概括如下表：
产品经理如何应对非功能性产品需求变 更 令人烦恼的非功能性需求变更 在软件开发中，大家都会遇到过这样的问题：客户的一个新想法，就推翻了之前与客户经过再三讨论而确认定下来的需求。如果是功能性需求变更还会让人容易接受一些，毕竟功能性需求不实现的话，是会大大影响到软件产品的质量。但现在我所负责的这个开发项目中遇到的都是一些非功能性的变更,而且许多是看起来无关痛痒的、鸡毛蒜皮的变更。 （1）什么是非功能性需求？ 在IEEE中，软件需求的定义是：用户解决问题或达到目标所需的条件或功能。一般包含业务需求、用户需求、功能需求、行业隐含需求和一些非功能性需求。业务需求反映了客户对系统、产品高层次的目标要求；功能需求定义了开发人员必须实现的软件功能。所谓非功能性需求，是指为满足用户业务需求而必须具有除功能需求以外的特性。包括系统性能、可靠性、可维护性、易用性和对技术和对业务适应性等。其中最常见的是软件界面、操作方便等一系列要求。 （2）非功能性需求变更的特点 让我们从客户角度和开发人员角度去看看非功能性需求的特点。首先，有些非功能性小需求从客户角度看起来工作量不大，但是实际上开发人员要耗费比较长的时间去完成这些小功能。其次，许多非功能性需求，如界面美观、操作方便等都是客户头脑一热、或领导一拍脑袋就部署下去的需求，往往是原来在需求分析阶段所没有注意的内容。
其实，非功能性需求是常常被轻视，甚至被忽视的。原因是非功能性需求描述很困难，它很难像功能性需求那样，可以通过结构化和量化的词语来描述清楚。在描述这类需求时候，我们经常采用软件性能要好、操作要方便、软件界面要美观大方等较模糊的描述词语。例如，易用性就同时涉及到美工和UI界面、人机工程、交互式设计、心理学、用户行为模式等内容。这类描述词语都是脱离了软件的执行环境，是对人和相关的场景的描述，因此很难体现到软件架构设计和具体的实现中。 为什么非功能性需求变更会频繁发生？ 为什么非功能性需求不能固定下来呢？或定下来后就不许变了呢？通常有许多人会问这样的问题。实际上，当他变成了客户时，他可能就不会问这个问题了。（1）非功能性需求容易产生理解分歧 在软件需求分析阶段，客户和开发人员对非功能性需求的理解呈现"大体上共识多，细节上差异多"的特点。一般跟分析员的知识、背景，还有客户表述的标准程度、双方的交流情况有关。即使通过反复沟通，但是以实践经验来看非功能性需求的描述还是永远不够清晰、不够明确的，主要是因为在这个阶段所谓的产品还只存在于大家的大脑构思中。 作为一个客户，大多数情况下是不懂技术的，但他所需要的软件在他的心里还是有一个印象的。他会想象出软件的样子和功能，然后通过口头或者笔头的方式告诉需求分析人员。简单的说，就是在这个阶段用户往往不能确切地定义自己需要什么。用户常常以为自己清楚，但实际上他们提出的需求只是依据当前的工作所需，或者是他们想象出来的东西。结果是当客户向需求分析人员提出需求的时候，往往是通过自己的想法用自然语言来表达的，这样的表达结果对于真实的需求来
需求分析中需求规格SRS的非功能性需求的考虑因素 * 功能性质量因素：正确性，健壮性，可靠性 * 非功能性质量因素：性能，易用性，清晰性，安全性，可扩展性，兼容性，可移植性正确性 * 正确性是指软件按照需求正确执行任务的能力。“正确性”的语义涵盖了“精确性”。 * 正确性无疑是第一重要的软件质量属性。 * 技术评审和测试的第一关都是检查工作成果的正确性。 * 机器不会主动欺骗人，软件运行出错通常都是人造成的，所以不要找借口埋怨机器有毛病。 健壮性 * 健壮性是指在异常情况下，软件能够正常运行的能力。 * 正确性描述软件在需求范围之内的行为，而健壮性描述软件在需求范围之外的行为。 * 开发者往往把异常情况错当成正常情况而不作处理，结果降低了健壮性。 * 用户才不管正确性与健壮性的区别，反正软件出了差错都是开发方的错。所以提高软件的健壮性也是开发者的义务。 * 健壮性有两层含义：一是容错能力，二是恢复能力。 可靠性 * 可靠性是指在一定的环境下，在给定的时间内，系统不发生故障的概率。 * 可靠性本来是硬件领域的术语。比如某个电子设备在刚开始工作时挺好的，但由于器件在工作中其物理性质会发生变化（如发热），慢慢地系统的功能或性能就会失常。所以一个从设计到生产完全正确的硬件系统，在工作中未必就是可靠的。 * 软件在运行时不会发生物理性质的变化，人们常以为如果软件的某个功能是正确的，那么它一辈子都是正确的。可是我们无法对软件进行彻底地测试，无法根除软件中潜在的错误。平时软件运行得好好的，说不准哪一天就不正常了，如有千年等一回的“千年虫”问题，司空见惯的“内存泄露”问题、“误差累积”问题等等。 * 时隐时现的错误一般都属于可靠性问题，纠错的代价很高。 性能 * 性能通常是指软件的“时间-空间”效率，而不仅是指软件的运行速度。人们总希望软件的运行速度高些，并且占用资源少些。 * 性能优化的关键工作是找出限制性能的“瓶颈”
需求分析报告模板文件管理序列号：[K8UY-K9IO69-O6M243-OL889-F88688]
需求分析报告模板 科技信息中心 二○一一年五月二十日
1. 引言 引言是对这份软件产品需求分析报告的概览，是为了帮助阅读者了解这份文档是如何编写的，并且应该如何阅读、理解和解释这份文档。 1.1 编写目的 说明这份软件产品需求分析报告是为哪个软件产品编写的，开发这个软件产品意义、作用、以及最终要达到的意图。通过这份软件产品需求分析报告详尽说明了该软件产品的需求规格，包括修正和(或)发行版本号，从而对该软件产品进行准确的定义。 如果这份软件产品需求分析报告只与整个系统的某一部分有关系，那么只定义软件产品需求分析报告中说明的那个部分或子系统。 1.2 项目风险 具体说明本软件开发项目的全部风险承担者，以及各自在本阶段所需要承担的主要风险，首要风险承担者包括： ●任务提出者； ●软件开发者； ●产品使用者。
1.3 文档约定 描述编写文档时所采用的标准(如果有标准的话)，或者各种排版约定。排版约定应该包括： ●正文风格； ●提示方式； ●重要符号； 也应该说明高层次需求是否可以被其所有细化的需求所继承，或者每个需求陈述是否都有其自己的优先级。 1.4 预期读者和阅读建议 列举本软件产品需求分析报告所针对的各种不同的预期读者，例如，可能包括： ●领导层及管理人员； ●开发人员； ●项目经理； ●项目的最终用户； ●测试人员； ●文档编写人员。 ●其他经许可阅读此文档的人员 并且描述了文档中，其余部分的内容及其组织结构，并且针对每一类读者提出最适合的文档阅读建议。
软件需求分析报告文档模板 目录 1. 引言 (1) 1.1编写目的 (2) 1.2项目风险 (2) 1.3文档约定 (2) 1.4预期读者和阅读建议 (2) 1.5产品范围 (2) 1.6参考文献 (3) 2. 综合描述 (3) 2.1产品的状况 (3) 2.2产品的功能 (4) 2.3用户类和特性 (4) 2.4运行环境 (4) 2.5设计和实现上的限制 (4) 2.6假设和约束(依赖) (5) 3. 外部接口需求 (5) 3.1用户界面 (5) 3.2硬件接口 (6) 3.3软件接口 (6) 3.4通讯接口 (6) 4. 系统功能需求 (6) 4.1说明和优先级 (7) 4.2激励／响应序列 (7) 4.3输入／输出数据 (7) 5. 其它非功能需求 (7) 5.1性能需求 (8) 5.2安全措施需求 (8) 5.3安全性需求 (8) 5.4软件质量属性 (8) 5.5业务规则 (8) 5.6用户文档 (8) 6. 词汇表 (9) 7. 数据定义 (9) 8. 分析模型 (9) 9. 待定问题列表 (19)
引言 引言是对这份软件产品需求分析报告的概览，是为了帮助阅读者了解这份文档是如何编写的，并且应该如何阅读、理解和解释这份文档。 1.1 编写目的 说明这份软件产品需求分析报告是为哪个软件产品编写的，开发这个软件产品意义、作用、以及最终要达到的意图。通过这份软件产品需求分析报告详尽说明了该软件产品的需求规格，包括修正和(或)发行版本号，从而对该软件产品进行准确的定义。 1.2 项目风险 具体说明本软件开发项目的全部风险承担者，以及各自在本阶段所需要承担的主要风险，首要风险承担者包括： ●任务提出者 ●软件开发者 ●产品使用者 1.3 文档约定 描述编写文档时所采用的标准(如果有标准的话)，或者各种排版约定。排版约定应该包括 ●正文风格： ●提示方式： ●重要符号： 也应该说明高层次需求是否可以被其所有细化的需求所继承，或者每个需求陈述是否都有其自己的优先级。 1.4 预期读者和阅读建议 列举本软件产品需求分析报告所针对的各种不同的预期读者，例如，可能包括 ●用户； ●开发人员； ●项目经理； ●营销人员； ●测试人员； ●文档编写入员。 并且描述了文档中，其余部分的内容及其组织结构，并且针对每一类读者提出最适合的文档阅读建议 1.5 产品范围 说明该软件产品及其开发目的的简短描述，包括利益和目标。把软件产品开发与企业目标，
非功能性需求 ) 什么是非功能性需求 非功能性需求是这样一种需求，它解决“如何使这个系统能在实际环境中运行”。 ) 重要吗？ 在设计解决方案的过程中满足功能性需求当然是很重要的。但是，如果没有考虑非功能性需求，那么这个解决方案则很难取得实效，因为用户可能难以甚至无法使用系统的功能。 很多非功能需求一般会在底层的基础技术平台去仔细设计和实现。 ) 非功能性需求要考虑那些方面 非功能性的特性一般有这些： 可靠性 只显示系统可以做某些事情是不够的。如果一个系统不能可靠地运行（例如，在加载时，或者在系统故障时，等等），则它就不能满足客户的需要。 有一些问题应该自问一下： * 即使硬件出现故障，系统也可以可靠运行吗？ * 复制和故障转移方案是什么？ * 需要手动干预，还是系统可以自动进行故障转移？ * 实现可靠性会对性能造成负面影响吗？ * 实现可靠性的成本有多高？ 可靠性需要考虑的一些具体方面是： 安全性：假设攻击者就在外面。如何知道系统用户就是他们所声称的，并只让他们访问经过授权的功能？如何保护我的系统不受攻击？考虑到网络攻击、机器攻击，甚至从您自己的系统内部发起的攻击。 事务性：如何设计系统来保存工作单元的属性？如果在设计中涉及多个独立的子系统（服务和就是这种情况），则这一点就显得特别重要。不要假设始终可以进行两阶段提交 ( )。 可用性 如果用户不能够从他们可用的渠道（例如）方便地访问您的产品，那么它的好处何在呢？这有时是作为功能性的一部分一起考虑（或者应该在理想的环境下）的，但是常常被忽视，以致于整个项目处于危险之中。这里需要考虑的一些问题是： * 您是否为用户带来不适当的负担（例如，需要特殊的浏览器版本）？ * 系统是否根据模型视图控制器 () 体系结构设计以使多用户界面成为可能？如果是这样，如何将它们绑定在一起？ * 是否界面本来就有状态而功能无状态（反之亦然）？ 有效性 如果没有有效地使用资源（例如处理器、内存和磁盘空间），功能性、可靠性和可用性再好的系统最后都会失败。我们经常发现将有效性划分成两个子范围是很有用的，这两个子范围都应该加
渭南学院电子工程生产实习电子万年历 项目需求分析报告 编号： 序号： 课题名称：电子万年历指导教师： 班级： 项目成员： 时间： 修订记录
目录 1引言错误!未定义书签。 编写目的错误!未定义书签。 项目背景错误!未定义书签。 定义错误!未定义书签。 参考资料错误!未定义书签。 2概述错误!未定义书签。 产品的描述错误!未定义书签。 产品的功能错误!未定义书签。 开发环境错误!未定义书签。 一般约束错误!未定义书签。 3具体需求错误!未定义书签。 内部功能需求错误!未定义书签。 外部接口需求错误!未定义书签。 用户界面错误!未定义书签。 硬件接口错误!未定义书签。 软件接口错误!未定义书签。 通讯接口错误!未定义书签。 性能需求错误!未定义书签。 静态数值需求错误!未定义书签。 动态数值需求错误!未定义书签。 数据词典错误!未定义书签。 数据采集错误!未定义书签。 数据精确度错误!未定义书签。 时间特性错误!未定义书签。 适应性错误!未定义书签。 设计约束错误!未定义书签。 需遵守的其它标准错误!未定义书签。 硬件限制错误!未定义书签。 属性需求错误!未定义书签。 可靠性错误!未定义书签。 安全性错误!未定义书签。 可维护性错误!未定义书签。 可移植性错误!未定义书签。 其它需求错误!未定义书签。
项目需求分析报告 关键词： 摘要： 引言 xxxxxx 编写目的 【阐明编写需求说明书的目的，指出读者对象】 项目背景 【项目的委托单位、开发单位和主管部名】 【该产品项目与其他产品或其他系统的关系】 定义 【列出文档中用到的专门术语的动议和缩写词的原文】 参考资料 【格式：作者标题编号出版单位或资料来源发表日期】 【范围：项目经核准的计划任务书；合同或上级批文；项目开发计划；与项目有关的已发表的资料；文档中所引用的资料；所采用的标准或规范】 概述 产品的描述 用与它有关的产品或项目来描述被开发项目： 如果被开发产品系统是独立的, 则应在本节描述被开发产品系统概况。 如果本产品系统是一个较大的系统或项目中的一个组成部分,那么本小节应当:简述这个较大的系统或项目的每一个组成部分的功能,并标识其接口；标识被开发产品项目的主要外部接口(建议用图形表达有关的系统或项目的主要组成、相互联系和外部接口)。 产品的功能 简明叙述被开发产品项目的功能。 开发环境 列出所采用的操作系统、编程语言、编程工具（编译器和调试器）、硬件设备、数据库平台和网络平台等开发环境特点。 一般约束 硬件的限制； 与其他应用系统的接口； 本节不列举具体需求或具体设计约束。但是, 应对具体需求一章中描述的某些具体需求和设计约束提供理由。 具体需求 内部功能需求 描述产品系统产品的输入经过什么处理转换为输出，它必须描述在产品系统中进行的基本操作。对于每一类功能或者有时对于每一个功能，需要描述其输入、处理和输出等需求。这些内容用四小节描述： 功能需求1 引言 描述完成本功能的目的，所使用的方法和技术，包括可以清楚说明本功能示意图的来源或背景材料。 输入 对本功能全部输入数据的详细描述,它们包括:输入源、数量、度量单位、时间关系、有效输入的范围、精度和公差等。 操作员具体的控制需求，其中包括操作员活动的描述，控制台或操作员的位置等。例如，在打印表格时，要求操作员调整打印纸位置的需求。 指明引用的接口规格说明或相应的接口控制文档。 处理 说明该功能应该对各输入数据进行哪些处理，并对各处理进行定性的说明，尽可能采用严格的定
附录A软件需求分析报告文档模板 1. ........................................................................................................................................................ 引言2 1.1编写目的 (2) 1.2项目风险 (2) 1.3文档约定 (2) 1.4预期读者和阅读建议 (2) 1.5产品范围 (3) 1.6参考文献 (3) 2. 综合描述 (3) 2.1产品的状况 (3) 2.2产品的功能 (4) 2.3用户类和特性 (4) 2.4运行环境 (4) 2.5设计和实现上的限制 (4) 2.6假设和约束（依赖） (5) 3. 外部接口需求 (5) 3.1用户界面 (5) 3.2硬件接口 (6) 3.3软件接口 (6) 3.4通讯接口 (7) 4. 系统功能需求 (7) 4.1说明和优先级 (7) 4.2激励/响应序列 (8) 4.3输入/输岀数据 (8) 5. 其它非功能需求 (8) 5.1性能需求 (8) 5.2安全措施需求 (9) 5.3安全性需求 (9) 5.4软件质量属性 (9) 5.5业务规则 (9) 5.6用户文档 (9) 6. 词汇表 (10) 7. 数据定义 (10) 8. 分析模型 (11) 9. 待定问题列表 (11)
1. 引言 引言是对这份软件产品需求分析报告的概览，是为了帮助阅读者了解这份文档是如何编 写的，并且应该如何阅读、理解和解释这份文档。 1.1编写目的 说明这份软件产品需求分析报告是为哪个软件产品编写的，开发这个软件产品意义、作用、以及最终要达到的意图。通过这份软件产品需求分析报告详尽说明了该软件产品的需求规格，包括修正和（或）发行版本号，从而对该软件产品进行准确的定义。 如果这份软件产品需求分析报告只与整个系统的某一部分有关系，那么只定义软件产品 需求分析报告中说明的那个部分或子系统。 1.2项目风险 具体说明本软件开发项目的全部风险承担者，以及各自在本阶段所需要承担的主要风险， 首要风险承担者包括： ?任务提出者； ?软件开发者； ?产品使用者。 1.3文档约定 描述编写文档时所采用的标准（如果有标准的话），或者各种排版约定。排版约定应该包 括： ?正文风格； ?提示方式； ?重要符号； 也应该说明高层次需求是否可以被其所有细化的需求所继承，或者每个需求陈述是否都 有其自己的优先级。 1.4预期读者和阅读建议 列举本软件产品需求分析报告所针对的各种不同的预期读者，例如，可能包括： ?用户； ?开发人员； ?项目经理； ?营销人员； ?测试人员； ?文档编写入员。 并且描述了文档中，其余部分的内容及其组织结构，并且针对每一类读者提出最适合的
需求分析与测试的重要性 读《软件工程案例教程》有感 对于学习软件工程这门课程，我认为有许多东西要学习。其实在我看来学习这门课程的精髓是学习一种方法。是一个如何去分析和处理问题的过程，应该说其范畴已经远远不止局限于该门课程，成为了一个综合的一个能够解决问题的思想集合。读完软件工程案例教程这本书，我觉得自己受益匪浅。 整本书的内容逻辑很清晰明了，由浅入深循序渐进，首先我就大概描述下我们所学的内容，第一章是从整体分析软件工程这门学科的发展和所处的社会环境，接着后面的几章深入分析了软件开放过程和模式、软件项目管理、计算机工程、需求分析、结构化分析建模以及基于UML面向对象分析建模和测试等。对于这本书我主要对需求分析和测试比较感兴趣，在这我要着重的谈一些自己的心得体会以及自己的看法。 一．需求分析 1.1需求分析的重要性 一款成功的软件是建立在成功的需求分析之上的，而高质量的需求来源于用户与开发人员之间有效的沟通与合作。当用户有一个问题可以用计算机系统来解决，而开发人员开始帮助用户解决这个问题，沟通就开始了。由此我们可以看出需求分析的重要性。 需求获取可能是最困难、最关键、最易出错及最需要沟通交流的活动。对需求的获取往往有错误的认识：用户知道需求是什么，我们所要做的就是和他们交谈从他们那里得到需求，只要问用户系统的目标特征，什么是要完成的，什么样的系统能适合商业需要就可以了，但是实际上需求获取并不是想象的这样简单，这条沟通之路布满了荆棘。首先需求获取要定义问题范围，系统的边界往往是很难明确的，用户不了解技术实现的细节，这样造成了系统目标的混淆。 其次是对问题的理解，用户对计算机系统的能力和限制缺乏了解，任何一个系统都会有很多的用户或者不同类型的用户，每个用户只知道自己需要的系统，而不知道系统的整体情况，他们不知道系统作为一个整体怎么样工作效率更好，也不太清楚那些工作可以交给软件完成，他们不清楚需求是什么，或者说如何以一种精确的方式来描述需求，他们需要开发人员的协助和指导，但是用户与开发人员之间的交流很容易出现障碍，忽略了那些被认为是"很明显"的信息。最后是需求的确认，因为需求的不稳定性往往随着时间的推移产生变动，使之难以确认。为了克服以上的问题，必须有组织的执行需求的获取活动。 1.2需求分析的原则 （1）需求分析必须能够表达和理解问题的数据域和功能域。数据域包括数据流、数据内容和数据结构，而功能域反映上述3方面的控制信息。 （2）需求分析要把一个复杂问题按功能进行分解并逐层细化。通常，软件系统要处理的问题如果太大、太复杂就很难理解，若划分成几部分，并确定各部分间的接口，就可完成整体的功能。在需求分析过程中，软件系统的用户需求中的数据、功能和行为都应细化。 （3）需求建模。模型可以帮助系统分析人员更好地理解软件系统的数据、功能和行为，这些模型是软件工程中下一阶段进行系统设计的基础。 1.3需求分析的注意事项
释放办公激情，效能触手可及嘉为IT咨询培训0 非功能性需求——性能需求分析 软件的非功能性需求是衡量软件质量很重要的一个因素，同时也决定了功能相似的条件下不同软件的价格。比如，一个同时能处理一万用户请求的网站的技术要求和一个没考虑过这方面问题的网站相比就有天壤之别。然而实际工作中，非功能性需求却常常被忽略，或者制定得非常随意。那么非功能性需求应该怎么制定，又如何验收呢？ 下面我们以常见的非功能性需求——性能需求为例，介绍一下非功能性需求应该怎么制定和验证。 在许多网站开发项目中我们都会在合同或者招标说明中看到“本网站必须能同时满足多少用户的使用”，这就是一个针对性能的非功能性需求，不过这个需求定义的非常不专业。 首先，对于一个服务器系统来说同时在线的用户，或者并发用户数并不是一个清晰的概念。在线用户或者更具体的——和服务器保持连接的用户，如果不进行操作，那么除了占用一点服务器内存外没有任何开销。用户只有执行了向服务器发起请求在操作，服务器才需要消耗CPU、硬盘、网络和更多的内存资源来响应这些请求。因此性能指标应该使用每秒请求数来标定。虽然每秒请求数通常和并发用户数成正比，但由于应用不同、用户使用方式不同等原因。即使是同类型网站并发用户数和每秒请求数的比例也有很大的差别。具体的数字是多少就需要进一步的需求分析才能确定。 其次，这个需求没有限定系统响应时间。响应时间是性能需求中另一个重要指标。正确的性能需求是通常以一定平均响应时间条件下服务器的极限指标来描述的。 好了，我们知道制定性能需求需要每秒请求数和响应时间两个数值。那么这两个数值如何制定才合理呢？需要注意的是性能指标不是越高越好，高性能通常需要复杂的实现技术、更高的部署成本和更多的维护工时。因此制定性能需求绝对不能拍脑袋。 做性能需求分析通常有这么几个步骤： 1、确定参照系统 2、测量参照系统的性能指标 3、预测目标系统 4、计算目标系统性能指标 参照系统是一个和目标系统类似并且已经存在的系统。通常将要被目标系统替换的老系统就是一个很好的参照系统。需要注意的是如果新系统的业务或者技术基础变化很大，那么旧系统未必是一个好的参照系统。 测量参照系统的性能指标通常比较容易，比如对于IIS网站来说，打开日志记录至少一个业务周期（比如一周）或者几个典型时段的数据，然后可以使用各种专业工具进行分析。从这些日志我们很容易得到所谓的用户数和每秒请求数的关系，以及系统响应时间等参数。简单的统计有时甚至通过自行编写的程序来完成。 有了基本的参照数据，那么接下来拍脑袋决定的目标系统预测也会相对靠谱。最后计算目标系统的指标就是一些普通的算术问题了。
附录A 软件需求分析报告文档模板 1. 引言 (2) 1.1编写目的 (2) 1.2项目风险 (2) 1.3文档约定 (2) 1.4预期读者和阅读建议 (2) 1.5产品范围 (3) 1.6参考文献 (3) 2. 综合描述 (3) 2.1产品的状况 (3) 2.2产品的功能 (4) 2.3用户类和特性 (4) 2.4运行环境 (4) 2.5设计和实现上的限制 (4) 2.6假设和约束(依赖) (5) 3. 外部接口需求 (5) 3.1用户界面 (5) 3.2硬件接口 (6) 3.3软件接口 (6) 3.4通讯接口 (7) 4. 系统功能需求 (7) 4.1说明和优先级 (7) 4.2激励／响应序列 (8) 4.3输入／输出数据 (8) 5. 其它非功能需求 (8) 5.1性能需求 (8) 5.2安全措施需求 (9) 5.3安全性需求 (9) 5.4软件质量属性 (9) 5.5业务规则 (9) 5.6用户文档 (9) 6. 词汇表 (10) 7. 数据定义 (10) 8. 分析模型 (11) 9. 待定问题列表 (11)
1. 引言 引言是对这份软件产品需求分析报告的概览，是为了帮助阅读者了解这份文档是如何编写的，并且应该如何阅读、理解和解释这份文档。 1.1 编写目的 说明这份软件产品需求分析报告是为哪个软件产品编写的，开发这个软件产品意义、作用、以及最终要达到的意图。通过这份软件产品需求分析报告详尽说明了该软件产品的需求规格，包括修正和(或)发行版本号，从而对该软件产品进行准确的定义。 如果这份软件产品需求分析报告只与整个系统的某一部分有关系，那么只定义软件产品需求分析报告中说明的那个部分或子系统。 1.2 项目风险 具体说明本软件开发项目的全部风险承担者，以及各自在本阶段所需要承担的主要风险，首要风险承担者包括： ●任务提出者； ●软件开发者； ●产品使用者。 1.3 文档约定 描述编写文档时所采用的标准(如果有标准的话)，或者各种排版约定。排版约定应该包括： ●正文风格； ●提示方式； ●重要符号； 也应该说明高层次需求是否可以被其所有细化的需求所继承，或者每个需求陈述是否都有其自己的优先级。 1.4 预期读者和阅读建议 列举本软件产品需求分析报告所针对的各种不同的预期读者，例如，可能包括： ●用户； ●开发人员； ●项目经理； ●营销人员； ●测试人员； ●文档编写入员。 并且描述了文档中，其余部分的内容及其组织结构，并且针对每一类读者提出最适合的
*功能需求和非功能需求* 软件产品的需求可以分为功能性需求和非功能性需求，其中非功能性需求是常常被轻视，甚至被忽视的一个重要方面。其实，软件产品非功能性定义不仅决定产品的质量，还在很大程度上影响产品的功能需求定义。如果事先缺乏很好的非功能性需求定义，结果往往是使产品在非功能性需求面前捉襟见肘，甚至淹没功能性需求给用户带来的价值。 所谓非功能性需求，是指软件产品为满足用户业务需求而必须具有且除功能需求以外的特性。软件产品的非功能性需求包括系统的性能、可靠性、可维护性、可扩充性和对技术和对业务的适应性等。下面对其中的某些指标加以说明。 1．系统的完整性 系统的完整性指为完成业务需求和系统正常运行本身要求而必须具有的功能，这些功能往往是用户不能提出的，典型的功能包括联机帮助、数据管理、用户管理、软件发布管理和在线升级等。 并不是所有的系统都必须包括以上所有的功能，而是可以根据产品的使用环境和企业的产品发展决策进行挑选。例如，在线升级、软件发布管理适用于具有Internet或内网环境的软件产品；数据管理对于产生数据存储的产品则是必须的，设计人员不应假设用户同时是一个合格的DBA。而且系统所产生信息的分布和关系，也不是DBA所应该了解的内容。因此完整的系统应该包括数据备份、恢复、日志管理及垃圾数据清除等基本功能，哪怕这些功能的核心只是一条语句或命令；用户管理功能是另一项必不可少的功能，它定义哪些用户可以以什么样的功能使用系统。好的用户管理功能不仅可以有效控制用户对系统的使用，使系统处于一个安全且负载合理的运行状况，还能提高系统的应用适应性。 2．系统的可扩充性与可维护性 指系统对技术和业务需求变化的支持能力。当技术变化或业务变化时，不可避免将带来系统的改变。不仅要进行设计实现的修改，甚至要进行产品定义的修改。好的软件设计应在系统架构上考虑能以尽量少的代价适应这种变化，常用的技术有面向对象的分析与设计及设计模式。 3．技术适应性与应用适应性 系统的适应性与系统的可扩充性和可维护性的概念相似，也表现产品的一种应变能力，但适应性强调的是在不进行系统设计修改的前提下对技术与应用需求的适应能力，软件产品的适应性通常表现为产品的可配置能力。好的产品设计可能要考虑到运行条件的变化，包括技术条件（网络条件、硬件条件和软件系统平台条件等）的变化和应用方式的变化，如在具体应用中界面的变化、功能的剪裁、不同用户的职责分配和组合等。 对以上重要的非功能性需求进行逐一分析后，即可开始进行产品功能设计。实际上，非功能性需求定义将反映到系统的功能设计中，表现为系统的架构。
市场需求分析报告MKT_CD_T_0005 V1.0 深圳市xx电子股份有限公司
修订记录
目录 市场需求分析报告 (1) 1前言 (4) 2客户期望分析 (5) 2.1 客户的Wants&Needs (5) 2.2 客户需求分析和总结 (5) 3细分市场特征需求分析 (5) 3.1 ××细分市场1 (5) 3.1.1 ××细分市场宏观层面需求分析 (5) 3.1.2 ××细分市场细节层面需求分析 (5) 3.1.3 网络位置和网络结构..................................................... 错误！未定义书签。 3.1.4 对接设备及接口 (6) 3.1.5 产品主要需求总结 (6) 3.2 ××细分市场2 (6) 3.2.1 ××细分市场宏观层面需求分析 (6) 3.2.2 ××细分市场细节层面需求分析 (6) 3.2.3 网络位置和网络结构..................................................... 错误！未定义书签。 3.2.4 对接设备及接口 (6) 3.2.5 产品主要需求总结 (6) 4目标市场准入需求分析 (7) 4.1.1 准入要求 (7) 4.1.2 测试标准 (7) 4.1.3 准入需求描述 (7) 5解决方案配套需求分析 (7) 5.1 解决方案配套描述 (7) 5.2 配套要求总结 (7) 6E2E交付需求分析 (8) 7商业模式需求分析 (8) 8价格需求分析 (8) 9现有产品组合需求满足度评估分析 (8) 9.1 我司市场需求满足度评估 (8) 9.2 竞争对手市场需求满足度评估 (9) 9.3 竞争力需求分析 (9) 10需求汇总和策略分析 (9) 11文档评审Checklist (9) XXX 产品市场需求分析报告
〈项目名称〉业务需求-非功能性需求 版本 <1.0> 文档编号： 当前版本： 1.0 修改日期：
修订文档历史记录
目录 1.简介4 1.1目的4 1.2范围4 1.3定义、首字母缩写词和缩略语4 1.4参考资料4 2.性能4 2.1交易响应时间4 2.2用户数5 2.3吞吐量需求5 2.4数据存储容量6 3.可扩展性6 4.伸缩性6 5.安全性7 5.1应用安全性需求7 5.1.1认证与授权服务7 5.1.2资源访问控制服务7 5.1.3应用日志7 5.2基础级安全需求7 5.2.1防火墙保护7 5.2.2防病毒服务7 5.2.3数据安全7 5.2.4入侵检测及漏洞扫描7 5.2.5数据传输服务7 6.可用性7 7.易用性8 8.可靠性8 8.1计划维护服务时间8 8.2单点故障对系统的影响程度8 8.3可恢复性8 8.3.1停机恢复8 8.3.2程序和数据的备份8 8.3.3灾难恢复8 9.业务约束9 9.1<业务约束-001>业务组织架构9 9.2<业务约束-002>语言要求9 10.技术约束9 10.1<技术约束-001>客户端规范9 10.2<技术约束-002>服务器规范9 10.3<技术约束-003>网络环境规范10 10.4<技术约束-004>外设规范10 10.5<技术约束-005>开发规范10
[说明：文档模板中蓝字部分为模板说明和示例，黑字部分为内容要求。黑字部分不允许删除，对于对项目不适用的部分，在相应的章节中进行说明。] 1.简介 1.1目的 [阐明业务需求文档中，非功能性需求文档的目的。] 1.2范围 [包括所有的非功能性需求。] 1.3定义、首字母缩写词和缩略语 [本小节应提供正确理解此非功能性需求文档所需的全部术语、首字母缩写词和缩略语的定义。这 些信息可以通过引用项目词汇表来提供。] 1.4参考资料 [列出与本业务有关的一些参考资料，以备出现业务疑问时，可以方便地追根溯源。每个文档应标 有标题、报告号（如果适用），如需要，列出文档的日期和发布组织。列出可从中获取这些引用的来 源。这些信息可以通过引用附录或其他文档来提供。] 2.性能 [与性能有关的非功能需求由以下几个单独的子需求组成：] 2.1交易响应时间 [交易可以定义为：一个交易是指一个单一角色跨越系统边界触发一个事件并执行一定数量的处 理和数据库访问。交易响应时间指完成目标系统中的交互或批量处理所需的响应时间。 根据业务处理类型的不同，本规范把交易划分为三类：交互类业务、查询类业务和大数据量批 处理类业务，并根据交易类别分别给出响应时间要求的参考值，包括峰值响应时间、平均响应时间。] ●交互类业务 [交互类业务的响应需求。] ●查询类业务 [查询类业务的响应需求，可以包括一些对信息进行分析的需求。] ●大数据量、批处理业务
需求分析报告 版本：1.0.0 编者年月日审核年月日批准年月日 X X X 二〇二〇年五月
一、引言 1.1 编写目的 对产品或项目进行定义，包括修正或发行版本号。如果这个软件需求规格说明只与整个系统的一部分有关系，那么只定义文档中要说明的部分或子系统。 1.2 背景说明 说明项目或模块开发背景。 1.3 预期读者和阅读建议 列举软件需求规格说明书所针对的不同读者，如用户、设计人员、编程人员、测试人员、项目经理、市场人员等。指出最适合于每一类型读者阅读文档的建议。 1.4 术语定义 解释需求说明书中的术语、名词、简称及缩写等等。 1.5 参考文献 列出所有参考资料、参照的软件名称，包括标题名称、作者、版本号、日期、出版单位或资料来源，以方便读者查阅这些文献。 二、任务概述 2.1 目标 描述项目或业务模块要达到的目标。
2.2 用户特点 描述主要的用户及其特点（教育水平、经验、计算机水平等）。确定可能使用该产品的不同用户类别并描述它们的特征。有些需求可能只与特定的用户类相关。将该产品的重要用户类与那些不太重要的用户类区分开。 2.3 假定和约束 一般约束、假设及对用户的要求。 三、业务功能概要描述 3.1 现有系统分析 对现有系统（包括自动或人工的）进行简要分析。 3.2 业务描述 描述实际业务的过程和特点，即业务建模。 3.3 系统角色 画出系统中的角色，并用文字进行说明。 3.4 主题描述（或：系统用例视图） 画出主题图，描述主题内的业务和主题间的业务。 或用UML语言描绘系统总的用例视图。 3.5 业务流程图 用UML的活动图描绘系统总的业务流程。
软件需求分析报告文档模板 姓名 日期
1. 引言 (3) 1.1编写目的 (3) 1.2项目风险 (3) 1.3文档约定 (3) 1.4预期读者和阅读建议 (3) 1.5产品范围 (4) 1.6参考文献 (4) 2. 综合描述 (4) 2.1产品的状况 (4) 2.2产品的功能 (5) 2.3用户类和特性 (5) 2.4运行环境 (5) 2.5设计和实现上的限制 (5) 2.6假设和约束(依赖) (6) 3. 外部接口需求 (6) 3.1硬件接口 (6) 3.2软件接口 (7) 3.3通讯接口 (7) 4. 系统功能需求 (7) 4.1说明和优先级 (8) 4.2激励／响应序列 (8) 4.3输入／输出数据 (8) 5. 其它非功能需求 (8) 5.1性能需求 (9) 5.2安全措施需求 (9) 5.3安全性需求 (9) 5.4软件质量属性 (9) 5.5业务规则 (9) 5.6用户文档 (10) 6. 词汇表 (10) 7. 数据定义 (10) 8. 分析模型 (11)
1. 引言 引言是对这份软件产品需求分析报告的概览，是为了帮助阅读者了解这份文档是如何编写的，并且应该如何阅读、理解和解释这份文档。 1.1 编写目的 说明这份软件产品需求分析报告是为哪个软件产品编写的，开发这个软件产品意义、作用、以及最终要达到的意图。通过这份软件产品需求分析报告详尽说明了该软件产品的需求规格，包括修正和(或)发行版本号，从而对该软件产品进行准确的定义。 如果这份软件产品需求分析报告只与整个系统的某一部分有关系，那么只定义软件产品需求分析报告中说明的那个部分或子系统。 1.2 项目风险 具体说明本软件开发项目的全部风险承担者，以及各自在本阶段所需要承担的主要风险，首要风险承担者包括： ●任务提出者； ●软件开发者； ●产品使用者。 1.3 文档约定 描述编写文档时所采用的标准(如果有标准的话)，或者各种排版约定。排版约定应该包括： ●正文风格； ●提示方式； ●重要符号； 也应该说明高层次需求是否可以被其所有细化的需求所继承，或者每个需求陈述是否都有其自己的优先级。 1.4 预期读者和阅读建议 列举本软件产品需求分析报告所针对的各种不同的预期读者，例如，可能包括： ●用户； ●开发人员； ●项目经理； ●营销人员； ●测试人员； ●文档编写入员。 并且描述了文档中，其余部分的内容及其组织结构，并且针对每一类读者提出最适合的文档阅读建议。
用户需求分析报告（范本） 1.1 需求分析报告 1.1.1 引言 当决定要开发一个信息系统时，首先要对信息系统的需求进行分析，需求分析要做的工作是深入描述软件的功能和性能，确定软件设计的限制和软件同其他系统元素的接口细节，定义软件的其他有效性需求。 抽象出当前系统的逻辑模型。在理解当前系统“怎么做”的基础上，抽取其“做什么”的本质，从而从当前系统的物理模型抽象出当前系统的逻辑模型。在物理模型中有许多物理因素，随着分析工作的深入，有些非本质的物理因素就成为不必要的负担，因而需要对物理模型进行分析，区分出本质的物理因素就成为不必要的负担，因而需要对物理模型进行分析，区分出本质的和非本质的困素，去掉那些非本质的困素即可获得反映系统本质的逻辑模型。 1.1.2 任务概述 随着信息时代的到来，图书的信息化管理使得问题得以解决，图书馆管理系统的出现就显得水到渠成了。 本系统主要上可以分为两大模块:图书馆管理员模块和读者登录模块，并在这两大模块下分成多个子模块。图书的使用对象是借阅者，例如学生，教师。 因此根据这些信息，本系统的主要功能就是：实现图书馆图书信息的管理和维护，图书浏览、查询等。 1.1.3数据描述 系统功能结构 学生用户端：查询图书，学生用户可以进行简单的查询和高级查询，预约图书，当要借的的书不在馆时，可以提前预约。挂失图书，图书丢失要挂失，可以在学生用户端实现。 管理员端：学生用户管理，实现学生用户信息的修改，删减，添加，查询。图书管理，包括对图书的增加，删减，查询等。管理员管理：操作者包括超级管理员和普通管理员，超级管理员可以对普通管理员进行删减，查询等操作，而普通管理员只有修改自己密码的权限。 借阅管理：主要是学生借阅管理，归还图书和缴纳罚款的管理。 主要有学生信息表和管理信息表还有图书信息表为例