第三章 软件需求

一、软件需求

1.错误需求

错误需求具有扩散效应

错误需求的修复代价会随着进展越来越高

2.定义

以一种清晰、简洁、一致且无二义性的方式，描述用户对 目标软件系统在功能、行为、性能、设计约束等方面的期望，是在开 发过程中对系统的约束。

通常用于表达“做什么”，而不描述“如何做” 。

3.作用

“Requirement is the Basics of Quality”

– 充分理解现实中的业务问题，并作为软件设计的基础；

– 为软件项目的成本、时间、风险估计提供准确的依据；

– 减少开发工作量，避免将时间与资源浪费在设计与实现错误的需求上；

– 通过提供需求文档和需求基线，来有效的管理系统演化与变更；

– 作为顾客与开发团队之间正式合同的一部分；

– 为最终的验收测试提供标准和依据。

二、软件需求的分类

不同层次的软件需求：业务需求、用户需求、功能需求

1.业务需求

客户对于系统的高层次目标要求 (high-level objectives) ，业务需求通常来自项目投资人、购买产品的 客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求 描述了组织为什么要开发一个系统，即组织希望达到的目标。定义了 项目的远景和范畴(vision and scope)。

2.用户需求

用户需求(User Requirements)：从用户角度描述的系统功能需求与非 功能需求，通常只涉及系统的外部行为而不涉及内部特性。用户需求 描述了用户能使用系统来做些什么。

3.功能需求

系统应该提供的功能或服 务，通常涉及用户或外部系统与该系统之间的交互，不考虑系统内部 的实现细节。规定开发人员必须在产品中实现的软件功能，用户利用 这些功能来完成任务，满足业务需求。

4.非功能需求

从各个角度对系统 的约束和限制，反映了客户对软件系统质量和性能(quality and performance)的额外要求，如响应时间、数据精度、可靠性等。

– 可用性(Usability):是一种用户可以学会的操作、输入准备、解释一个系统 或者构件输出的状况。 – 可靠性(Reliability):是系统或构件在给定时间内、指定条件下，完成其要求 功能的能力。

– 性能(Performance):需求要考虑系统的定量属性，比如响应时间，吞吐量、 有效性和准确性。

– 可支持性(Supportability):需求关注于在进行部署后系统的变化状况，比如 包括可适配性、可维护性、可移植性等。

5.约束条件

系统设计和实现时必须满足的限制条件，对 其进行权衡或调整是相当困难的，甚至是不可能的；

6.业务规则

对某些功能的可执行性或内部执行逻辑的 一些限定条件。

– 通常表达为“如果…，那么…”的形式

– 通常是一些容易发生变化的功能；

7.外部接口需求

描述系统与其所处 的外部环境之间如何进行交互

– 硬件接口需求

– 软件接口需求

– 通信接口需求

三、需求的质量

1.好的需求具备的特征

• 完整性：每一项需求都必须将所要实现的功能描述清楚
• 正确性：每一项需求都必须准确地陈述其要开发的功能；
• 可行性：每一项需求都必须是在已知系统和环境的权能和限制范围内 可以实施的
• 必要性：每一项需求都应把客户真正所需要的和最终系统所需遵从的 标准记录下来
• 划分优先级：给每项需求、特性或使用实例分配一个实施优先级以指 明它在特定产品中所占的分量
• 无二义性：对所有需求说明的读者都只能有一个明确统一的解释
• 可验证性：检查一下每项需求是否能通过设计测试用例或其它的验证 方法，如用演示、检测等来确定产品是否确实按需求实现

2.产生不合格需求的原因

• 无足够用户参与
• 用户需求的不断增加
• 模棱两可的需求
• 不必要的特性
• 过于精简的规格说明
• 忽略了用户分类
• 不准确的计划

四、需求工程

定义：用工程的理念和方法来指导软件需求实践，它提供了一系列的过程、策略、 方法学和具，帮助需求工程师加强对业务或领域问题及其环境的理解，获 取和分析软件需求，指导软件需求的文档化和评审，以尽可能获得准确、一 致和完整的软件需求，产生软件需求的相关软件制品。

1.总体流程

2.需求开发所包含的活动

（1）需求获取(Requirement Elicitation)

通过与用户的交流，对现有系统的观察及对任务进行分析，从而开发、捕获和修订用户的需求

（2）需求分析(Requirement Analysis)

对收集到的需求进 行提炼、分析和审查，为最终 用户所看到的系统建立概念化 的分析模型

（3）需求规格说明(Software Requirement Specification, SRS)

– 需求开发的结果

– 精确的、形式化的阐述一个软件系统必须提供的功能、非功能、所要考虑的 限制条件等

– 作为用户和开发者之间的一个契约

– 是用户、分析人员和设计人员之间进行理解和交流的手段

（4）需求验证(Requirement Verification）

以需求规格说明为输入，通过 评审、模拟或快速原型等途径，分析需求规格的正确性和可行性，发 现存在的错误或缺陷并及时更改和补充。

五、需求获取 

需求工程整体流程：

1.需求获取的目标

– 收集准备建立的系统和正在使用的系统的信息，并从这些信息中提取用户和 系统需求。

– 为下一步的需求分析提供素材。

2.需求获取的基本步骤

• 第1步：了解相关背景和领域/行业的知识，确定产品所期望的用户类；
• 第2步：与客户企业或组织的高层人员进行交流，了解实际用户任务和 目标以及这些任务所支持的业务需求；
• 第3步：与客户企业或组织的底层人员进行交流，获取每个用户类的详 细的用户需求；
• 第4步：整理需求纪要，发现新问题，并重复1‐3步；
• 第5步：需求分类和组织，以区别功能需求、非功能需求、约束条件、 业务规则、外部接口需求、建议解决方法和附加信息；
• 第6步：优先排序和冲突解决；
• 第7步：得到最终需求清单，并与客户做最终签字确认。

3.困难

4.需求获取的途径

• 面对面访谈(face-to-face interviewing) 
• 调查问卷
• 现场观察(observing on the scene)
• 专题讨论会(workshop)
• 头脑风暴(brainstorming)
• 分析业务资料 
• 软件原型
• 群体化方法

5.需求分析的主要内容

对客户输入进行分类

（1）业务需求

描述客户可以从产品中得到的资金、市场或其它业务利润 的需求

（2）业务规则

一些活动只能在特定的条件下，由一些特定的人来完成时， 该用户可能在描述一个业务规则

（3）功能需求

– 客户所说的诸如“用户应该能”或者“系统应该”，这是最可能的功能需求。

– 功能需求描述了系统所展示的可观察的行为，并且大多数是处于执行者—系统响应顺序的环境中。

– 功能需求定义了系统应该做什么，它们组成了软件需求规格说明的一部分。

（4）非功能需求

对系统如何能很好地执行某些行为或让用户采取某一措施的陈述就是质量属 性，这是一种非功能需求。

（5）外部接口需求

这类需求描述了系统与外部的联系。

（6）约束条件

是指一些合理限制设计者和程序员选择的条件，它们代表 了另一种类型的非功能需求，必须把这些需求写入软件需求规格说明。

（7）数据定义

当客户描述一个数据项或一个复杂的业务数据结构的格式、 允许值或缺省值时，他们正在进行数据定义。

六、面向对象方法中的“用例” (Use Case)

用例(Use Case)：表示系统所提供的服务或可执行的某种行为，定义了系统是如何被参与者所使用的

1.用例方法的基本思想

从用户的角度来看，他们并不想了解系统的内 部结构和设计，他们所关心的是系统所能提供的服务，也就是被开发 出来的系统将是如何被使用的。

2.用例模型构成

– 参与者(Actor) ：存在于被定义系统外部并与该系统发生交互的人或其他系 统，代表系统的使用者或使用环境;

– 用例(Use Case)

– 系统边界(System Boundry)：明晰时可以省略;

– 通讯关联(Communication Association) ：用于表示参与者和用例之间的对 应关系，它表示参与者使用了系统中的哪些服务(用例)、系统所提供的服务 (用例)是被哪些参与者所使用的;

3.用例的特征

– 行为序列(sequences of actions)：一个用例由一组可产生某些特定结果的行 为构成，这些行为是不可再分解的(接收用户输入、执行、产生结果)

– 系统执行(system performs)：系统为外部角色提供服务；

– 可观测到的、有价值的结果(observable result of value)：用例必须对用户产 生价值；

– 特定的角色(particular actor)：某人、某台设备、某外部系统等等，能够触 发某些行为。

七、用例建模

用例建模的基本过程：

§ Step 1：确定系统边界

§ Step 2：识别并描述参与者(actor)

§ Step 3：确定每个参与者目标，识别用例(use case)

§ Step 4：识别参与者与用例之间的通讯关联(association)；

§ Step 5：给出每一个用例的详细描述

§ Step 6：细化用例模型

Step 1：确定系统边界

确定系统边界是为了识别出什么在系统之内，什么在系统之外，进而 识别出什么是系统的职责。

典型的系统边界包括：一个组织中的部门或整个组织；硬件设备或硬 件/软件边界。

Step 2：识别并描述参与者

– 谁使用这个系统的功能？

– 谁从该系统获得信息？

– 谁向该系统提供信息？

– 该系统需要访问(读写)哪些外部硬件设备？

– 谁来负责维护和管理这个系统以保证其正常运行？

– 该系统需要与其他系统进行交互吗？

Step 3：识别用例(use case)

找到参与者之后，据此来确定系统的用例。

主要分析各参与者目标， 需要系统提供什么样的服务，或者说参与者是如何使用系统的。

Step 4：识别参与者与用例之间的通讯关联

Step 5：给出用例的详细描述

场景(scenario)：是参与者和系统之间的一系列特定的活动交互，也称 为用例实例(use case instance)，事件流。

分为常规流和扩展流两类：

– 常规流：描述该用例最正常的一种场景，系统执行一系列活动步骤来响应参 与者提出的服务请求；

– 扩展流/备选流：负责描述用例执行过程中异常的或偶尔发生的一些场景。

（1）常规事件流（场景）

§ 每一个步骤都需要用数字编号以清楚地标明步骤的先后顺序

§ 用一句简短的标题来概括每一步骤的主要内容

§ 对每一步骤，从正反两个方面来描述

（2）扩展事件流（场景）

扩展流的描述格式可以与基本流的格式一致，也需要编号并以标题概述其内容。

Step 6：细化用例模型

还可以描述：

– 参与者与参与者之间的泛化(generalization)

– 用例和用例之间的包含(include)

– 用例和用例之间的扩展(extend)

– 用例和用例之间的泛化(generalization)关系

（1）用例之间的关系：包含(include)

§ “包含关系”是通过在关联关系上加入>标记来表示；

§ 语义：用例1会用到用例2（无条件执行），用例2的事件流将被插入到 用例1的事件流中。

§ 一般表示为公共功能

（2）用例之间的关系：扩展(extend)

§ “扩展关系”是通过在关联关系上加入>标记来表示；

§ 语义：用例2在某些特定情况下（有条件执行）会用到用例1，此时， 用例1的事件流将被插入到用例2的事件流中。

§ 一般表示为异常功能，大多是扩展流程

（3）用例之间的关系：泛化(generalization)

§ 当多个用例共同拥有一种类似的结构和行为的时候，可将它们的共性抽 象成为父用例，其他的用例作为泛化关系中的子用例；

§ 子用例继承了父用例所有的结构、行为和关系

八、用例模型的提交物

• 用例模型
• 每个用例的详细描述
• 术语表：所用到的术语说明
• 补充规约：非功能性需求的说明

九、活动图和泳道图

对用例描述的图形化补充

UML活动图(Activity Diagram)提供一种可视化的流程图方式，对use case的事件流进行直观展示，以便于读者更好的理解。

1.两种形式

– 传统的活动图：只涉及一个参与者；

– 泳道图(swim-lane diagram)：侧重于描述多个参与者的活动之间的交互关系。

2.UML活动图

活动图的基本要素：

– 起始点、结束点；

– 活动；决策点；

– 活动之间的时序连接；活动之间的并发点；

– 泳道；

3.OO分析的步骤

§ Step 1：角色识别

§ Step 2：用例识别

§ Step 3：绘制用例图

§ Step 4：对用例图进行精化

§ 针对每个用例：

– Step 5：撰写用例描述

– Step 6：绘制用例的活动(泳道)图

– Step 7：识别分析类(边界类、控制类、实体类)

– Step 8：识别每个类的属性和方法

– Step 9：绘制分析类图

– Step 10：绘制领域类图

– Step 11：绘制时序图

十、敏捷开发中的“用户故事” (User Story)

用户故事：从用户的角度来描述用户渴望得到的功能：角色(谁要使用这个功能)、 目标/活动(需要完成什么样的功能)、商业价值(为什么需要这个功能， 这个功能带来什么样的价值)。

1.用户故事的描述

作为一个<角色>, 我想要<活动>, 以便于<商业价值>

2.用户故事卡的正面: Conversation

3.用户故事卡的反面：Confirmation

4.好的用户故事应具备的特征：INVEST

§ Independent – 尽可能独立；

§ Negotiable – 可讨论的。它不是一个合同，没有详细的规约，后续开 发阶段可以不断协商和改进；

§ Valuable – 对用户/客户有价值的，以用户可理解的语言书写，是系统 的“特性”而非“开发任务” ；

§ Estimatable – 其工作量可以估计；

§ Small – 小，而不是大；

§ Testable – 可测试的、可验证的

5.分割用户故事

– 1、按照用户故事所支持数据的边界来分割大型用户故事（例如导入GBQ文 件、Excel等）。

– 2、从主用户故事中除去对例外或错误条件的处理（相当于用户的基本路径 和扩展路径），从而把一个大型用户故事变小许多。

– 3、按照操作边界分割，把大型用户故事分割成独立的建立、读取、更新和 删除操作（例如预算二次导入，或者新增时需要向导、规则比较复杂时也可 以单独成一个故事来描述）。

– 4、考虑去除横切考虑（例如安全处理、日志记录、错误处理等），为用户 故事建立两个版本：一个具备对横切考虑的支持，另一个不具备这种支持。

– 5、考虑功能性需求和非功能性需求隔离到不同的用户故事，从而分割大型 用户故事（性能）。

6.用户故事支持验收测试

§ 在每个用户故事背后，列出未来用户测试时可能使用的“测试用例” ，作为该故事是否已被完整实现的基本标准。

§ 对应于敏捷开发的一个基本思想：在写代码之前先写测试(TestDriven Development, TDD)

7.用户故事支持敏捷迭代计划

§ 针对识别出的每一个故事，使用Story Point估算其工作量；

§ 团队成员分别估计(而不是由项目经理一人决定)，差异较大时面对面讨 论，发现分歧，形成共识；

§ 形成估算清单。

8.评定用户故事的优先级

最简单的方法就是问问客户最希望在下一个 迭代中最想看到的是哪一些功能。

9.用户故事支持敏捷迭代计划

§ 对用户故事排列优先级；

§ 安排责任人；

§ 汇聚为迭代计划并发布；

§ 开发过程中监控进度。