关于非功能性需求说明书Word下载.docx

关于非功能性需求说明书Word下载.docx

《关于非功能性需求说明书Word下载.docx》由会员分享，可在线阅读，更多相关《关于非功能性需求说明书Word下载.docx（6页珍藏版）》请在冰豆网上搜索。

*即使硬件出现故障，系统也可以可靠运行吗？

*复制和故障转移方案是什么？

*需要手动干预，还是系统可以自动进行故障转移？

*实现可靠性会对性能造成负面影响吗？

*实现可靠性的成本有多高？

可靠性需要考虑的一些具体方面是：

安全性：

假设攻击者就在外面。

如何知道系统用户就是他们所声称的，并只让他们访问经过授权的功能？

如何保护我的系统不受攻击？

考虑到网络攻击、机器攻击，甚至从您自己的系统内部发起的攻击。

事务性：

如何设计系统来保存工作单元的ACID属性？

如果在设计中涉及多个独立的子系统（Web服务和SOA就是这种情况），则这一点就显得特别重要。

不要假设始终可以进行两阶段提交（twophasecommit）。

可用性

如果用户不能够从他们可用的渠道（例如Web）方便地访问您的产品，那么它的好处何在呢？

这有时是作为功能性的一部分一起考虑（或者应该在理想的环境下）的，但是常常被忽视，以致于整个项目处于危险之中。

这里需要考虑的一些问题是：

*您是否为用户带来不适当的负担（例如，需要特殊的浏览器版本）？

*系统是否根据模型-视图-控制器（Model-View-Controller）体系结构设计以使多用户界面成为可能？

如果是这样，如何将它们绑定在一起？

*是否界面本来就有状态而功能无状态（反之亦然）？

有效性

如果没有有效地使用资源（例如处理器、内存和磁盘空间），功能性、可靠性和可用性再好的系统最后都会失败。

我们经常发现将有效性划分成两个子范围是很有用的，这两个子范围都应该加以考虑：

性能：

这个系统的运行情况有多好？

它只是平稳缓慢地运行吗？

系统可以达到其响应时间目标吗？

应用程序的设计是否符合性能要求？

您利用缓存了吗

可伸缩性：

如果系统在小范围内运行看起来相当快，那么当扩展至每秒、每分钟或者每小时几千或成千上万个活动的时候呢？

它的设计是否达到吞吐量目标？

可以复制系统来实现线性扩展吗？

是否存在瓶颈（例如公共数据库）

可维护性

这是一个极其重要的需求，因为如果开发人员、管理员和操作人员不能够解决如何管理应用程序的问题，则它在首次发布之前就会夭折。

假设您是一位管理员，您承担了解决此问题的任务，那么您如何配置它？

如何监视它？

如果您一件事情需要执行很多次（例如，安装许多应用程序），那么会怎么做呢？

您是否有一个可复制的部署流程呢？

您是否可以使重复的任务自动化，使之在大范围内可行呢？

可移植性

虽然列在最后，但它并非最不重要。

例如，如何采用标准来提供某种形式的平台中立性呢？

是否计划将应用程序迁移到您的最新和最高版本的应用服务器上呢？

如果不打算这样做，则当供应商撤消对该版本的支持时您要怎么做呢？

如果您的项目基于开放源代码，则也有类似的问题。

如果每当某人有个更好的捕鼠器（mousetrap）您就必须重写整个应用程序，则没有人会问津。

作为一个公司，就有一定的工作量存在，而员工的工作效率与公司的任务完成量息息相关。

而员工的个人信息、通讯薄，它的工作量可能是其它信息工作量的几倍，会议的增加、会议室的查询、个人信息的修改；

工作管理；

统计等等，每个信息的数据都在不断地变化着，如果采用人工的方式进行操作，那么，一天的工作量，足以让人觉得比较繁琐，吃不消。

针对这样的情况，采用让数据的查询变得简单化，数据变的更让每个人都在任何时刻都可以了解到。

旋风协同办公系统是为公司开发的，本系统

性定义不仅决定产品的质量，还在很大程度上影响产品的功能需求定义。

如果事先缺乏很好的非功能性需求定义，结果往往是使产品在非功能性需求面前捉襟见肘，甚至淹没功能性需求给用户带来的价值。

所谓非功能性需求，是指软件产品为满足用户业务需求而必须具有且除功能需求以外的特性。

软件产品的非功能性需求包括系统的性能、可靠性、可维护性、可扩充性和对技术和对业务的适应性等。

下面对其中的某些指标加以说明。

1．系统的完整性

系统的完整性指为完成业务需求和系统正常运行本身要求而必须具有的功能，这些功能往往是用户不能提出的，典型的功能包括联机帮助、数据管理、用户管理、软件发布管理和在线升级等。

并不是所有的系统都必须包括以上所有的功能，而是可以根据产品的使用环境和企业的产品发展决策进行挑选。

例如，在线升级、软件发布管理适用于具有Internet或内网环境的软件产品；

数据管理对于产生数据存储的产品则是必须的，设计人员不应假设用户同时是一个合格的DBA。

而且系统所产生信息的分布和关系，也不是DBA所应该了解的内容。

因此完整的系统应该包括数据备份、恢复、日志管理及垃圾数据清除等基本功能，哪怕这些功能的核心只是一条语句或命令；

用户管理功能是另一项必不可少的功能，它定义哪些用户可以以什么样的功能使用系统。

好的用户管理功能不仅可以有效控制用户对系统的使用，使系统处于一个安全且负载合理的运行状况，还能提高系统的应用适应性。

2．系统的可扩充性与可维护性

指系统对技术和业务需求变化的支持能力。

当技术变化或业务变化时，不可避免将带来系统的改变。

不仅要进行设计实现的修改，甚至要进行产品定义的修改。

好的软件设计应在系统架构上考虑能以尽量少的代价适应这种变化，常用的技术有面向对象的分析与设计及设计模式。

3．技术适应性与应用适应性

系统的适应性与系统的可扩充性和可维护性的概念相似，也表现产品的一种应变能力，但适应性强调的是在不进行系统设计修改的前提下对技术与应用需求的适应能力，软件产品的适应性通常表现为产品的可配置能力。

好的产品设计可能要考虑到运行条件的变化，包括技术条件（网络条件、硬件条件和软件系统平台条件等）的变化和应用方式的变化，如在具体应用中界面的变化、功能的剪裁、不同用户的职责分配和组合等。

对以上重要的非功能性需求进行逐一分析后，即可开始进行产品功能设计。

实际上，非功能性需求定义将反映到系统的功能设计中，表现为系统的架构。

下一节中将会描述如何实现系统的适应性。

软件产品的功能设计要点

软件产品的功能设计要点如下。

1．产品核心功能的选取

软件产品的设计，一定有一个明确的目标，或是为了解决某个或某类具体的应用问题，或是为解决问题提供一个或一组工具。

产品的目标决定了产品的核心功能，产品的其他功能都是对这一功能的补充或围绕这一功能提供的相关服务。

适当选取核心功能，有如下几个原则。

①规模适当，不贪大求全，坚持“有所不为”。

具体来说，在一个产品中，非核心功能尽量简化和弱化。

以“多媒体远程教学系统”为例，核心功能应该是基于网络的多媒体远程教学，包括同步教学和非同步教学，与教学相关的学籍管理、教务管理、答疑考试和收费管理等辅助功能则采取最小化原则进行设计。

这样既可以突出产品的技术特点，又可以避免以己之短搏人之长，显得产品在培训教育方面不够专业。

等到核心功能稳定在产品中以后，再专门针对不同的应用要求研制不同的产品系列，如“网校版”、“中学版”和“企业版”等。

②除了应用要求以外，还可以根据关键技术进行版本规划。

由于不同的技术对设备会有不同要求、并产生不同的应用效果，因此可以在相同的业务框架下构造基于不同技术的不同产品。

例如，微软与多媒体相关的技术有流媒体技术、DirectShow、DirectPlay和TAPI等，RealNetworks也有完整的流媒体技术开发平台。

这些技术分别具有一定的功能和性能特点，同时也各有其局限，利用它们的组合可以形成面向不同细分市场的产品。

例如，针对以“灌输”为主、对交互性和实时性没有要求的单向式培训，设计以流媒体为主要技术的产品版本；

针对实时性和交互性要求很高的教学和培训，设计以DirectShow和DirectPlay为核心技术的产品版本。

③尽量遵从标准协议和行业标准。

除了计算机系统有多种技术标准和协议外，各行各业还有自己的行业标准。

例如，对于“多媒体远程教学系统”而言，涉及的标准和协议有媒体格式MPEG标准、流媒体传输和控制协议等，在应用领域有国家教委颁布的关于远程教育的建议标准，这些都应该充分考虑。

有时不参照标准或自定义一些协议处理解决方案带来一时的快捷，但往往生命力和可靠性经不起时间的考验，在系统与其他相关系统联合使用时就会带来问题。

2．多重可重用性的分析与设计

可重用性是现在软件设计较为重视的一个特性，不仅应该在系统设计中考虑，还应该在系统分析时就加以考虑，使系统达到多重可重用性。

这就要求我们不仅要采用面向对象的思想来进行系统分析，用对象概念构造系统行为。

还要求我们在更高层次上对系统的操作模式或应用模式进行抽象，发现更高级的可重用性。

仍旧以“多媒体远程教学系统”为例，如果仅在系统设计时考虑可重用性，则产品可能达到部件级的可重用，即系统的某些核心特性可以反复用于相关产品的设计之中；

如果我们加入对应用操作模式的抽象，对于“直播”、“流媒体与课件同步”和“现场控制”等构成应用的操作环节进行面向对象的分析，即可获得更好的可重用性。

如果设计得当，一个产品可以同时满足直播教学、培训、股评和案例研讨等含有相同应用模式的多种不同应用环境，甚至连一行代码也不用重写。

多重的可重用性实际上就实现了非功能性需求中的应用适应性，无论我们设计面向哪些用户（最终用户／系统集成商／软件开发商）的产品，进行一些多重可重用性的分析都是有益无害的。

3．辅助功能的设计

这里提到的“设计得当”，包括辅助功能的设计这一重要因素。

前面所述的非功能性需求有一些就反映在辅助功能的设计中。

在我们把最终业务用户作为产品的惟一用户时，把全部注意力放在产品的主要功能设计上；

当我们把产品的用户范围扩大到系统管理人员、数据维护人员及系统集成商／软件开发商时，我们就必须对产品的辅助功能给予足够的关注。

对于应用软件产品，至少有如下重要的辅助功能。

①在线帮助：

这仍然是面向业务用户（当然也要面向其他用户）的一项功能，用于使系统更为友好。

在线帮助功能通常设计成能独立运行的文档形式，如html格式。

②数据管理：

面向数据维护人员。

虽然数据库管理系统都有现成的数据管理功能，但专门设计的数据管理可以更简便、易于使用，而且可以完成数据库管理系统本身所不能完成的工作。

③日志管理：

面向系统管理人员。

良好设计的日志功能可以作为系统管理人员或产品设计人员监视系统状态、追踪系统问题，并作为用户使用系统的审计依据。

④用户管理：

用户管理与下面的两项功能一起使用，可以使系统适应不同的用户功能分配需求。

系统管理人员可以最大限度地灵活指定不同用户所能执行的不同功能项，消除通常造成软件产品在用户手中“水土不服”的最主要的因素。

⑤功能定义及功能表的自动生成：

面向系统管理人员，定义系统的所有可操作功能项，并在用户进入系统时自动生成由管理员为之分配的功能表作为其“主菜单”。

这一功能对于含有数据库和Web界面的系统特别适用，它使得系统具有“自动演化”的能力。

即系统在运行时即可替换其部分功能，并且所有的功能权限在统一的控制之下。

这正是系统可维护性的“最高境界”。

⑥系统配置：

面向高级用户或专职的IT人员，根据实际需求定义系统的技术参数和应用模式。

经过系统配置后，系统不再是有各种技术和应用可行性的“中间系统”，而成为真正面向最终用户的产品。