第3章 需求获取

标签： 软件需求工程

《软件需求工程》 毋国庆 第二版 个人笔记

---

• 第3章 需求获取
  • • 确定需求开发计划
    • 确定项目的目标和范围
    • 确定调查对象
    • 实地收集需求信息
    • 确定非功能需求
    • 在收集需求信息中应该注意的问题
    • 使用场景技术的需求获取

---

1. 确定需求开发计划

• 基本任务：确定需求开发的实施步骤，给出手机需求活动的具体安排和进度。
• 重点是：分析、理解和描述用户的需求，着重于软件系统“做什么”，而不是如何实现软件系统。

2. 确定项目的目标和范围

• 基本任务：根据项目目标把项目相关人员定位到一个共同和明确的方向上，并决定软件系统的范围。
• 项目的目标主要包括项目开发的目的和意义，以及软件系统应实现的目标（即目标需求）
• 项目的范围：指软件系统具体应包括和不应包括的部分，以及软件系统所涉及的各个方面。

• 不同的人会从不同的角度提出不同的目标需求，例如（自动售货机）：
  
  • 从开发商角度：
    
    1. 为客户提供便利的自动售货功能
    2. 同故宫管理系统能想顾客提供品种较为齐全的消费品
    3. 吸引顾客对商品的兴趣
    4. 高可靠性
  • 从零售商角度：
    
    1. 能吸引和方便更多的顾客
    2. 代替人工操作
  • 从开发人员的角度
    
    1. 使用较为先进的开发技术和工具
    2. 建立高科技系统

• 确定项目范围的好处是：
  
  1. 可以判断用户所提出的需求信息是否对项目合适
  2. 有些用户需求信息可能是建议，这些建议是项目之外的，但可能有价值。因此可适当改变项目范围来适应这样的需求

3. 确定调查对象

• 基本任务：明确地确定来自不同层次的需求来源的用户，并将其分类。
• （必须搞清楚的问题：谁是产品的用户）

• 对用户分层次：
  
  1. 提出目标需求的用户：他们阐明软件系统的高层次概念，如开发项目的目的、总体规划、主要业务内容。
  2. 提出业务需求和功能需求的用户：他们相当清楚要使该系统完成什么任务，以及系统应具备的重要功能和特性等。
  3. 软件开发人员（系统分析员）：他们必须从用户的角度，根据用户提供的需求信息和业务流程理解和分析出软件系统应实现的具体功能和非功能需求，从而使软件系统能按照用户要求完成任务。

• 用户代表的义务：
  
  1. 给分析人员讲解业务及说明业务方面的术语等专业问题
  2. 抽出时间清楚地说明需求，并不断完善
  3. 当说明系统需求时，力求准确详细
  4. 需要时，要及时对需求做出决策
  5. 要尊重开发人员的成本估算和对需求的可行性分析
  6. 对单项需求、系统特性或用例划分优先级
  7. 评审需求文档和原型
  8. 一旦知道要对项目需求进行变更，要马上与开发人员联系
  9. 在要求需求变更时，应遵照开发组织确定的工作过程来处理
  10. 尊重需求工程中的开发人员采用的流程（过程）

• 典型的软件需求来源
  
  1. 直接和简介使用软件系统的用户
  2. 系统需求规格说明书
  3. 市场调查和用户问卷调查
  4. 已开发出的和待开发的同类软件系统的描述和文档
  5. 对人工系统中存在的问题的报告和增强要求
  6. 观察正在工作的用户
  7. 用户工作内容的分析

4.实地收集需求信息

• 任务:到现场实地调查和与用户交流，收集和理解用户需求信息
• 面临的困难：
  
  1. 用户方面（没有充分的时间、利益关系、用户自身素质问题）
  2. 开发人员方面（缺乏用户的业务知识，交流问题）

• 三个步骤：

  1. 向掌握“全局”的负责人调查
  2. 向部门负责人调查
  3. 向业务人员调查

• 实地收集需求信息的方式

  1. 座谈会方式
  2. 书面咨询的方式（问问题）
  3. 利用用例表示方法

• 需求信息的分类：
  
  1. 目标需求：描述用户或开发机构通过产品可获得的利益或利润，以及与产品相关的发展规划等方面的信息。
  2. 用例说明：有关如何利用系统完成业务任务或如何实现用户目标的陈述可能就是用例，而特定的任务描述更需使用用例说明。
  3. 业务规则：当一个客户说一些活动智能在特定的条件下由一些特定的人来完成时，该用户可能在描述一个业务规则。
  4. 功能需求：功能需求定义了系统应该做什么，他们是软件需求规格说明书的一部分
  5. 性能需求：对系统如何能很好地执行某些行为或让用户采取某一措施的陈述就是性能需求，这是一种非功能需求。
  6. 外部接口需求：描述了系统与外部的联系。（从《某些设备》读取信号，给《某些系统》发送消息，以某种格式读取文件。。。）
  7. 限制：指一些合理限制设计者和程序员选择的条件，它们代表了另一种类型的非功能需求，必须把这些需求写入软件需求规格说明书。（必须使用《某种数据库或程序语言》，不能申请多于《一定数量的内存》，必须与《其他应用程序》一致。。。）
  8. 数据定义：当客户描述一个数据项或一个复杂的业务数据结构的格式、允许或默认值时，就是在进行数据定义
  9. 解决方案：（这是客户在说系统如何设计实现，而不是做什么，这不是需求，是建议）

5. 确定非功能需求

• 非功能需求是衡量软件能否良好运行的定性指标。
• 一些常见非功能需求：
  
  1. 可靠性
  2. 可扩充性
  3. 安全性
  4. 互操作性
  5. 健壮性
  6. 易使用性
  7. 可维护性
  8. 可移植性
  9. 可重用性

• 在收集需求信息中应注意的问题
  
  1. 应能适当地调整收集范围
  2. 尽量把用户所做的假设解释清楚，特别是发生冲突的部分
  3. 尽量理解用户用于表达他们需求的思维过程，特别是尽量熟悉和掌握用户具有的一些专业知识和术语
  4. 在收集需求信息时，应尽量避免受不熟悉细节的影响
  5. 应尽量避免讨论一些具体的解决方案，因为需求阶段的工作是弄清楚软件系统做什么，而不是怎么做
  6. 需求信息收集工作的结束，不要没完没了的

6. 在收集需求信息中应该注意的问题

• 要注意以下问题：
  
  1. 应能适当地调整收集范围
  2. 尽量把用户所做的假设解释清楚
  3. 尽量理解用户用于表达他们需求的思维过程，特别是尽量熟悉和掌握用户具有的一些专业知识和属于
  4. 在收集信息时，应尽量避免受不熟悉细节的影响
  5. 应尽量避免讨论一些具体的解决方案
  6. 需求信息收集工作的结束，不要没完没了的

7. 使用场景技术的需求获取

• 场景：用户与软件系统为实现某个目标而进行交互活动过程的描述

• 应包含的内容：

  1. 执行者（用户）
  2. 进入场景前系统状态的描述
  3. 执行者的目的
  4. 动作和事件系列（包括正常和非正常的事件流）

• 例子（使用以上的描述形式）（Windows98切断PC电源的场景）

  • 执行者（用户）：王某
  • 进入场景前系统状态的描述：使用PC的经验是1年，几乎每天使用。另外，发送电子邮件的工作已结束
  • 执行者的目的：退出Windows98，并且切断PC电源
  • 动作和事件系统：图3-2中的第2段文字，从按下“开始”按钮到切断PC事件结束为止。

• 场景的典型表示形式

• 使用用例的需求获取（ATM取出现金用例）（用例描述）