非功能性需求是随着软件系统的规模成长和复杂性增加这两个因素才逐渐成为需求工程师们的新着眼点和关注点的。早期的时候，甲方处于自身对软件技术的了解和自身对系统未来维护的方便性考虑等，对系统有了诸如：开发平台、技术流派、关键实现等等方面的要求，这被称之为：“设计约束”。从甲乙双方合同的角度，设计约束也是一种需求------一种“非功能”性的需求。后来，软件的质量问题越来越突出，描述软件质量目标的要求也成为非功能性需求的一部分。于是，目前业界关于软件的非功能性需求，一般就包括：质量属性要求（质量目标）和约束性要求。

　　关于软件的非功能性需求的开发，一致以来没有什么典型的方法论。我根据自己的一些实践经验，这里总结出来一个非功能性需求开发（获取和分析）的一般过程，一起探讨。

　　（一）先看一下如果获取和分析软件的质量属性要求（甲方未直接或明确提出来）。过程如下：

　　（1）遍历每个软件质量属性，从宏观层面找出可能存在的质量要求。发现支持每个质量要求的依据。

　　（2）分析质量属性的冲突。

　　（3）确定质量属性的优先级。

　　（4）选择排名靠前的几个作为关键质量属性。

　　案例：一个大型自动化仓库管理控制系统，其用户有大型快寄公司如UPS、DHL、中国邮政，大型卖场如沃尔玛和制造公司如奔驰等。该系统需要进行仓储管理、货物调度等。另外，甲方要求系统将来可以更换硬件平台。

　　第一步：我们逐个分析是否存在哪个软件质量属性，并找出其存在的依据（（1）-（2）步骤一起执行）。

　　性能？非实时系统，但不能拥塞和长时间故障 ，否则影响运行吞吐量，影响企业的核心利润。所以，性能问题是该系统需要考虑的一个重要质量属性。

　　安全性？系统要确保设备操作安全，故障率低，不发生工人伤亡。确保系统指令不出错。所以，安全性也是该系统需要考虑的一个重要质量属性。

　　持续可用性？以设备为生产线的企业，最大限度的利用设备是企业的基本运营原则，所以24小时X7天/周的持续可用性是必须的。所以，持续可用性安全性也是该系统需要考虑的一个重要质量属性。

　　可互操作性？不存在与其他系统的数据交换和业务协作等互操作。

　　可靠性？没有象诸如电信计费那样的可靠性要求。

　　健壮性/鲁棒性？系统的用户群相当固定，且小，不易发生非法操作。

　　易用性？仓储管理人员属于产业工人，需要系统操作简单、交互明了。

　　可测试性？此类系统在正式上线前必须进行试运行。

　　可重用性？仓储管理是一个社会普遍的业务类型，如果开发方需要继续在该领域发展，不妨考虑可重用性。

　　可维护性？此类系统一旦建立，只要企业存在，系统的维护性一定要考虑。

　　可扩展性？不同的仓库业务类型和流程大同小异，但可能规模不同，另外，一个仓储企业的发展必然包括业务规模的发展，因此可伸缩性是必须要考虑的。

　　可移植性？“甲方要求系统将来可以更换硬件。” 这是一个来自甲方的直接的软件质量属性要求。

　　基于以上分析，我们认为：安全性、持续可用性、易用性、可维护性、可扩展性、可移植性、可重用性、可测试性都可以作为该系统的非功能性需求。

　　第二步：接下来，我们分析这些软件质量属性，他们直接是否存在冲突，也就是满足一个会导致另一个不满足或消弱的情况。

　　性能是否影响可移植性？本系统中，性能要求主要体现在整体存储吞吐量上，是一个统计概念，这并不和具体的平台、技术之间关联，所以没有冲突。

　　可移植性是否影响易用性？甲方的可移植性要求导致将来硬件系统的更替，可给甲方的系统维护人员带来新的挑战，但业务承担员工并不会有太大影响，因为，业务流程控制操作并不会改变。