需求分析

需求定义

需求，是人们要解决的某个问题或达到某种目的的需要。是系统或其组成部分为满足某种书面规定（合同，标准，规范等）所要具备的能力。需求将作为系统开发，测试，验收，提交的正式文档依据。

(一)需求任务
需求是对外可见的系统特征。
需求管理有三项任务：
•  学习 ——需求获取
•  剪枝 ——需求优选
•  文档化 ——撰写需求规格说明书

(二)存在问题的需求描述
（1）含糊的需求描述
• “工资总额由上一条记录获得”
• “所有客户都具有同一控制域”
（2）错误的需求描述
• “所有系统将九月作为财政年度的起始间”
（3）不完整的需求描述
• “出错信息显示在屏幕的第11行”
（4）矛盾或不一致的需求描述
• “C=A+B”；“C=A-B”
（5）无法测试的需求
• “系统应具有友好的界面”

需求类型

产品 / 过程
• 产品需求
• 过程需求
产品需求
• 功能性需求
• 非功能性需求 （性能、质量属性、对外接口、约束）
抽象层次详细程度
• 业务需求
• 用户需求
• 系统需求
• 软件设计规约

(一)业务需求
业务需求是指那些可以帮助企业达成组织目标（包括策略目标）的需求项 。

• 企业的业务需求是关于企业业务的陈述，和这个需求如何被实现无关，无论是手动的还是通过系统来完成。
• 业务需求被叫做业务目标 。

(二)系统需求
系统需求的满足使得系统实现预期的功能，它从用户的角度描述系统在做什么，与系统是由什么硬件和软件实现无关。
 企业选择实现系统的首要条件是：系统需求满足组织的业务需求。
 
 (三)软件需求
 软件需求是指关于系统中软件部分的需求，它的满足帮助实现系统需求。
 
• 订票系统软件通过标准的网络服务接⼝和航班信息交互
• 用户接⼝需要设置关于用户偏好的颜色和字体大小
• 系统的API需要同时支持C++和Java来让程序员访问系统服务

(四)用户需求
系统的用户需求指的其满足会影响系统的用户接受程度的需求 。有时候，⽤户需求被称作“用户接口需求”。

(五)功能性需求
系统的功能性需求是指满足系统需求需要提供的功能 。有时，功能需求也被称为“行为需求”。

• 订票系统需要提供一个在任何航班上预留座位的功能
• 订票系统需要提供一个通过信用卡付费的功能

(六)非功能性需求
非功能性需求定义软件系统以及软件开发过程为满足系统功能需求要满足的其他约束条件。

(七)质量需求
质量需求描述软件系统正常工作时需要满足的额外的、与质量相关的要求 。在软件工程文献中，也称之为“质量属性”。 它应答的是关于 “提供的服务好到何种程度”的问题 （How well）。

(八)依从性需求
依从性需求着重描述软件对国家法律、国际公约、社交法则、文化与政治习惯、标准等环境约束的满足要求 。

• 两列火车间的最小间距应满足国际铁路运输安全规范中的最坏情况停车距离。
• 会议调度系统在缺省情况下，要排除目标市场所在地区的公众假期。

(九)体系结构设计需求
体系结构设计需求定义系统环境对待设计系统在结构上的约束。

• 分布式约束：要求软件系统组件满足目标组织由于地理自然分布导致的对系统设备节点的分布要求，以及数据的分布式存储与处理要求。
• 安装约束：要求软件系统能够在目标实现环境下正常运行。

(十)设计开发约束
设计开发约束是对软件系统设计过程的约束。
包括：开发成本、开发周期、产品特征的变化性、可维护性、可重用性、可移植性等。

需求类型间存在一定的重叠
功能性需求与非功能性需求间的划分并非绝对的，可能存在一定的重叠。
• 防火墙管理软件的功能性需求也同样是安全型需求。
• 来电过滤常被看做是功能性特征，同时它也和通话者的隐
私需求相关。
• 对患者的病历服务发动拒绝服务攻击使得医生在手术期间
无法访问患者的关键数据，这是关乎数据和患者人身双重
安全的需求。
• 向列车高频发送加速请求，既是安全需求也是性能需求。

需求分类的合理使用
• 关注特殊的需求特征
• 关注需求的语义特征
• 明确指出系统必须支持的行为
• 排除那些不可接受的系统行为
• 明确指出系统的最好支持的行为
• 对那些适用范围受限的关注点和横切关注点区别对待
• 需求的分类主要用于为需求的抽取提供启发式的规则
• 避免忽略某些关键的需求类型
• 通过已知矛盾的需求类型发现具体需求间的矛盾和冲突

引出功能性需求的问题
功能
• 系统将做什么
• 系统什么时候做
• 有多种操作模式吗
• 需执行何种计算或数据转换
• 对外部刺激的响应是什么
数据
• 输入输出数据格式？
• 数据是否持久保存？

引出设计约束及过程约束的问题
物理环境
• 设备放在哪儿？
• 单节点还是多节点？
• 是否对环境有要求？温度、湿度、电磁干扰？
• 系统规模有何限制？
• 电源、供热或空调有何限制？
• 是否重用已有系统的构件？对编程语言的要求？
接口
• 输入是来自一个还是多个其他系统？
• 输出是来自一个还是多个其他系统？
• 输入、输出格式是否预定义？
用户
• 谁使用系统？
• 几类用户？
• 每类用户技术水平如何？
过程
• 资源、材料
• 系统构造需要哪些人员、技能
• 多少⽂文档？
• 在线还是本地？电子还是纸质
• 读者有哪些？
• 标准

引出质量需求的问题
性能
可靠性
安全性
可用性
可维护性
精度与精确性
交付时间及成本

需求过程

需求工程（RE）——软件工程的子领域，包括系统需求工程和软件需求工程。软件需求工程的管理划分为以下过程：

参与需求分析的人员
客户/用户
系统分析师
项目经理
领域专家

需求分析的困难
1. 沟通中遇到的问题
既不明白也说不清；
心里很清楚，但却说不清；
对业务非常熟悉，表述也很清晰。
2. 需求的易变性
唯一不变的就是变化


3. 分析人员和顾客理解有误
软件系统分析人员不可能都是全才。客户表达的需求，不同的分析人员可能有不同的理解。如果分析人员理解错了，可能会导致开发人员白干活，吃力不讨好。

分析人员写好需求说明书后，要请客户方的各个代表验证。如果问题很复杂，双方都不太明白，就有必要请开发人员快速构造软件的原型，双方再次论证需求说明书是否正确。

需求获取的方法
常规的需求获取的方法：
访谈
情景分析
联合分析小组
建立快速软件原型

获取需求的5W1H方法
Why
为什么要设计该系统？
What
系统要做什么？有什么功能？
Who
什么人用？什么人付钱？
When
购买后什么时候使用？需要使用多长时间？
Where
哪里使用？会不会换地方？
How
怎样使用?

5W1H方法
在需求阶段引入这5W+1H的定律，在一定程度上保证了系统需求的准确性，也使得项目经理或需求分析人员可以非常有序的有条理的开展需求挖掘和调研活动，这样的安排用户在配合上也非常清晰，知道如何与项目人员配合。

第一个W定律—Why定律
Why就是为什么用户要引入系统，引入新的信息系统对用户有什么帮助，在总体工作效能上如何实现一个最终的结果？

Why定律是要求在需求开始时，项目经理就应该明确的，这个项目是为了改进用户工作效率；提高部门间的协作机制；加快对客户反应的体系服务；提升企业的竞争力等等。

有了这么一个Why引入思想，项目经理就可以理清用户最终要的是可以提供给他们什么样的系统，在系统的定位和建立上，就有一个明确地最终目标。其次，有了一个总体的目标性，从各业务流程的要求入手，引入第二个W定律—What定律。
第二个W定律—What定律
What则是这个系统要做什么？实现什么？就是客户提出的各业务流程问题、流程局限性问题、系统要解决的问题等，在这个What的基础上，把系统划分成各功能模块，逐步弄清模块流程需求、功能需求、结构需求。
第三、四、五个定律—Who、When、Where
这个阶段其实就是需求细化阶段，在What定律的基础上，细分系统的用户需求：分析什么人，在什么时间，什么阶段可以或必须操作这个功能，结合前面的What定律，理清系统的流程阶段划分，记录并分析系统功能实现的细节。

在这个阶段就可以产生系统需求的用例图，作为下阶段设计的依据。
1H定律—How定律
就是怎样实现系统了，在前面的Why、What、Who、When、Where基础上，已经搭建了一个非常好的系统需求基础框架，如何在这些用户需求的基础上，分析系统的需求，如何进行需求规格的分析与下阶段的设计、实现工作，就是How to accomplish the system了。

需求分析的步骤

需求分析建模
需求分析是对要解决的问题进行详细的分析，弄清问题的要求，包括需要输入什么数据，要得到什么结果，最后应输出什么。

需求分析的过程也是需求建模的过程，最终用户所看到的系统的一个概念模型，是对需求的抽象描述，解决目标系统“做什么”的问题。

软件工程始于一系列的建模工作，需求分析建模是逐层深入解决问题的办法。需求分析模型是系统的第一个技术表示。

需求导出和分析过程的模型如下：


需求规格说明编写
需求规格说明（Software Requirement Specification，SRS）需要指明软件的基本特征和性质，以及期望和选择的特征和性质，和其他系统元素的接口，建立软件必须满足的约束。
当客户和开发团队对要开发的产品达成一致的协议时，即产生需求规格说明文档。它是整个开发工作的基础，要具有准确性和一致性，并且直观易读，易于修改。

需求验证
需求验证是为了确保需求说明准确、完整，表达必要的质量特点。

需求验证务必保证需求符合完整性、准确性、可行性、必要性、一致性、可跟踪性及可验证性这些良好特征。

需求规格说明提交后，开发人员要与客户对需求分析的结果进行验证，以SRS为输入，通过符号执行，模拟或快速原型等途径，分析需求的正确性和可行性。验证过后需要进行签字确认。

需求变更
在进行需求分析时要防患于未然，尽可能的分析清楚哪些是稳定的需求，哪些是易变的需求，以便在进行系统设计时，将软件的核心建立在稳定的需求上，同时留出变更空间。

需求变更管理是组织、控制和文档化需求的系统方法。