文档介绍：需求工程与分析
彭小娟
******@
87818938
1
*
回顾
系统工程
基于计算机的系统
可行性研究的任务
社会/法律可行性
技术可行性
经济可行性
可行性研究的步骤
推荐可行的方案
编写可性和精度？
数据流量？
数据需保持的时间？
25
资源需求
软件运行时所需的数据、软件。内存空间等资源。
软件开发、维护所需的人力、支撑软件、开发设备等。
26
安全保密要求
需对访问系统或系统信息加以控制吗？
如何隔离用户之间的数据？
用户程序如何与其它程序和操作系统隔离？
系统备份要求？
27
*
质量保证
系统的可靠性要求？
系统必须监测和隔离错误吗？
规定系统平均出错时间？
出错后，重启系统允许的时间？
系统变化如何反映到设计中？
维护是否包括对系统的改进？
系统的可移植性？
28
*
软件需求各组成部分之间的关系
29
*
需求获取的难点
问题的多面性
获取中的问题
领域知识缺乏
利害关系人与开发人员的交流问题
不完备性和不一致性
需求易变性
需求错误的类型
30
*
问题的多面性
31
*
需求获取中的问题
32
沟通漏斗
想的好
说不清
你心里想的
100%
你嘴上说的
80%
别人听到的
60%
悟的少
听不明
别人听的懂的
40%
→
→
33
*
需求错误的类型
34
需求获取的方法与策略
建立顺畅的通信途径
访谈与调查
观察用户操作流程
组成联合小组
用例
35
*
需求获取的原则
将复杂问题分解、逐层细化
能够表达和理解问题的数据域和功能域
建立模型
36
*
有效需求实践
对方法的承诺
尽力并利用负责需求的联合团队
定义真实的客户需求
使用不断改进需求过程
迭代使用系统需求和体系结构过程
运用机制维护项目组之间的沟通
选择熟悉的方法并维护一组工作产品
执行需求检验与确认
提供适应需求变更的有效机制
使用业界、机构和项目证明的、已知的、熟悉的最佳实践，推动开发工作
37
*
定义真实的客户需求
将总项目费用8%-14%用于需求过程
培训项目组和项目管理人员更多地关心需求工程
找到项目倡导者
开发项目前景和范围定义
找一位需求工程师，并且通过领域专家完成需求工程任务
培训开发人员不要做出需求决定，不要自行发挥
使用不同手段获取用户需求和期望
培训需求工程师编写好的需求
记录每条需求的基本原理
使用方法和自动化工具分析和跟踪需求，并为需求划分优先级
开展同行评审和审查
尽量考虑使用适当的方法
需求应该采用文字或图表的方法记录下来
大型系统的高层次系统需求数量大约在50-200条之间
38
*
阶段结果
要开发的系统或产品的范围
参加需求获取过程的利害人名单
描述考虑要用于系统的技术环境的文档
通过功能组织起来的需求列表
在适当时为每个需求指定领域约束的一系列语句
用例的规格说明
39
*
需求分析与协商
任务
是发现、求精、建模和规约的过程
分析的原则（P54）
过程（图示）
问题识别
评估和综合
建模
规约
编制需求分析文档
评审
协商：不实际的目标、冲突的目标
40
需求分析的作用
软件设计
软件需求分析
系统工程
41
*
需求分析任务
42
分析的原则
问题的信息域必须被表示和理解
软件将完成的功能必须被定义
软件的行为必须被表示
描述信息、功能和行为的模型必须被划分，可以分层次地揭示细节
分析过程应该从要素信息移向实现细节
43
需求分析过程图示
44
系统建模
常用的建模方法
面向数据流的结构化分析方法（SA）
面向数据结构的分析方法
面向对象的分析方法（OOA）等
原型方法
其它各种方法
*
45
*
46
*
面向数据流的需求分析的方法
适合于数据处理类型软件的需求分析
用抽象模型的概念，按照软件内部数据传递、变换的关系，自顶向下逐层分解，直到找到满足功能要求的所有可实现的软件为止
使用工具（图示）
数据流图，数据词典，结构化英语，判定表与判定树
特点
具有严格的原则
简单实用，适合于数据处理领域问题
对不是以数据流为主干的系统无奈
难以确定数据流之间的变换
“数据字典爆炸”
47
分析模型的结构
控制规约
数据
字典
数据
流图
E-R图
状态-迁图
加
工
规
约
数
据
对
象
描
述
48
需求规约
规约可以是一份写就的文档，一个图形化的模型，一个形式化的数学模型，一组