认识软件需求
一、可行性分析
- 项目的成功与否取决于多种因素，包括社会因素、认为因素以及技术因素等等，可行性分析是其中的重要因素之一。
- 可行性分析的内容-->软件产品技术路线、软件成本和效益分析、软件风险的量化分析、可重用构件技术分析
- 可行性分析的四个要素
- 经济：维护阶段的费用、项目扩展的收益
- 技术：给定时间完成功能、软件性能是否有保障、是否允许引进新技术
- 环境：市场与政策（法律、知识产权）
- 人：综合特质（流动 开发、配合、协调领导能力等）
二、需求分析-->决定软件产品质量的关键
1.需求分析的任务
- 功能需求分析：系统必须提供的服务
- 性能需求分析：速度、效率、反应时间等
- 质量需求
- 外部接口需求
- 出错处理需求
- 约束条件
- 未来扩展需求：功能、网络扩展等内容
2.需求分析的基本原则
(1)表达和理解问题的信息域
(2)建立描述系统信息、功能和行为的模型
(3)对系统模型按照一定形式分解
(4)分清系统的逻辑视图和物理视图
逻辑视图：系统要达到的功能和要处理的信息之间的关系 与实现细节无关
物理视图：处理功能和信息结构的实际表现形式 与实现细节有关
3.需求分析过程
- 目标认定：必须完成的功能、性能要求、有无外部接口等
- 分析和综合：进行需求确认 保证需求的正确性、一致性和无歧义性
- 需求建模：建立功能模型、行为模型和数据模型
- 需求规格说明书：需求分析阶段的最终产物
- 需求评审
- 变更
三、需求诱导-->将用户真正需求挖掘出来
- 规约技术
- 面向团队的需求获取技术
- 软件开发人员、客户-->需求分析团队
- 用于分析和规约的早期阶段，是需求分析的主流技术
- 质量功能部署-->最大限度让用户满意
- 强调 正常、期望、令人振奋 三类需求
- USE—CASE-->参与者和系统的交互方式
四、结构化分析方法(Structured Analysis SA)
1.结构化分析方法
（1）面向数据流的需求分析方法 适合分析大型的数据处理系统
（2）基本思想：
- 分解-->对于复杂的系统，将大问题分解为若干小问题，然后对小问题分别求解
- 抽象-->先考虑问题最本质的属性 暂把细节略去，以后再逐层添加细节，直至涉及到最详细的内容。利用最本质的属性表示一个系统的方法为抽象
（3）特点
- 本质上是借助模型实现需求分析的一种活动
- 模型：
- 数据模型-->实体关系图
- 功能模型-->数据流图
- 行为模型-->状态转换图
- 数据字典
结构化分析的过程就是要创建数据模型、功能模型和行为模型。
2.结构化需求分析技术
（1）实体关系图（Entity Relation Diagram,ERD）
- 描述数据对象、属性、对象间关系 以实体、关系、属性三个基本概念概括数据的基本结构
- 数据对象：被软件所标识的具有一系列属性的抽象信息 每个数据对象的实体被唯一标识
- 对象属性：实体具有的特性
- 对象间关系1:1 1:N N:M
（2） 数据流图(data flow diagram,DFD) 应用于数据驱动的系统
- 描述信息流和数据从输入移动到输出时被应用的变换的图形化技术
- 基本组成
- 数据源点和终点：系统外部环境中的实体（人员、组织或者其他软件） 使用矩形框表示
- 加工或处理：对数据流进行的操作或变换，使用圆角矩形或者椭圆表示
- 数据流：数据在系统内传播的路径，使用箭头表示
- 数据存储：暂时保存的数据 为数据处理提供所需要的输入流或者仓库存储，使用双直线表示
- 数据流的关系
（3）控制流模型图-->状态转换图
- 事件驱动的系统：系统对事件的响应-->系统状态的改变
- 状态：特定时刻系统可以被观察到的行为模式，外部事件可以改变状态；分为初始状态（仅有一个）、中间状态、最终状态（可能有多种）
- 事件：系统在某个特定时刻发生的事情 导致系统产生动作、状态发生改变
- 图示
（4）数据词典
- 描述分析过程中的数据和对象，对分析模型中出现的所有名字进行定义
- 内容：
- 名字-->数据、控制项、数据存储和外部实体的名称
- 别名
- 使用地点与方法-->使用数据或控制项的加工列表
- 内容描述：描述数据或者控制项的符号
- 其他说明
- 作用：独立于软件需求规格说明书，减少编程人员在数据定义时的混乱和无序 增加项目参与者对关键信息理解的一致性
- 组成：数据流、数据项、文件、基本加工
五、软件快速原型实现
1.软件原型：能够呈现系统的主要功能和接口实现的“软件样机”。
快速原型技术是一种有效的需求分析方法
2.原型的实现方法-->突出原型软件实现的快速功能
- 可重用的软件构件技术
- 第四代编程技术-->简答易学、用户界面良好、非过程化程度高、面向问题、不必告诉计算机怎么做
- 形式化规格说明书和原型环境
3.流程
4.实现策略
- 抛弃式原型：用户通过软件原型发现需求中的漏洞并提出足够多反馈意见时即可抛弃
- 演化式原型：原型通过多次演化更新，形成可交付的软件产品
目的：使用户的需求更加明确和具体
六、需求评审
1.需求评审：彻底验证软件需求规格说明书的正确性 使得利益相关双方彻底理解需求
2.评审：需求的正确性、一致性、完整性、可实施性、可靠性、合理性
3.评审
- 准备：软件开发人员认真准备需求规格说明书 对需求做尽可能详细的描述
- 多层次多阶段评审结合：需求分析分成不同的阶段，进行范围大小不等的阶段性评审
- 跟踪和反馈：评审结束后给出问题的确定性结论
UML 图形整理
1.UML图种类
对于整个系统：
功能使用用例图描述
静态结构由类图和对象图描述
动态行为由状态图、顺序图、协作图和活动图描述
物理架构由构件图和部署图描述
2.UML图例
3.用例图use case diagram
- 定义系统的功能需求，从系统的外部观看系统的功能，并不描述系统内部对功能的具体实现
- 从外部执行者的角度描述系统提供的功能
- 一个用例（a）包含（include）另外一个用例（b）:用例a需要用例b的功能并且总是执行这个内含的用例
- 一个用例（a）扩展（extend）另外一个用例（b）:用例a可能（可选择的）用到用例b的功能，于是去扩展用例b。
4.类图 class diagram
- 描述系统的静态结构，表示系统中的类以及类与类之间的关系
5.对象图 object diagram
- 描述一组对象以及它们之间的关系，表示类的实例对象
- 对象图是对类图的一种实例化，是系统某个时期可能存在的具体对象实例
6.状态图 state chart diagram
- 表示一个状态机，强调对象行为的时间顺序
- 对类的补充，展开此类对象可能的状态和发生某些事件时状态的转移情况
7.顺序图sequence diagram & 协作图 collaboration diagram
- 表示一组对象之间的动态协作关系
- 顺序图：对象之间发送消息的时间顺序
- 协作图：收发信息的对象的组织结构
8.构件图 component diagram
- 描述程序代码的组织结构，构件以及它们之间的依赖关系，表示系统的静态实现视图
9.部署图deployment diagram
- 系统中软件和硬件的物理架构，表示系统运行时的处理节点以及节点中构件的配置
