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

如何采集非功能性需求

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

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

可用性
界面	客户的行业性质如何？	在此回答客户的行业性质。不同的行业性质应该有不同的界面风格考量。例如，给政府部门做项目，界面风格应当是庄严稳重的，不能设计成娱乐网站式的花花绿绿。
客户的企业文化如何？	在此回答客户的企业文化。界面的色调和风格应与客户的企业文化相符合。例如，如果客户以年轻人居多，界面风格可以轻松活泼一些。如果以老年人居多，界面风格应当稳重一些。
客户业务的复杂程度如何？	在此回答客户业务的复杂程度。例如，客户的业务功能庞杂，界面设计时导航功能考虑就要多一些，尽量在一个版面容纳更多的功能并方便导航；否则，就应该考虑第一时间可以看到所有功能。
使用人员的情况如何？	在此回答使用人员的情况。如果使用人员计算机素质较高，可以考虑复杂一些的界面设计，反之就应当尽量简单和直接。
操作习惯	客户之前使用过什么系统吗？	在此回答客户之前使用过系统的界面风格。人总是有惰性的，尤其对上了年纪的人来讲，适应新的风格总要慢一些。应当考虑保持原先客户习惯的操作模式。
客户喜欢怎样的操作风格？	在此回答客户习惯的操作风格。例如是喜欢菜单，还是导航条，是喜欢按钮，还是超链接等。
文档要求	客户需要联机文档吗？	在此回答客户是否需要联机文档。联系文档类似word的帮助菜单里的内容。
客户需要在线帮助吗？	在此回答用户是否需要在线帮助。在线帮助需要在界面中放置该界面的操作指导。
客户的计算机操作水平如何？	在此回答客户的计算机操作水平。若客户的操作水平较高，则用户手册可专心描述业务操作；若客户的操作水平很差，则用户手册还要考虑普及一些计算机基础知识，并且多使用界面截图。

可移植性
硬件环境	客户当前的硬件环境如何？	在此回答客户当前的硬件环境。若客户的硬件设备比较陈旧，面临着更新的问题，那么系统移植应当被纳入考虑范围。至少应当考虑假设客户将来要更新设备，会更新成哪一类设备
客户是否有长期的硬件厂商合作伙伴？	在此回答客户是否有长期的硬件提供商。假设客户有长期的设备供应商，那么客户的硬件设备就会比较稳定，相应的移植能力也就没那么重要。反之，如果客户隔三岔五的更换设备供应商，系统的移植能力就需要重视了。
客户的业务是否在快速增长？	在此回答客户业务增长速度。如果客户的业务增长迅速，那么相对频繁的升级硬件设备就是意料中的事，移植能力就重要一些。反之，客户业务稳定，升级硬件设备的可能性就低，相应的移植能力也就没那么重要。
软件环境	客户和系统运行环境如何？	在此回答客户的系统运行环境。如果客户的系统运行环境比较单纯，仅有有限的系统在运行并且相互之间关系不大，则移植的可能性小。反之，客户就有可能从信息化的整体考虑而提出统一系统平台的构想，由此带来移植的问题。
客户是否有长期的软件提供商？	在此回答客户是否有明确的软件供应商。例如客户如果与某家应用服务器供应商建立了长期合作关系，那么改变软件环境的可能性就小。反之，就有可能因为改变了第三方软件产品而带来移植问题。
自己是否有长期明确的技术路线？	在此回答开发商自己是否有长期明确的技术路线。如果公司已经有技术路线规划和长期的产品规划，则应当考虑移植能力，以保证当软件所遵循的标准或技术路线改变时自己和客户的投入成本不受到大的损失。

    
如何记录非功能性需求

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

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