大象--Thinking in UML早知道 -- 006 -- 非功能性需求

如何采集非功能性需求

    在需求阶段，与功能性需求不同，非功能性需求是需要需求人员主动引导的。因为客户并非计算机专家，除了可用性之外，他们很少会考虑其它的非功能性需求。即使提出，也是很模糊的要求，比如速度要快，报表要在一分钟之内统计完成等模糊的语言。

    需求人员要在需求过程中了解清楚系统的应用环境，包括硬件环境、网络环境、用户情况、预期使用人数、并发使用情况等等，这些因素都是确定非功能性需求的重要依据。在收集非功能性需求时，可以采用固定表格的形式，一个一个问题搞清楚。下面笔者给出一个调研表的示例，供读者参考。在这个表格中，通过回答表中的问题来确定非功能性需求的指标。

非功能性需求调查表

可靠性

安全性

系统数据的敏感程度？

在此回答系统数据的保密要求。这个要求与客户的业务相关，是指的整体敏感程度。例如可以分为机密、保密、一般、公开等几种类别

系统运行于何种环境？

在此回答系统的运行环境。是运行于Internet还是Intranet？是公用服务器还是私有服务器？是集中式应用还是分布式应用？是单机版还是服务器版？

客户组织中的信息保密制度？

在此回答客户组织中的信息保密制度。例如，工资数据、财务数据保密级别很高，只有组织中的部分人员可访问；一般公司制度数据，人员资料可向内部人员公开等等。

使用人员成份情况

在此回答使用人员的成份。例如，是否都是内部人员？是否分为正式员工和合同工？是否有外部人员访问等等

事务性

系统业务交叉程度如何？

在此回答业务的交叉程度。如果多个部门或很多用户频繁的对同一份数据存取，业务交叉程度就高，相应的事务性要求也就高。

数据精确度要求如何？

在此回答数据的精确度要求。如果数据精确度要求很高，例如财务数据，相应的事务性要求也就高；反之，例如人员档案资料，精确度要求低，相应的事务性要求也就没那么严格

业务是在线的还是离线的？

在此回答业务的运行要求。在线交易必须保证事务性，所谓一手交钱一手交货。而离线交易则事务级别可相应降低。

系统集成情况如何？

在此回答系统的集成情况。如果系统与其他很多系统集成在一起，相互依赖于数据的同步，那么事务性要求就高。

是分布式系统还是集中式系统？

在此回答系统的应用模式。如果系统是分布式的，那么一般都需要借助事务中间件完成全局事务。否则，有可能数据库本身的事务处理机制就能满足要求。

稳定性

系统的服务能力要求如何？

在此回答系统的服务能力要求。例如是需要7*24小时不间断服务，还是可以允许短暂停机。

用户的操作频率如何？

在此回答用户的操作频率。例如，假设每操作10次就可能出现一次故障，如果客户每天只使用1次，那么或许是可以忍受的。但如果客户每天使用10次以上，就是不可忍受了。

业务的及时性要求如何？

在此回答业务的及时性要求。例如，客户的业务依赖于数据的连续传输，一旦数据链停止，整个业务都将停止，则系统稳定性要求就高。反之，如果今天传输数据，明天才来读取，稳定性要求就低。

数据的重要程度如何？

在此回答数据的重要程度。例如，一旦部分数据丢失，整个系统就存在失效或崩溃的风险，则稳定性要求就高；反之，如果数据丢失，不影响系统的正常运行，稳定性要求就低。

可用性

界面

客户的行业性质如何？

在此回答客户的行业性质。不同的行业性质应该有不同的界面风格考量。例如，给政府部门做项目，界面风格应当是庄严稳重的，不能设计成娱乐网站式的花花绿绿。

客户的企业文化如何？

在此回答客户的企业文化。界面的色调和风格应与客户的企业文化相符合。例如，如果客户以年轻人居多，界面风格可以轻松活泼一些。如果以老年人居多，界面风格应当稳重一些。

客户业务的复杂程度如何？

在此回答客户业务的复杂程度。例如，客户的业务功能庞杂，界面设计时导航功能考虑就要多一些，尽量在一个版面容纳更多的功能并方便导航；否则，就应该考虑第一时间可以看到所有功能。

使用人员的情况如何？

在此回答使用人员的情况。如果使用人员计算机素质较高，可以考虑复杂一些的界面设计，反之就应当尽量简单和直接。

操作习惯

客户之前使用过什么系统吗？

在此回答客户之前使用过系统的界面风格。人总是有惰性的，尤其对上了年纪的人来讲，适应新的风格总要慢一些。应当考虑保持原先客户习惯的操作模式。

客户喜欢怎样的操作风格？

在此回答客户习惯的操作风格。例如是喜欢菜单，还是导航条，是喜欢按钮，还是超链接等。

文档要求

客户需要联机文档吗？

在此回答客户是否需要联机文档。联系文档类似word的帮助菜单里的内容。

客户需要在线帮助吗？

在此回答用户是否需要在线帮助。在线帮助需要在界面中放置该界面的操作指导。

客户的计算机操作水平如何？

在此回答客户的计算机操作水平。若客户的操作水平较高，则用户手册可专心描述业务操作；若客户的操作水平很差，则用户手册还要考虑普及一些计算机基础知识，并且多使用界面截图。

有效性

性能

系统的平均访问量？

在此回答系统数据的平均访问量。平均访问量是指在特定的时间段内，比如天，或小时，系统平均被访问的次数。

系统的峰值访问量？

在此回答系统的峰值访问量。峰值访问量是指在特殊的情况下，系统瞬时可能被访问的最大数量。

系统的数据流量？

在此回答系统的数据流量。数据流量是指在系统中传输和处理的数据量。包括数据的数量和数据的大小。

系统的并发要求？

在此回答系统的并发要求。并发是指同一时间内多个访问者对同一资源的访问。区别于平均访问量。若同时使用系统但访问的是不同资源，则不称为并发。

硬件环境如何？

在此回答系统的硬件环境。包括服务器情况，例如内存、CPU、硬盘等，以及网格状况，例如带宽、交换机容量等。

可伸缩性

客户业务预期的扩张速度？

在此回答客户业务预期的扩张速度。业务扩张速度是指使用系统的频繁程度，随着业务的扩张，使用系统的频率随之提高，就需要系统有一定的伸缩能力。

客户数据量的扩张速度？

在此回答客户数据的扩张速度。即使客户的业务没有扩张，但有可能随着系统的使用，数据量急剧扩张。这也需要系统具备一定的伸缩能力。

使用人数的扩张速度？

在此回答使用人数的扩张速度。例如网站，随着人气的提升，访问人数可能呈爆炸性增长，也需要系统具备一定的伸缩能力。

可扩展性

系统规模会持续扩大吗？

在此回答系统规模是否会持续扩大。例如客户的项目是分期建设的，系统规模会随着项目的进展持续扩大。则系统的建设初期就要考虑扩展性。

客户是否有长期系统建设的计划？

在此回答客户是否有长期的系统建设计划。如果客户具有这样的计划，随着新建设的系统不断加入运行，同时还要保证原先系统的稳定，就要考虑系统的可扩展性。

客户有升级系统的长期计划吗？

在此回答客户是否有系统升级的长期计划。如果客户具有这样的计划，那么技术的升级换代是不可避免的。系统在建设的初期就要考虑可扩展性。

可移植性

硬件环境

客户当前的硬件环境如何？

在此回答客户当前的硬件环境。若客户的硬件设备比较陈旧，面临着更新的问题，那么系统移植应当被纳入考虑范围。至少应当考虑假设客户将来要更新设备，会更新成哪一类设备

客户是否有长期的硬件厂商合作伙伴？

在此回答客户是否有长期的硬件提供商。假设客户有长期的设备供应商，那么客户的硬件设备就会比较稳定，相应的移植能力也就没那么重要。反之，如果客户隔三岔五的更换设备供应商，系统的移植能力就需要重视了。

客户的业务是否在快速增长？

在此回答客户业务增长速度。如果客户的业务增长迅速，那么相对频繁的升级硬件设备就是意料中的事，移植能力就重要一些。反之，客户业务稳定，升级硬件设备的可能性就低，相应的移植能力也就没那么重要。

软件环境

客户和系统运行环境如何？

在此回答客户的系统运行环境。如果客户的系统运行环境比较单纯，仅有有限的系统在运行并且相互之间关系不大，则移植的可能性小。反之，客户就有可能从信息化的整体考虑而提出统一系统平台的构想，由此带来移植的问题。

客户是否有长期的软件提供商？

在此回答客户是否有明确的软件供应商。例如客户如果与某家应用服务器供应商建立了长期合作关系，那么改变软件环境的可能性就小。反之，就有可能因为改变了第三方软件产品而带来移植问题。

自己是否有长期明确的技术路线？

在此回答开发商自己是否有长期明确的技术路线。如果公司已经有技术路线规划和长期的产品规划，则应当考虑移植能力，以保证当软件所遵循的标准或技术路线改变时自己和客户的投入成本不受到大的损失。

    如何记录非功能性需求

    前面已经讲过，非功能性需求不适合记录在用例规约里。在RUP里提供了两份模板可以用来记录非功能性需求。一份是用例补充规约，另一份是软件需求规约。用例补充规约是专门为某个用例服务的，如果某个非功能性需求只只该用例有关，例如仅有某个用例需要特别的安全性，那么可以写在用例补充规约里。软件需求规约是针对整个软件的，所以如果非功能性需求是针对整体软件的，就应当写在软件需求规约文档里。

    不过，笔者建议将这两个文档合并。因为在实践中，非功能性需求仅仅针对某个用例的情况是不多见的。并且文档过多和信息过于分散会增加项目管理的难度。因此可以将所有的非功能性需求都写到同一份文档里，既便于管理，也容易阅读。