软件需求总结(总)

软件需求工程复习归纳

课程目标：

1. 系统地掌握需求开发和管理的技术和方法
2. 掌握需求分析和建模的技术和方法
3. 掌握需求规格的验证和评审等要点和方法
4. 结合具体的实际项目开发，解决软件项目开发中的有关需求的各种问题
5. 能够适应目前各种应用项目的系统的需求开发和管理工作
6. 学习并掌握软件需求实践的工具和技巧
7. 分析和解答软件工程实践中的困难和问题

软件工程与需求工程

生存期模型：

概念：软件开发的一种过程性框架

类型：瀑布模型、V模型、原型模型、增量式模型

瀑布模型：需求分析→设计→程序编码→软件测试→运行维护

不合格需求的主要原因

• 用户参与度不够
• 用户需求不要断增多
• 需求说明模糊
• 不必要的特性
• 规格说明太粗
• 不对用户分类
• 计划不准确

需求工程

基本概念：一种获取，组织并记录系统需求的系统化方法。以及一个使客户与项目团队不断变更的系统需求达成并保持一致的过程

层次特征：业务需求、用户需求、功能需求

主要过程：需求开发过程、需求管理过程

注：需求分析：解决什么业务问题

​ 需求规格说明：所开发的系统提供什么功能，性能

面对对象

概念：面对对象由对象、类、继承、通信四个概念组成。

**对象：**在现实世界时是客观世界中的一个实体；在面向对象程序中表达成计算机理解、可操纵、具有一定属性的行为和对象；在计算机世界中是一个可标识的存储区域

封装：把对象的全部属性和全部服务结合到一起，形成一个不可分割的独立单位（对象），尽可能隐藏对象的全部细节（信息隐蔽）

继承：使用已存在的定义做为基础建立新定义的技术

统一建模语言UML

概念：基于面向对象的可视化的通用(General)建模语言

用例图：

作用：描述系统的功能需求

组成：执行者(Actor)、用例(Use Case)、执行者用例的关系、用例之间的关系

• 执行者：执行者是指用户在系统中所扮演的角色，执行者可以是人，也可以是一个外界系统（ps：用例总是由执行者启动的）
• 用例：执行的一系列动作（功能），用椭圆符号表示

用例之间的关系：泛化、使用、扩展关系

• 泛化：用例之间的一般与特殊关系

• 《include》：一个用例使用另外一个用例

• 《extends》：通过什么被扩展用例添加动作来扩展用例

类图：

类图包含了一组类似及他们之间的关系

组成：类、属性、操作

关系：

• 关联：一对一，一对多，多对多，单项关联，多项关联
• 依赖：表示两个式多个类之前的调用关系
• 聚集：表示总体的部分的关系
• 泛化：继承关系

状态图：

概念：用来描述一个特定对象的所有可能的状态以及状态转移的事件

状态：所有对象都具有状态,状态是对象执行了一系列活动的结果。当某个事件发生后,对象的状态将发生变化。

• 初态⚫：状态图的起点，只有一个初态。

• 终态◉：状态图的终点，可以有很多个终态。

• 中间状态：名字域+活动域

• 符合状态：可以进一步组合的状态

• 状态迁移："→"通常是由事件引起的

  

活动图（流程图）：

定义：描述了系统中各种活动的执行顺序

组成：活动、转移、对象流、泳道（采用分组的机制）

转移：转移用带箭头的直线表示，可标注执行该转移的条件，无标注表示顺序执行。

泳道：一个道代表一组对象

对象流：活动图中可以出现对象，对象作为活动输入/输出。（用虚箭头表示）

顺序图：

概念：用来描述对象之间动态的交互行为，着重体现对象之间信息传递的时间顺序。（水平轴→对象，垂直轴→时间）

组成：

• 对象：用矩形框图表示，它们代表参与交互的对象
• 生命线：表示对象存在的时间，在顺序图中生命线表示从对象图标向下延伸的一条虚线
• 激活：过程的执行的时间，包括它等待嵌套过程执行的时间
• 消息：消息作为对象间的一种通信方式来表示

需求获取

项目启动要考虑的问题：

愿景（描述项目核心价值【老大】）、涉众、投入、风险、可行

愿景：

没有度量指标的目标没有意义

• 什么是愿景：在老大看来为什么要开发这个系统

• 愿景的两个要点：1、一定来自老大的想法 2、一定要有度量指标

  例如：愿景→实现电子速汇款 度量指标→数据到账时间短

涉众：

同一件事不同利益视角，探索系统的需求就是探索涉众利益的平衡点

• 划分原因：系统需求易变，业务需求(涉众利益)不变

• 客户是最大的涉众

• 划分涉众优先级

业务建模：

过程：

• 选定业务单元
• 识别业务执行者
• 识别业务用例
• 详述业务用例
• 建立对象模型

业务执行者：业务执行者在业务外面，业务工人在业务里面

业务单元：

概念：一个组织或人群

​ 例：淘宝网业务单元为淘宝网公司及内部人员，业务实体则是淘宝网站

业务用例：

有效的完整目标

只针对业务执行者，为业务执行者提供价值(内部活动不是业务用例)

用例命名：执行者视角→动词+宾语

• 慎用弱名词和弱宾语
• 弱动词：进行、使用、复制、加载、重复….
• 弱名词：数据、报表、表格、表单、系统…

用例的粒度：用例要有路径，路径要有步骤，而这一切都是可观测的

• 最常犯的错误（错把步骤当作用例）

业务对象模型：

概念：业务对象模型（也叫领域模型）是描述业务用例实现的对象模型。它是对业务角色和业务实体之间应该如何联系和协作以执行业务的一种抽象

补充：

业务建模的目的：描述现实，帮助发现软件需求

UML业务建模：用业务用例模型和业务对象来描述现实

系统需求分析：

需求文档编写步骤：

1. 识别系统执行者
2. 识别系统用例
3. 书写系统用例文档
4. 通过关系整理用例
5. 用例的排序和分包

用例文档即为需求文档

识别系统执行者：

系统执行者：谁使用系统的主要功能、谁需要系统的支持已完成日常工作任务、系统需要应付和处理哪些设备、系统需要和哪些外部系统交互、谁对系统运行产生的结果感兴趣、有没有自动发生的事件

业务范围：指这个项目所涉及的所有客户业务，这些业务有没有计算机系统参与都客观存在

系统范围：软件将要实现的那些对应于业务功能的系统功能，从功能性需求来说系统范围是业务范围的一个子集

补充：

系统外，交互的功能需求

有多少执行者就代表有多少接口

识别系统用例：

RUP：系统用例实例（某人用系统做什么）是在系统中执行的一系列动作后（步骤），这些动作将产生执行者可见的价值结果（目标），一个用例定义了一组用例实例（路径）

系统用例：

形式：[执行者]使用系统来[用例]

书写系统用例文档

例：

1、用例编号

2、用例名 （水电站财务部项目）

​ 提交费用单

3、执行者

​ 其他部门人员

4、前置条件 (一个用例开始之前系统所必须的环境和状态)

其他部门人员已经登录系统

5、后置条件 （一个用例成功结束后系统应该具备的状态）

​ 系统已保存费用单

6、涉众利益

其他部门人员（3）-----------希望操作简单，尽快把费用单交给会计。

部门领导（上游）（1）----担心搞错费用的金额和用途。

会计（下游）（2）-----------担心有重复有错误增加工作量。

括号内的数字为涉众的优先级。

前置条件：开始用例前所需的系统及其环境状态

后置条件：用例成功结束后系统应具备的状态

基本路径：用户最想看到、最关心的路径

例：

拓展路径：系统要处理的意外和分支

补充约束：

• 字段列表：

  • "+"→数据序列 “[ ]”→可选项 “{}*”→多个

    {|||}→可能取值 “A=B”把B的结构赋给A

  • 用表达式表示：

    

• 业务规则

  • 分类：事实(设备是资产的一种)、推理(如果过了计划中的交付日期，货物还没有送到，即为“为不按时送货”)、约束(合同的总金额不能超出买房的信用额度)
  • 表示方法：文字说明、决策表、OCL(对象约束语言)

• 非功能需求

  • 非功能需求常常是激烈竞争的决胜点
  • 非功能需求：可用性(可度量)、可靠性、性能…

交互四部曲：动作→验证→改变→回应

书写用户文档：

• 只书写听的懂的
• 使用主动语句(执行者…系统…)
• 遵循四部曲
• 不涉及界面细节
• 基本和拓展分开
• 不要越界

通过关系整理用例：

拓展：分离扩展路径

包含：提取公共步骤，便于复用

泛化：同一业务目的的不同技术实现

何时使用扩展关系：

• 扩展路径步骤多
• 扩展路径内部其他较多扩展点→拓展的拓展

例：

用例的排序与分包：

用例排序

大量用例时的分包：按执行者分包、按主题分包、按开发团队分包、按发布情况分包

包图:

只在软件的开发过程中存在

• 表示：

  • 不同包的模型元素可以同名，在同一个包中不能重名
  • 包中元素具有高内聚、低耦合的有特点

• “+”——是公共的，对所有包可视

• “#”——保护，只能对该包的子包可见

• “-”——私有，对外包不可视

包的联系：

需求管理

调研需求：

• 需求的研究对象
• 需求的调研内容
• 需要调研内容
• 需求结果管理

需求调研内容：功能、接口、用户使用环境、重要性要求、稳定性要求、易用性、性能

需求调研方法:问卷调查、访谈、观察、开会、制作示意图、角色扮演、原型开发

需求变更：

随着系统上线，用户提出的问题和新的需求

易用性问题：界面布局、操作方式、文字表达、排序条件等细节问题，这些问题不解决的话会降低用户体验，此类问题一般应尽量解决。

拒绝变更：

• 并不是软件本身的问题
• 根据愿景分析没必要将系统复杂化提高成本
• 由于客观条件限制，或者技术上做不到的，要予以拒绝

常见问题：

• 对于符合需求的易用性方面的要求，应尽量满足。

• 有些问题可通过改善管理办法来解决。

• 客观条件做不到的、技术上做不到的，应予以拒绝。

• 超出范围的要求，可引导客户做第二期。

• 有些问题需要同时在软件和管理办法上做工作来改善。

”老大“提出的新需求

”老大“的需求必须满足

”老大“提出的需求方案只是一种解决方案，可以通过分析用不同解决方案满足”老大“的根本需求。

需求认知曲线

两种需求认知曲线

敏捷开发与敏捷需求

敏捷过程希望尽快得到可以发布的软件版本，尽快得到反馈

四句宣言：

用户故事：

三要素：角色，功能，价值（按“作为一个…，可以…，以便…”）

作用：

• 作为进度跟踪的依据

• 作为和人交谈的备忘录，敏捷过程提倡足够就好，避免浪费

十二个原则：

特点：

• 在需求模糊或快速变化的前提下，小型开发团队的软件开发活动
• 做到“刚刚好”
• 提高软件开发的效率
• 以积极的态度对待需求的变化
• 短时间不断地交付可运行的软件供用户使用