软件工程-第三章 需求分析

目录

 

3.1 需求分析

3.1.1 需求获取

3.1.2 需求分析的过程

一、需求确认

二、需求变更

3.1.3 需求分析的任务＆需求规格文档编制

一、需求分析的任务

二、软件需求规格文档编制

3.2 面向过程的分析方法

3.2.1 面向过程的分析方法

1、需求分析模型概述

2、面向过程分析模型 ——结构化分析方法

3.2.2 数据流图（DFD）初步

3.2.3 数据流图进阶（一）

3.2.4 数据流图进阶（二）

3.2.5 检查数据流图的原则

3.3 面向对象的分析方法

3.3.1 面向对象的分析方法

3.3.2 用例图初步

3.3.3 用例图进阶

1、关联(Association)

2、泛化(Inheritance)：对用例的方式进行分解（查询信息：按编号查询、按名称查询）

3、包含(Include)：对用例的动词进行具体分解（管理账号：增加账号、减少账号、修改账号）

4、扩展(Extend)

☺包含(include)、扩展(extend)的区别

3.3.4 活动图

一、简述

二、构成

♥如何绘制活动图

---

3.1 需求分析

3.1.1 需求获取

1. 需求分析的概念

（1）地位：需求分析是软件开发的第一个阶段；这是一个至关重要的环节，关系着系统开发的成败

 

（2）任务：确定系统必须具有的功能、性能，系统要求的运行环境，并且预测系统发展的前景

 

（3）换句话说，需求就是以一种清晰、简洁、一致、无二义性的方式，

     对一个待开发系统中各个有意义方面的陈述的一个集合

 

 

2、修正需求错误的代价

 

 

3、需求获取 / 需求抓取 / 需求发现 / 需求获得

（1）软件需求的来源

（2）软件工程师收集这些软件需求的方法

 

（0）获取到的需求的类型

  Δ1、功能性需求：要求产品必须实现某些功能

       例如，学校的选课软件只允许有学生身份的用户浏览并选择课程，

       同时要求学生选择某一门课时必须要满足“先修课”的 要求等

 

  Δ2、非功能需求：必须遵循的标准，外部界面的细节，使用的工具，实现的约束条件，质量属性…

       例如，股票交易系统必须在一定时间内返回用户查询结果（它对时间的要求比“科技文献检索”

       网站要高）；

       火车票购票系统、大学选课软件必须能支持一定数量的用户同时访问等  

 

（1）需求来源

  Δ1、用户目标     Δ2、领域知识     Δ3、投资者

  Δ4、运行环境     Δ5、组织环境

 

 

（2）需求获取技术

  Δ1、采访

  Δ2、设定情景（用例）

  Δ3、原型

  Δ4、会议

  Δ5、观察商业过程和工作流

 

 

4、需求获取面临的挑战

（1）客户说不清楚需求

（2）需求易变性

（3）问题的复杂性和对问题空间理解的不完备性与不一致性

 

 

5、经验

（1）尽可能地分析清楚哪些是稳定的需求，哪些是易变的需求

     以便在进行系统设计时，将软件的核心 建筑在 稳定的需求上，否则将会吃尽苦头

（2）在合同中一定要说清楚“做什么”和“不做什么”

 

 

6、需求诱导十原则

 

 

3.1.2 需求分析的过程

 

一、需求确认

Step1：需求获取（上一节）

 

Step2：需求分析（需求提炼）

（1）定义：对应用问题及环境的理解和分析，为问题涉及的信息、功能、系统行为建立模型

           将用户需求精确化、完全化，最终形成下一步（需求描述）的需求规格说明书

 

（2）核心：建立分析模型

 

（3）采用多种形式描述需求，通过建立需求的多种视图，揭示出一些更深的问题

（4）还包括与客户的交流以澄清某些易混淆的问题，并明确哪些需求更为重要，

     其目的是确保所有风险承担者尽早地对项目达成共识并对将来的产品有个相同而清晰的认识

 

 

Step3：需求描述：软件需求规格说明书

（1）软件需求规格说明书の定义：软件系统的需求规格说明，是对待开发系统的行为的完整描述

                               它包含了功能性需求、非功能性需求

 

（2）需求分析工作完成的一个基本标志 : 形成了一份完整的、规范的需求规格说明书

 

（3）需求规格说明书の目的：为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解，             

                           使之成为整个开发工作的基础

 

 

Step4：需求验证

1、必要性

（1）如果在后续的开发or当系统投入使用时才发现需求文档中的错误，就会导致更大代价的返工

（2）由需求问题而对系统做变更的成本比修改设计或代码错误的成本要大的多

（3）假设需求阶段引入1个错误的需求，设计时对这个需 求需要5~10条设计实现，

     1条设计需要 5~10条程序，1条程序需要3~5种测试组 合测试。

 

2、工作：对需求文档执行检查

（1）有效性检查：检查不同用户使用不同功能的有效性

（2）一致性检查：在文档中，需求之间不应该冲突

（3）完备性检查：需求文档应该包括所有用户想要的功能和约束

（4）现实性检查：检查保证能利用现有技术实现需求

 

3、需求验证技术

（1）需求评审

（2）利用原型检验系统是否符合用户的真正需要

（3）对每个需求编写概念性的测试用例。

（4）编写用户手册。用浅显易懂的语言描述用户可见的功能。

（5）自动的一致性分析。可用CASE工具检验需求模型的一致性。

 

二、需求变更

    处理流程

 

 

3.1.3 需求分析的任务＆需求规格文档编制

一、需求分析的任务

1、建立分析模型：面向过程分析模型，面向对象分析模型

   准确地定义未来系统的目标，确定为了满足用户的需求系统必须做什么

 

2、编写需求说明

   用《需求规格说明书》规范的形式准确地表达用户的需求

 

 

二、软件需求规格文档编制

1、沟通活动通用任务集

（1）识别主要客户和共利益者

（2）与主要客户会谈“上下文无关的问题” ，以确定

  ① 业务需要和商业价值

  ② 最终用户的特性\需要

  ③ 需要的用户可见输出

  ④ 业务约束

（3）写一页项目范围的说明

（4）评审范围说明，并应客户要求做出相应修改

（5）与客户/最终用户进行协作，确定：

  ① 采用标准格式记录客户可见的使用场景

  ② 输入和输出

  ③ 重要的软件特性、功能和行为

  ④ 客户定义的商业风险

（6）描述场景、输入/输出、特性/功能以及风险

（7）与客户细化场景、输入/输出、特性/功能以及风险

（8）为每个用户场景、特性、功能和行为分配客户定义的优先级

（9）回顾搜集的所有信息并修订

（10）为计划活动做准备

 

 

2、软件需求规格说明的原则

（1）从现实中分离功能，即描述要“做什么”而不是“怎样实现”

（2）要求使用面向处理的规格说明语言（或称系统定义语言）

（3）如果被开发软件只是大系统中的一个元素，那么整个大系统也包括在规格说明的描述之中

（4）规格说明必须包括系统运行环境

（5）规格说明必须是一个认识模型

（6）规格说明必须是可操作的

（7）规格说明必须容许不完备性并允许扩充

（8）规格说明必须局部化和松散耦合

 

3、软件需求规格说明的结构

   IEEE标准为需求文档提出了以下结构，组织机构内部可以基于此标准扩展：

（1）引言

  a.需求文档的目的

  b.文档约定

  c.预期的读者和阅读建议d.产品范围

  e.参考文献

 

（2）综合描述

  a.产品前景

  b.产品功能与优先级

  c.用户特征

  d.运行环境

  e.设计与实现上的限制<