软件工程需求分析.ppt

软件工程需求分析
第一页，共29页
*
一、软件工程（2） ：迭代模型
迭代模型：不断迭代
用例驱动、架构优先
软件过程模型—典型
优先完成核心部分
不断向外扩展，可能要修正部分核心代码，但总体而言，
核心逐步稳定，并不断扩大范围
统一分析、设计、编码理念：OOA、OOD、OOP
统一建模语言：UML
采用瀑布模型：需求分析 客户确认设计 客户确认
编码单元测试集成客户确认
用例图：表示系统的功能，并支持其操作者
第二页，共29页
*
一、软件工程（3）：结构化与面向对象的理念区别
理念区别：考虑问题的视角完全不同
问题1
问题2
问题3
问题4
解决问题1
解决问题2
解决问题3
简单映射
简单演进
存在交叉
问题变更可能导致系统崩溃
不支持迭代
所有问题必须事前明确
开发过程中，无法和客户确认
基本要到开发完成，
才能确定是否解决问题
很多到最后才发现需要变更
影响全局
抽象
支持迭代
核心逐步稳定并扩大
次要问题可以逐步明确
不断发布新版本，客户不断确认
不断确认变更，影响范围有限
结构化思维，OO编程语言
类识别错误
类继承错误
仍不支持迭代
无法形成稳定的核心
变更将导致全局影响
第三页，共29页
*
一、软件工程（4）：解决方法
问题定义及可行性研究
核心需求分析OOA
架构指导
关键需求1
关键需求2
次要需求N
设计，客户确认
编码
集成
集成测试
设计，客户确认
编码
集成
集成测试
设计，客户确认
编码
集成
集成测试
功能测试
部署、维护
可行性研究
核心需求规格说明书、UI原型
关键是用例图、活动图
架构指导书
关键是逻辑架构图和规范
需求规格说明书迭代
详细设计说明书迭代
关键是类图、对象关系图
DB、UI
类代码及单元测试报告
集成
集成测试报告
功能测试报告QC
部署方案、维护计划
评审
评审
评审
每
日
构
建
评审
关键：
迭代，含需求迭代
类识别
核心识别
每日构建，阶段性确认
核心逐步稳定并扩大
第四页，共29页
*
一、软件工程（4）：解决方法
SA
AD
DEV
QC
QA
PM




















尽快START
客户确认
第五页，共29页
*
二、可行性分析
工作内容：
进度安排/里程碑确定
人员配置、资源投入
开发环境、配置管理
项目规范、沟通管理
风险识别及规避措施
关键点：
和客户确定阶段性成果的交付、内部评审、客户评审
识别项目风险，针对技术风险和客户进行沟通
明确项目范围
去除不可行的需求或技术
对不明确需求进行调研
可行性分析的目的，使项目：
成本可行、效益可行
进度可行
资源配置可行
客户需求可行
技术要求可行、质量可行
社会环境、市场、政策可行
同时识别出项目风险，加以控制
第六页，共29页
*
三、需求分析（1）：建立逻辑模型
需求规格说明书要素：
项目目标、组织架构、功能需求、性能需求、部署环境、可靠性需求、安全性要求及权限模型、UI需求、进度要求、资源投入、成本约束、边界/接口、使用者、现状
关键点：
进一步明确项目范围
去除不可行的需求或技术
对不明确需求进行调研
工作内容：
最核心问题必须明确，次要问题可以迭代
采用合适的分析工具
编制需求规格说明书
需求迭代
需求评审
需求说明书
完整、清晰：需求覆盖、描述完整
一致性：上下文无冲突，无二义性
可行性：需求可行、技术可行
接口：识别系统边界
需求覆盖
限制、假设
风险识别
目的：
目标一致
需求覆盖
通过UI原型更容易需求理解
通过UI原型更容易客户确认需求
识别、控制风险
作为项目计划的输入
需求调研
：收集、细化
需求分析
：原型、优化
需求评审、客户确认
：改进、认同
第七页，共29页
*
三、需求分析（2）：结构化分析方法
问题1
问题2