课件需求分类业务需求系统需求软件需求用户需求功能性需求非功能性需求质量需求依从性需求体系结构设计需求设计开发约束需求分类注意点问题引出引出功能性需求的问题引出设计约束及过程约束的问题引出质量需求的问题
课件8.3 需求的类型.pdf
需求分类软件需求的分类可从多个维度上进行划分，可彼此交叉。
按软件需求修饰对象的不同，可分为：
软件产品需求：主要约束的是软件产品、软件制品本身的属性；软件过程需求：侧是修饰或者限制软件开发过程的要求；
产品需求又可细分为：
功能性需求：指代软件产品的功能特性；非功能性需求：则是软件产品的质量属性，是在功能性需求满足的情况下的进一步的要求；
按照软件需求面向对象的不同、以及其抽象层次和详细程度的不同，又可以将需求分为：
业务需求：针对业务部门的分析人员；用户需求：针对客户方、承包方的管理人员、最终用户、客户工程师和系统架构师；系统需求：则是由最终用户、客户工程师、系统架构师和承包方的程序员来关注的软件设计规约：则是客户工程师参考系统架构师和承包方的程序员重点关注的
业务需求企业的业务需求是指那些可以帮助企业达成组织目标（包括策略目标）的需求项。
企业的业务需求是关于企业业务的陈述，和这个需求如何被实现无关。无论是人工手动的还是通过系统来完成，都不影响企业的业务需求。
有时我们也把业务需求称为业务目标。
例如携程旅行这个公司它的业务需求是销售飞机票，公司的目标是成为当人们想买飞机票时首先想到的公司。这是对一个企业的业务需求的陈述。
系统需求系统需求的满足使得系统实现了预期的功能，它从用户的角度描述系统在做什么，而与系统是由什么样的硬件和软件实现无关。
一个企业选择实现某个软件系统的首要条件，就是该系统需求应该是满足组织的业务需求的。
举例，下面有3条需求描述：
卖票系统需要和用户数据库交互新的软件会使得汽车的启动速度加倍我们新产品制造的低成本，将会让我们有更高的市场份额并满足销售目标
由这三条需求可看到，对预期功能进行定义的只有其中的第二条，而第一条只是说明了卖票系统它要和用户数据库交互这个事实，实际上是一种设计的约束，第三条实际上在说低成本它是一个对过程的一个约束，而并没有说出产品的一个功能是什么，所以也不属于系统需求。
软件需求在一个软硬件结合系统中，软件需求是指关于系统中软件部分的需求，它的满足将有助于实现整体的系统需求。
举例：
“订票系统软件通过标准的网络服务接口和航班信息交互”，这是在说明订票系统软件与外部的其它系统之间的交互方式是通过网络服务接口，因此它既是一个软件需求，也是一个关于接口的一个描述；“用户接口需要设置关于用户偏好的颜色和字体大小”，这也是一个软件系统的功能，就是要设置用户偏好的颜色和字体大小，同时，它又是一种增强用户体验的一条软件需求，是关于质量和非功能性属性的；“系统的 APl 需要同时支持 C++和 ava 来让程序员访问系统服务”，意味这是一条软件系统的设计约束，是对编程语言的要求
用户需求系统的用户需求指的其满足程度会影响系统的用户接受程度的需求，有时候，用户需求被称作“用户接口需求”。
举例：
订票系统的⽤户接口需要提供和系统交互的选项，通过控制命令或者 WIMP 接⼝客户希望照相机背后有⼀个液晶屏幕，这样在拍照之后可以马上看到照⽚
功能性需求系统的功能性需求是指满足系统需求需要提供的功能，有时，功能需求也被称为“行为需求”。
举例：
订票系统需要提供一个在任何航班上预留座位的功能订票系统需要提供一个通过信用卡付费的功能
非功能性需求非功能性需求 (Non-functional Requirements, NFRs) 定义软件系统以及软件开发过程为满足系统功能需求要满足的其他约束条件。具体细分为：
质量相关的需求（服务质量）依从性需求体系结构约束设计开发约束
质量需求质量需求描述软件系统正常工作时需要满足的额外的、与质量相关的要求。在软件工程文献中，也称之为“质量属性”。它应答的是关于“提供的服务好到何种程度”的问题（How well)。
例如：
“订票系统的用户界面要满足用户选择出发和终到站的过程不能超过四次按键”，这是关于用户友好性的需求；“订票系统的订票请求响应时间要小于 1 分钟”，这是关于订票系统的响应时间的要求，也就是性能的要求；“图书馆的黑名单应随时响应馆员的查询操作”，这是对图书馆黑名单可用性问题的一个需求；“列车加速控制软件的平均无故障时间是 109 小时”，这是对系统可靠性的一个要求；
依从性需求依从性需求着重描述软件对国家法律、国际公约、社交法则、文化与政治习惯、标准等环境约束的满足要求。
例如：
两列火车间的最小间距应满足国际铁路运输安全规范中的最坏情况停车距离会议调度系统在缺省情况下，要排除目标市场所在地区的公众假期
这些依从性的需求往往是一个系统它所处的经济、政治、上下文要求的一些限制，它的满足是系统正常运行或者合法运行的一个客观标准。
体系结构设计需求体系结构设计需求定义系统环境对待设计系统在结构上的约束和限制。主要包含2个方面：
分布式约束：要求软件系统组件满足目标组织由于地理自然分布导致的对条统设备节点的分布要求，以及数据的分布式存储与处理要求。
例如：会议调度系统应与分布在世界各地的参会者的邮件服务系统和电子日程管理系统协同工作。它是由于组织机构本身以及其外部相关系统本身的分布属性导致的。
安装约束：要求软件系统能够在目标实现环境下正常运行。
例知：会议调度系统应在微软 Window8 和 MacOS 10.10 上。
设计开发约束设计开发约束是对软件系统设计过程的约束。包括开发成本、开发时间周期、产品特征的变化性、可维护性、可重用性、可移植性等。
例如：
“清华大学图书馆门户系统的开发成本不应高于 200 万元”，是对项目开发成本的约束；“动车控制软件应在两年内投入使用”，这是对开发时间周期的约束；“会议日程安排系统应根据会议类型动态调整调度策略”，策略具体的变化性包括：
对于专业研讨会与内部会议，两者策略应该不同对于固定会址与轮换会址，两者策略也不同对于参会人员的重要程度，是相同级别还是不同级别，也是不同策略的
需求分类注意点对需求的分类，需要额外强调的一点是需求的类型之间是存在一定重叠的。比如功能性需求与非功能性需求间的划分并非绝对的，可能存在一定的重叠，而顶层的非功能性需求经过逐步的细化和操作化以后，就转换成了一个系统的功能。
例子：
在一个核电站的安全注入条统中，当反应堆正常启动或冷却时一旦发现冷却剂损失，将安全注入指示灯打开。这既是一个功能性需求，又是一条安全性需求。防火墙管理软件的功能性需求也同样是安全型需求通话系统的来电过滤常常被看做是功能性特征，同时它也和通话者的隐私需求相关医疗信息系统中，对患者的病历服务发动拒绝服务攻击，使得医生在手术期间无法访问患者的关键数据，这是关乎数据和患者人身双重安全的需求向列车高频发送加速请求，既是安全需求也是性能需求
因此，要对需求分类的合理使用，我们应该：
关注特殊的需求特征关注需求的语义特征
明确指出系统必须支持的行为，这是系统被用户接受的必要条件排除那些不可接受的系统行为，这是导致系统不可接受的必要条件明确指出系统的最好支持的行为，这是用户对系统偏好的需求，但又不是必要条件
对那些适用范围受限的关注点以及横切许多功能的关注点，应该区别对待，比如安全性、多语言支持这类横切关注点可设计一个通用的解决方案，然后把它和各类系统有机结合集成在一起，而对那些适用范围受限的关注点，则要具体问题具体分析需求的分类主要用于为需求的抽取提供启发式的规则，使得我们可以
避免忽略某些关键的需求类型而且对于固有的需求类型之间存在矛盾和竞争关系的需求，我们可以在具体的需求条目中发现这些矛盾，解决相关冲突
问题引出
引出功能性需求的问题功能性需求是系统的功能和数据两个方面：
针对功能，需要做的提问是：
系统将做什么系统什么时候做有多种操作模式吗需执行何种计算或数据转换对外部刺激的响应是什么
针对数据的提问，主要是：
输入输出数据的格式？数据是否需要持久保存？
引出设计约束及过程约束的问题设计约束主要关注系统的物理环境和接口、上下文：
物理环境方面提问：
设备放在哪儿？单节点还是多节点？是否对环境有额外的要求？比如温度、湿度、电磁干扰等方面是否需要更多的加固和保护？系统规模有何限制？同时在线用户数是否有要求等电源、供热或空调有何限制？是否重用已有系统的构件，从而对编程语言有了特殊的要求？
接口方面提问：
输入是来自一个还是多个其他系统？输出是来自一个还是多个其他系统？输入、输出是否有预定义的格式？
而过程的约束则是关注系统用户和过程：
用户：
谁使用系统？几类用户？每类用户技术水平如何？
过程：
相关资源、材料系统构造需要哪些人员、技能多少文档？在线还是本地？电子还是纸质读者有哪些？相关标准
引出质量需求的问题
性能可靠性安全性可用性可维护性精度与精确性交付时间及成本