(转)如何获取和分析非功能性需求

​​ http://blog.csai.cn/user2/52721/archives/2010/45514.html ​​​非功能性需求是随着软件系统的规模成长和复杂性增加这两个因素才逐渐成为需求工程师们的新着眼点和关注点的。早期的时候，甲方处于自身对软件技术的了解和自身对系统未来维护的方便性考虑等，对系统有了诸如：开发平台、技术流派、关键实现等等方面的要求，这被称之为：“设计约束”。从甲乙双方合同的角度，设计约束也是一种需求------一种“非功能”性的需求。后来，软件的质量问题越来越突出，描述软件质量目标的要求也成为非功能性需求的一部分。于是，目前业界关于软件的非功能性需求，一般就包括：质量属性要求（质量目标）和约束性要求。
    关于软件的非功能性需求的开发，一致以来没有什么典型的方法论。我根据自己的一些实践经验，这里总结出来一个非功能性需求开发（获取和分析）的一般过程，一起探讨。
（一）先看一下如果获取和分析软件的质量属性要求（甲方未直接或明确提出来）。过程如下：（1）遍历每个软件质量属性，从宏观层面找出可能存在的质量要求。发现支持每个质量要求的依据。（2）分析质量属性的冲突。（3）确定质量属性的优先级。（4）选择排名靠前的几个作为关键质量属性。
案例： 一个大型自动化仓库管理控制系统，其用户有大型快寄公司如UPS、DHL、中国邮政，大型卖场如沃尔玛和制造公司如奔驰等。该系统需要进行仓储管理、货物调度等。另外，甲方要求系统将来可以更换硬件平台。
第一步：我们逐个分析是否存在哪个软件质量属性，并找出其存在的依据（（1）-（2）步骤一起执行）。
性能？ 非实时系统，但不能拥塞和长时间故障 ，否则影响运行吞吐量，影响企业的核心利润。所以，性能问题是该系统需要考虑的一个重要质量属性。
安全性？ 系统要确保设备操作安全，故障率低，不发生工人伤亡。确保系统指令不出错。 所以，安全性也是该系统需要考虑的一个重要质量属性。
持续可用性？ 以设备为生产线的企业，最大限度的利用设备是企业的基本运营原则，所以24小时X7天/周的持续可用性是必须的。 所以，持续可用性安全性也是该系统需要考虑的一个重要质量属性。
可互操作性？ 不存在与其他系统的数据交换和业务协作等互操作。
可靠性？ 没有象诸如电信计费那样的可靠性要求。
健壮性/鲁棒性？ 系统的用户群相当固定，且小，不易发生非法操作。
易用性？ 仓储管理人员属于产业工人，需要系统操作简单、交互明了。
可测试性？ 此类系统在正式上线前必须进行试运行。
可重用性？ 仓储管理是一个社会普遍的业务类型，如果开发方需要继续在该领域发展，不妨考虑可重用性。 
可维护性？ 此类系统一旦建立，只要企业存在，系统的维护性一定要考虑。
可扩展性？不同的仓库业务类型和流程大同小异，但可能规模不同，另外，一个仓储企业的发展必然包括业务规模的发展，因此可伸缩性是必须要考虑的。
可移植性？ “甲方要求系统将来可以更换硬件。” 这是一个来自甲方的直接的软件质量属性要求。
基于以上分析，我们认为：安全性、持续可用性、易用性、可维护性、可扩展性、可移植性、可重用性、可测试性都可以作为该系统的非功能性需求。
第二步：接下来，我们分析这些软件质量属性，他们直接是否存在冲突，也就是满足一个会导致另一个不满足或消弱的情况。
性能是否影响可移植性？本系统中，性能要求主要体现在整体存储吞吐量上，是一个统计概念，这并不和具体的平台、技术之间关联，所以没有冲突。
可移植性是否影响易用性？甲方的可移植性要求导致将来硬件系统的更替，可给甲方的系统维护人员带来新的挑战，但业务承担员工并不会有太大影响，因为，业务流程控制操作并不会改变。
基于以上分析，本系统没有明显的质量属性冲突。
第三步：确定这些质量属性的优先级。
这个优先级是根据各个质量属性对系统的影响程度来定性判断的。一般来讲，影响安全生产的要素要高优先级考虑，其次是影响企业经营的要素，最后考虑哪些支持性的要素。因此，该案例的软件质量优先级排序如下：1.安全性2.持续可用性3.易用性4.可维护性5.可扩展性、可移植性、可重用性、可测试性。
第四步：筛选关键的软件质量属性。
一个系统关键的软件质量属性和质量目标不可能太多，一般视系统的规模从2-5个不等。因此，该案例的关键软件质量属性可以选择前三个：1.安全性2.持续可用性3.易用性。

（二）获取和分析软件约束的过程如下：
第一步，获取约束。可以从以下4个方面获取软件约束。（1）来自业务环境的约束，如：与其他系统集成、预算限制、上线时间紧等（2）来自使用环境的约束，如：用户群特征（知识水平、语言能力、操作习惯等），系统运行环境（干扰、网络质量、移动性等）（3）来自构建（开发）环境的约束，如：开发人员的素质（技术水平、学习能力、）、团队分布等（4）来自当前技术环境的约束，如：技术平台、中间件、编程语言等等。  第二步，分析约束，发现功能性需求和软件质量属性。

案例：某公司欲开发一个全球农产品C2C电子商务项目，主要功能是提供一个便捷、快速的交易流程。投资5000万用于初期开发系统、运营和市场营销。先期估算买卖会员一年内可以到达20万，以后计划每年确保50%的会员增长率。该系统拟采用支付宝和快钱进行第三方结算。目前这两家公司向其他客户提供Web服务接口。承接方希望在年度内完成开发，因为他们下一年要被一家外资公司执行收购。
第一步，获取约束
业务环境存在哪些约束？ 投资方投资额限制、会员增长率、第三方系统集成要求 。
使用环境存在哪些约束？ 全球农民或农场主为系统的使用者，隐含一个设计约束：系统操作简单。 有些农村地区网络质量差，带宽小。
构建环境存在哪些约束？ 系统开发商有对开发时间的限制。
技术环境存在哪些约束？ 可能以Web服务方式集成。
第二步，分析约束，发现功能性需求和软件质量属性。
直接的设计约束： 以Web服务方式集成 ，开发周期 ，多语言版本 等等。
可引出功能需求： “主要功能是提供一个便捷、快速的交易流程”，并且，全球农民或农场主为系统的使用者，这就要求系统能够进行产品快速搜索和产品比价。
可引出质量需求： “有些农村地区网络质量差，带宽小。”在网络环境差的条件下保证系统的可用性等。