软件需求
冯曦
2020/4/2
---
2020/4/2
什么是需求？ 软件需求的层次和分类 需求的重要性 需求工程简介
---
2020/4/2
字面的含义
需要，要求，由需要而产生的要求。
需要 业务干系人(项目投资人、购买产品的客户、 实际用户的管理者、市场营销部门或产品策划部门) 想要实现的愿景和目标
最终用户想要完成的任务
2020/4/2
---
优点：
使用“FURPS+”分类方案（或其他分 类方案）作为需求范围的检查列表是 有效的，可以避免遗漏系统某些重要 方面。 其中某些需求可以统称为质量属性 （quality attribute）、质量需求 （quality requirement）或系统的“某 属性”。这些需求包括：可用性、可 靠性、性能和可支持性
文档相当重要！为什么？文档不只是单单做为一个需求记录，文档的核心 作用是做到需求的真实记录、保存，并指导后续产品开发，保证不会偏差 太大。同时起到不同部门的沟通媒介作用，也可以对后续的需求变更进行 预防。但是需求文档的质量必须保证，要做到真实可靠，条理清晰，层次 分明。
2020/4/2
---
2020/4/2
“FURPS+”中的“+”是指一些辅助性的和次要的因素
• 实现（Implementation）：资源限制、语言和工具、硬件等； • 接口（Interface）；强加于外部系统接口之上的约束； • 操作（Operation）：对其操作设置的系统管理； • 包装（Packaging）例如物理的包装盒； • 授权（Legal）：许可证或其他方式。
分清楚那些是业务需求、哪些是用户需求、哪些是功能性需求和 非功能性需求对软件的开发有着重大的指导意义，绝不可以以偏 概全，错误地去揣摩用户的心思。个人认为应该以业务需求为主 线，以主线挖掘用户需求，再以挖掘出的用户需求去挖掘功能需 求和非功能需求。
2020/4/2
---
软件需求的分类
在一般使用中，需求按照功能性（行为的），非功能性（其 它所有的行为），设计约束来分类。那么需求可以分成下面 这些内容：
功能需求 性能需求 环境需求 可靠性需求 安全保密要求 用户界面需求
资源使用需求 成本消耗需求 开发进度需求 预先估计以后系统可能 达到的目标 执行期约束
2020/4/2
---
在统一过程（UP）中，需求按照 “FURPS+”模型进行分类。
Rational统一过程(RUP)是Rational软件公司（现在Rational公司被IBM并购）创造的软件工 程方法。RUP描述了如何有效地利用商业的可靠的方法开发和部署软件，是一种重量级过程 （也被称作厚方法学），因此特别适用于大型软件团队开发大型项目。Rational很著名的工 具就是Rose，一种面向对象的统一建模语言的可视化建模工具。
• 功能性（Functional）：特性、功能、安全性； • 可用性（Usability）：人性化因素、帮助、文档； • 可靠性（Reliability）：故障频率、可恢复性、可预测性； • 性能（Performance）：响应时间、吞吐量、准确性、有效性、资源利用率； • 可支持性（Supportability）：适应性、可维护性、国际化、可配置性。
讳疾忌医—需求不重视
➢ 不准确的计划 ➢ 模拟两可的需求
需求很难
2020/4/2
---
需求的不确定性
雾里看花—需求说不清
• 客户对需求永远只有朦胧的感觉
隔靴搔痒—需求说不准
• 分析人员或客户的理解有误
糟糕的需求
➢ 用户参与不足 ➢ 用户需求扩展 ➢ 有岐义的需求 ➢ 镀金问题
刻舟求剑—需求说不全
➢ 过于抽象的需求
• 客户的需求总是不断的变动和增加 ➢ 忽略了用户分类
---
业务需求
指导
用户需求
转化
功能需求和非功能 需求

业务需求与用户需求之间不是一对一的关系，一个业务需求可能对应多个用 户需求，一个用户需求可能满足多个业务需求。一个用户需求可能会涉及一 个或多个功能需求，功能需求从开发人员的角度描述系统行为，一个功能需 求支持一个或多个用户需求，非功能需求支持功能需求。
要求 业务干系人附加在愿景和目标上的约束
最终用户为顺利完成任务提出的约束
自身影响 冲突
企业的生存和发展 企业的产值和利润 员工的发展和收入
利益链
公司的综合实力和干系人的最终目标
利润同成本
不断变化的需求对系统建设的影响
需求虽然由客户触发,但是需要--- 结合自身综合考虑,合理规避风险,合理开发
什么是软件需求？
软件需求的层次
业务需求
表示组织或客户高层次的目标。业务需求通常来自项目投资人、购买产品的客户、 实际用户的管理者、市场营销部门或产品策划部门。业务需求描述了组织为什么 要实现这个系统，即组织希望达到的目标。使用前景和范围文档来记录业务需求， 这份文档有时也被称作项目轮廓图或市场需求文档。具有以下特点：直觉，凌乱， 片断，模糊，无条理，甚至是自相矛盾，
IEEE（电气和电子工程师协会）的软件工程标准词汇表（1997年） 中对需求的定义 1. 用户解决问题或达到目标所需的条件或权能(Capability) 2. 系统或系统部件要满足合同、标准、规范或其它正式文档所需具 有的条件或权能 3. 一种反映上面(1)或(2)所描述的条件或权能的文档说明。
需求是客观的，它只告诉我们建设人员应该实现什么目标，而不会告诉我 们怎么做，我们更不能凭借一点理解、想象和臆测而主观的去设计和开发。
用户需求
用户需求（user requirement）描述的是用户的目标，或用户要求系统必须能完成 的任务。用例、场景描述和事件――响应表都是表达用户需求的有效途径。也就 是说用户需求描述了用户能使用系统来做些什么。
功能需求和非功能需求
功能需求（functional requirement）规定开发人员必须在产品中实现的软件 功能，用户利用这些功能来完成任务，满足业务需求。我们需要在软件需求 说明书（SNS)中尽可能详细的描述整个系统的行为，也就是功能需求。 非功能需求是指软件产品为满足用户业务需求而必须具有且除功能需求以外 的特性，包括系统的性能、可靠性、可维护性、可扩充性和对技术和对业务 的适应性等。