软件需求获取与结构化分析方法

10
分析人员或客户理解有误
• 有个外星人间谍潜伏到地球刺探情报，它给 上司写了一份报告：“主宰地球的是车。它 们喝汽油，靠四个轮子滚动前进。嗓门极大， 在夜里双眼能射出强光。……有趣的是，车 里住着一种叫作‘人’的寄生虫，这些寄生 虫完全控制了车。” • 下雨天留人天留人不留 – 下雨天留人，天留人不留。（不留） – 下雨天，留人天，留人不？留！（留）
需求获取的过程
6. 需求整理与总结

必须对上面步骤取得的需求资料进行整理和总结， 确定对软件系统的综合要求，即软件的需求。 并提出这些需求实现条件，以及需求应达到的标 准。 这些需求包括功能需求、性能需求、环境需求、 可靠性需求、安全保密要求、用户界面需求、资 源使用需求、软件成本消耗与开发进度需求等。
• Standish请求被调查者解释项目失败的原因： • 不完整的需求（13.1%） • 缺少用户的参与（12.4%） • 缺乏资源（10.6%） • 不切实际的期望（9.9%） • 缺乏行政支持（9.3%） • 改变需求和规格说明（8.7%） • 缺乏计划（8.1%） • 不再需要该系统（7.5%）
26
软件需求分析阶段的任务
（6）每一个需求都是相关的吗？ 有时，某个需求会不必要地限制开发人员，或 者会包含于客户需要没有直接关系的功能。 例如：即使坦克的主要职责是穿过不平坦的地 带，一个将军也可能会决定使坦克的新软件系 统能够让士兵们收发电子邮件。我们应该尽力 使这种“特征爆炸”处于控制之中，并努力使 风险承担着集中于必需的、值得要的需求。
缺乏软件工程师
固定价合同
Inadequate communications for system integration 系统集成阶段 , 交流与沟通不充分 Insufficient experience as team 团队缺乏经验 缺乏应用领域专家
Shortage of application domain experts
12
13
项目失败的原因分析
No.
1 2 3 4 5 6 7 8 9 10
Top 10 Factors
Inadequate requirements specification Changes in requirements 需求的改变 缺乏系统工程师 缺乏了解软件特性的经理人 缺乏合格的项目经理 不充分的需求规范
软件需求分析阶段的任务
3. 需求定义
将已经过分析的需求清晰、全面、系统、准确地 描述成为正式的文档，这一步定义需求的工作就 是编写需求规格说明。
软件需求分析阶段的任务
4. 需求验证
为了确保已定义的需求（需求规格说明）准确无 误，并能为客户（或用户）理解和接受，需要对 其进行严格的评审。
3.2 结构化分析方法
11
分析人员或客户理解有误
• 有一个软件人员滔滔不绝地向客户讲解在 “信息高速公路上做广告”的种种好处，客 户听得津津有味。最后，心动的客户对软件 人员说：“好得很，就让我们马上行动起来 吧。请您决定广告牌的尺寸和放在哪条高速 公路上，我立即派人去做。” • 客户表达的需求，不同的分析人员可能有不 同的理解。适当时候有必要快速构造软件的 原型。
需求获取的过程
5. 确定目标系统的业务工作流 具体到当前待开发的应用系统，确定系统的业务工作流和 主要的业务规则，采取需求调研的方法获取所需的信息。 例如，针对信息系统的需求调研方法如下： (1) 调研用户的组织结构、岗位设臵、职责定义，从功能 上区分有多少个子系统，划分系统的大致范围，明确系统 的目标。 (2) 调研每个子系统的工作流程、功能与处理规则，收集 原始信息资料，用数据流来表示物流、资金流、信息流三 者的关系。 (3) 对调研内容事先准备，针对不同管理层次的用户询问 不同的问题，列出问题清单。将操作层、管理层、决策层 的需求既联系又区分开来，形成一个需求的层次。
平均值
4.5 4.3 4.2 4.1 4.1 3.9 3.8 3.8 3.6 3.6
Shortage of systems engineers Shortage of software managers
Shortage of qualified project managers Shortage of software engineers Fixed - price contract
27
软件需求分析阶段的任务
（7）需求是可测试的吗？ 如果需求能够提示验收测试，需求就是 可测试的。 例如：我们可能测试这样的需求：系统 应该对查询提供实时响应。我们不知道 “实时响应”是什么。但是，如果给出 适配标准，说系统应该在两秒内做出相 应，那么，我们就能够确切地知道如何 测试系统对查询的反应。
需求自身经常变动
• Marshall P. Cline, Greg A. Lomow, C++ FAQs, Addison-Wesley, 1995 记载：没有一个软件的需求改动 少于三次。唯一只改动需求两次的客户是个死人。这个可 怜的家伙还是在运送第三次需求的路上被车子撞死的。
• “需求会变动”是事实，在进行需求分析时就要留神： • （1）分析清楚哪些是稳定的需求，哪些是易变的需求。 将软件的核心建筑在稳定的需求上。 • （2）在合同中一定要说清楚“做什么”和“不做什么”。 如果合同含含糊糊，日后扯皮的事情就多。
需求获取的过程
1. 开发高层的业务模型 2. 定义项目范围和高层需求 3. 识别用户类和用户代表 系统的不同用户之间在很多方面存在差异，例如： (1) 使用产品的频率； (2) 用户在应用领域的经验和使用计算机系统的技 能； (3) 所用到的产品功能； (4) 为支持业务过程所进行的工作； (5) 访问权限和安全级别
需求获取的任务和原则
2. 需求获取应遵循的原则
(1) 深入浅出的原则。就是说，需求获取要尽可能 全面、细致。获取的需求是个全集，目标系统真 正实现的是个子集。 (2) 以流程为主线的原则。在与用户交流的过程中， 应该用流程将所有的内容串起来。如信息、组织 结构、处理规则等。这样便于交流沟通。流程的 描述既有宏观描述，也有微观描述。
24
软件需求分析阶段的任务
（4）需求是完备的吗？ 如果需求指定了所有约束下、所有状态下的、 所有可能的输入、输出以及必需的行为，那么 这组需求是完备的。 例如：工资系统应该描述某个雇员在支付薪水 前离开、升职或者需要提前支取薪水时会发生 什么。
25
软件需求分析阶段的任务
（5）需求是可行的吗？ 关于客户需要的解决方案确实存在吗？ 例如：假定客户想要用户访问几千英里 以外的主机，而且希望远程用户的响应 时间要和本地用户的一样，这样需求可 能就是不可行的。
23
软件需求分析阶段的任务
（3）需求是无二义性的吗？ 如果需求的多个读者能够一致、有效地解释需求，那 么需求就是无二义性的。 例如：一个人造卫星控制系统的用户要求足够的精确 性以支持任务计划。该需求并没有告诉我们什么任务 计划需要支持。客户和开发人员可能对与需要的精确 度有着相当不同的理解。对“任务计划”含义的进一 步讨论可能产生更为精确的需求：“在标识卫星位置 的过程中，位置误差应该在沿着轨道方向小于50英尺， 偏离轨道的方向小于30英尺。”通过这个更为详细的 需求，我们能够检验位置误差，并确切地知道是否满 足了需求。
5
为什么需求很重要？
• 需求错误的代价可能会很高昂。 • Boehm和Papaccio报告，如果在需求定义过程中 找出并修复一个基于需求的问题只需花费1美元， 那么，在设计过程中做这些工作就要花费5美元， 在编码过程中就要花费10美元，在单元测试过程 中就要花费20美元，而在系统交付后要花费200 美元之多！ • 因此，花时间理解问题及其背景，然后在第一时 间内修复需求，这样做是值得的。
软件需求分析阶段的任务
• 可以把软件需求分析阶段的工作分为4个步骤，即 获取需求、分析需求、定义需求和验证需求，如 图所示。
软件需求分析阶段的工作步骤
软件需求分析阶段的任务
1. 需求获取
通过启发、引导从客户（或用户）那里得到的原始 需求是他们的业务要求（needs），简称为N。
软件需求分析阶段的任务
3 = Serious
Scale: 5 = Very Serious
1 = No Serious
Source: Carnegie-Mellon University, Software Engineering Institute
需求获取的任务和原则
1. 需求获取的任务
(1) 发现和分析问题，并分析问题的原因/结果关系。 (2) 与用户进行各种方式的交流，并使用调查研究 方法收集信息。 (3) 按照三个成分观察问题的不同侧面：即数据、 过程和接口。 (4) 将获取的需求文档化，形式有用例、决策表、 需求表等。
6
需求获取的任务和原则
• 导出需求变得如此困难的原因归为以下几 个方面的问题：

系统的目标或范围问题； 需求不准确性问题 ； 需求的易变问题 ；
需求获取除了需要有专业的系统分析师，还需要 通过有效的客户／开发者的合作才能成功。
客户说不清楚需求
• 有些客户心里非常清楚想要什么，但却说 不明白。 • 如说买鞋子。我们非常了解自已的脚，但 没法说清楚脚的大小和形状。只能拿鞋子 去试，试穿时感觉到舒服才会买鞋。
2. 需Βιβλιοθήκη Baidu分析
（1）需求是正确的吗？ 我们和客户都应该评审需求文档，确保它们符合我们 对需求的理解。 （2）需求是一致的吗？ 需求之间有没有冲突？ 例如，如果某个需求规定，最多可以有10个用户同时 使用系统，而另外一个需求表述，在某种情况下，可 以有20个同时使用系统的用户，那么，这两个需求就 是不一致的。
28
软件需求分析阶段的任务
（8）需求是可跟踪的吗？ 是否对需求进行精心组织并唯一标记， 以达到易于引用的目的？需求定义中的 每一条是否都在需求规格说明中存在对 应？反过来也是这样吗？
29
软件需求分析阶段的任务
2. 需求分析
由于分析的过程会对获取的需求做部分调整，也即 从获取的需求N中去掉了一些a，又补充了一些c， 从而得到的是分析的需求R1（b+c）。
• 结构化分析方法


传统的分析建模方法称为结构化分析 （structured analysis，SA）方法。 最有代表性的是一种面向数据流进行需求分析的 方法，最初于20世纪70年代由D.Ross提出，后 来又经过扩充，形成了今天的结构化分析方法的 框架。
8
客户说不清楚需求
• 如果客户本身就懂软件开发，能把需求说 得清清楚楚，这样的需求分析将会非常轻 松、愉快。 • 如果客户全不懂软件，但信任软件开发方。 则分析人员可以引导客户，先阐述常规的 需求，再由客户否定不需要的，最终确定 客户真正的需求。 • 若是“不懂装懂”或者“半懂充内行”的 客户，他们可能会提出不切实际的需求， 那么沟通和协商都会很困难。 9
第3章 软件需求获取与结构化分析方法
• • • • • 需求获取与需求分析阶段的任务 结构化分析方法 系统需求规格说明 需求评审 需求管理
3.1 需求获取与需求分析阶段的任务
• 需求获取的任务和原则 • 需求获取的过程 • 软件需求分析阶段的任务
需求获取的任务和原则
• 需求获取的主要任务是与客户或用户沟通，了解 系统或产品的目标是什么？客户或用户想要实现 什么？系统和产品如何满足业务的要求，最终系 统或产品如何用于日常工作？ • 获取并理解用户的需求是软件工程师所面对的最 困难的任务之一。
为什么需求很重要？
• 1994年，Standish Group调查了350多家 公司的8000多个软件项目，了解它们的进 展情况。调查结果让人吃惊，31%的软件 项目在完成之前就取消了。另外，在大公 司中，只有9%的项目按时在预算内交付， 而在小公司中，满足这些标准的有16%。
4
为什么需求很重要？
需求获取的过程
4. 获取具体的需求
确定了项目范围和高层需求，并确定了用户类及用户代表 后，就需要获取更具体、完整和详细的需求。具体需求的 来源可以来自以下几种典型的途径。 (1) 与用户进行交流。 (2) 现有产品或竞争产品的描述文档。
(3) 系统需求规格说明。 (4) 当前系统的问题报告和改进要求。 (5) 市场调查和用户问卷调查。 (6) 观察用户如何工作。