【系统分析师之路】系统分析师必知必会（需求工程）

【系统分析师之路】系统分析师必知必会（需求工程）

一. 软件需求的分类

• 软件需求可以分为以下几个层次：

1. 业务需求

1. 反映组织机构或客户对系统，产品高层次的目标要求，面向整体全局的需求。
2. 它们在项目视图和范围文档中予以说明。
3. 它是反映企业或客户对系统高层次的目标要求，通常来自项目投资人，购买产品的客户，客户单位的管理员，市场营销部门或产品策划部门等。通过业务需求可以确定项目视图和范围，为以后的开发工作奠定基础。

2. 用户需求

1. 描述用户使用产品必须完成的任务。
2. 在用例文档或方案场景说明中予以说明。
3. 面向用户的视角的需求。
4. 它描述了用户的具体目标，或用户要求系统必须完成的任务。也就是说用户需求描述了用户能使用系统来做些什么。

3. 系统需求

• 是从系统的角度来说名软件的需求，它包括了功能需求，非功能需求和设计约束等。

1. 功能需求

1. 功能需求也称为行为需求，它规定了开发人员必须在系统中实现的软件功能，用户利用这些功能来完成任务，满足业务的要求。
2. 功能需求也称为行为需求

2. 非功能需求

1. 描述系统展现给用户的行为及执行的操作。
2. 包括产品必须遵循的标准，规范和合约；外部界面的具体细节；性能要求；设计或实现的约束条件；质量属性。
3. 非功能需求是指系统必须具备的属性或者品质，又可以分为软件质量属性和其他非功能需求。

3. 设计约束

1. 也称为限制条件或者补充规约，通常是对系统的一些约束说明。
2. 系统约束条件可以分为四类，可以使用进度，成本，质量和功能对其进行分类。

4. 软件功能部署QFD分类

1. 质量功能部署（QFD)是一种将客户要求转化成软件技术需求的技术.
   2.  QFD的目的是最大限度地让客户从软件工程过程中感到满意。
2. QFD确定了三类需求：基本需求，期望需求，兴奋需求。

1. 基本需求

1. 也叫常规需求，用户提出的明确的需求；

2. 期待需求

1. 隐含在产品或系统中，可能由于非常的基础，以至于用户没有显示说明的需求
   2.期望需求也叫做隐式需求，它间接定义了用户对某些特性的期望。

3. 意外需求

1. 叫做兴奋需求；出乎客户意料的东西。

5. 软件质量与需求

• 软件质量强调三个方面的内容

1. 软件需求是测试软件质量的基础；
2. 开发标准定义了一组用于指导软件开发方式的准则；
3. 期望需求(隐式需求)间接定义了用户对某些特性的需求。

【PIECES框架】

1. PIECES框架是对系统非功能需求分类的一种技术。
2. 对各种类型的需求进行分类，使得类似的需求可以组织起来达到汇报，跟踪和验证的目的，还可能帮助确定可能被忽略的需求。

1. 性能（Performance）

1. 用于描述企业当前的运行效率，可以分析当前业务的处理速度。

2. 信息（Information）

1. 信息和数据指标用于描述业务数据的输入，输出，以及处理方面存在的各种问题。

3. 经济（Economic）

• 主要是从成本与收益的角度分析企业当前存在的问题。

4. 控制（Control）

1. 提高信息系统安全和控制的水平。

5. 效率（Efficiency）

1. 提高企业人，财，物等的使用效率。

6. 服务（Service）

1. 提高企业对客户，供应商，合作伙伴，顾客等的服务质量。

【什么是软件需求】

1. 软件需求是指用户对系统在功能，行为，性能，设计约束等方面的期望。
2. 软件需求是指用户解决问题或达到目标所需的条件和能力，是系统或系统部件要满足的合同，标准，规范，或其他正式规定文档所具有的条件或能力，以及反映这些条件或能力的文档说明

【非功能需求分类】

No	需求	分类	理由
01	系统能否采用新方法以降低使用资源的成本	☆效率	降低使用资源的成本就是提高效率的方法
02	系统可接受的吞吐率是多少	性能	吞吐率和响应时间属于性能指标
03	系统可接受的响应时间是多少	性能	吞吐率和响应时间属于性能指标
04	应该减少多少开支或增加多少收益	经济	减少开支和增加收益是系统经济性指标
05	对用户隐私有什么要求	控制	“用户隐私”属于安全性控制的内容
06	对系统的可靠性和可用性有什么要求	☆服务	可靠性和可用性的要求属于服务
07	系统中需要包括哪些文档和培训材料	☆服务	文档和培训资料是为用户提供的服务
08	对外部系统的接口是什么	☆信息	“外部系统的接口”说明系统与外界交互的信息需求

【鱼骨图中人机料法环分类】

No	需求	分类	理由
01	缺少强制履行合同的规定	制度	-
02	合同相关信息没有通知到会员	☆人	是相关人员工作没有完成
03	没有催单提示客户	☆方法	采用的方法不正确
04	没有跟踪执行情况	方法	采用的方法不正确
05	设备成本太高造成价格不合理	材料	成本太高价”是所购买材料价格高
06	合同的履行缺乏灵活性	合同	这个是合同执行的问题
07	账务问题或者隐瞒相关内容	人	属于财务人员工作问题
08	价格太高并且无法修改	☆合同	“价格太高无法修改”是指合同中价格条款

二. 需求工程的定义

1. 需求工程

1）需求工程的概念

1. 所有与需求直接相关的活动叫做需求工程。
2. 需求工程帮助软件工程师更好地理解他们将要解决的问题。
3. 需求工程可以分为两大类，一类是需求开发一类是需求管理。
4. 需求工程并不关心采用何种设计方案解决问题

2）需求工程的作用

• 需求工程为以下工作提供了良好的机制
• 需求工程帮助软件工程师更好地理解他们将要解决的问题。
• 理解客户需要什么，分析要求，评估可行性，协商合理的解决方案，无歧义地详细说明方案，确认规格说明，管理需求以至将这些需求转化为可运行的系统。

2. 需求开发

1. 目的是通过调查与分析，获取用户需求并定义产品需求。
    2. 需求开发的过程有四个：需求收集，需求分析，需求定义，需求验证。
    3. 这四个阶段不一定是线性关系。
    4.  需求开发活动包括以下几个方面:
        1. 确定产品所期望的用户类别
        2. 获取每个用户类的需求。
        3. 了解实际用户任务和目标以及这些任务所支持的业务需求。
        4. 分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量属性,建议解决方法和附加信息。
        5. 将系统级的需求分为几个子系统，并将需求中的一部分分配给软件组件。
        6. 了解相关质量属性的重要性。
        7. 商讨实施优先级的划分。
        8. 将所收集的用户需求编写成文档和模型。

3. 需求管理

1. 确保各方对需求的一致理解，管理和控制需求的变更，以及需求到最终产品的双向跟踪。
2. 需求管理包括了：变更控制，版本控制，需求跟踪，风险管理，需求状态跟踪等五个方面。
3. 需求管理是用来支持需求开发的，需求开发和需求管理通过需求的基线联系在一起。

三. 需求获取

1. What：应该收集什么信息；
2. Where：从什么地方收集这些信息；
3. How：用什么机制或技术来收集信息；

1. 概念定义

1. 在整个需求过程中，需求捕获，需求分析，需求定义和需求验证四个阶段不是瀑布式的发展，而且应该在迭代式的演化过程。
2. 在进行需求捕获时，不要期望着一次就将需求全部收集完毕，而是应该捕获到一些信息后，进行相应的需求分析，并针对分析中发现的疑问和不足，带着问题再进行有针对性的需求捕获工作。

2. 要获取的信息

1. 一是与问题域相关的信息；如业务资料，组织结构图，业务流程，质量体系等；
2. 二是与解决问题相关的信息；
3. 三是用户对系统特别希望与施加的约束信息。

3. 信息来源

1. 客户，现有系统，现有系统用户， 新系统潜在的用户，现有产品，竞争对手的产品，领域专家，技术法规标准。
2. 具体实践的时候先对干系人进行相应的分类，选出干系人代表，建立表格，左边是想要的信息，右边是可能来源。

4. 需求获取的技术

1. 用户访谈，用户调查（问卷调查）
2. 现场观摩，文档考古
3. 书面交流，邮件，即时通信
4. 演示，JRP联合需求计划

5. 采样技术

1. 系统分析师应该查看哪些类型的文档，当文档的数据庞大，无法一一研究时，就需要使用采样技术选出有代表性的数据。
2. 采样技术不仅可以用于收集数据，还可以用于采集访谈用户或者是采集观察用户
3. 通过采样技术，选择部分而不是选择种群的全部，不仅加快了数据收集的过程，而且提高了效率，从而降低了开发成本。
4. 另外，采样技术使用了数理统计原理，能减少数据收集的偏差。
5. 但是，由于采样技术基于统计学原理，样本规模的确定依赖于期望的可信度和已有的先验知识，很大程度上取决于系统分析师的主观因素，对系统分析师个人的经验和能力依赖性很强，要求系统分析师具有较高的水平和丰富的经验。

【样本数量计算】

1. 文档分析中通常采用抽样技术来实现大量不同类型文档的分析，确定样本数量大小是实施抽样的重要工作。
2. 样本数量大小计算公式：    样本数量=0.25x(可信度因子/错误率)2

6. JRP联合需求计划

1）概念

1. 联合需求计划（Joint Requirement Planning, JRP)是一个通过高度结构化组织的群体会议来分析企业内的问题并获取需求的过程。
2. JRP会议包括一些不同的参与者和角色，期望每个参与者都能够参加并主动地参与整个JRP会议。

2）特点

1. 群策群力，收集需求，它不是对需求进行分析和验证。
2. 用在对问题有歧义，对需求不够清晰的时候。
3. 会议要做到言之有物，气氛开放，否则将难以达到预定的效果。所以该花一些时间，让所有的与会者相互认识，以使交流在更加轻松的氛围下进行。

3）参与者

• 系统分析师，用户，开发人员
• 通常该会议的参与人员是6到18人，召开会议时间为一到五个小时。

4）成员作用

1. 负责人：鼓励用户主动参与，一般是管理层，JRP会议对系统项目给予支持，做出需求是否入选最后决策。
2. 主持人：出色的沟通能力，解决矛盾的能力。他主要策划组织会议，引导讨论，鼓励出席者主动参与，解决可能产生的矛盾，确保实现会议预期目标。
3. 用户：确认业务规则和需求，评审设计原型；
4. 管理层：批准项目目标，设置项目优先权，批准进度费用；
5. 记录员：也就是系统分析师，记录讨论细节，会后发放；
6. IT人员：聆听记录用户和管理者问题和需求，不主动发言；

5）JRP会议优点

1. 积极将用户和开发管理者引入项目开发当中；
2. 代替了传统的面谈，节约了开发时间；
3. 有助于用户和管理者达成一致；
4. 解决相互之间矛盾和信息需求；
5. 把原型化技术作为证实需求和获得设计建议批准的手段，发挥原型化技术的优点。

6）流程

• 在JRP实施之前，应制定详细的议程，并严格按议程进行；

1. 按既定的时间安排进行；
2. 尽量完整地记录会议期间的内容；
3. 在讨论期间尽量避免使用专业术语；
4. 充分运用解决冲突的技能；
5. 会议期间设定充分的间歇时间；
6. 鼓励团队取得一致的意见；
7. 保证参加JRP的所有人员能够遵守事先约定的规则。

7. 现场观摩

1. 对于许多复杂的流程和操作而言，是比较难以用言语表达清楚的，而且这样做也会显得很低效。
2. 因此针对这一现象，分析团队可以就一些较复杂较难理解的流程，操作采用现场观摩的方法来获取需求。
3. 具体来说就是走到客户的工作现场，一边观察一边听客户的讲解，甚至可以安排人员跟随客户工作一小段时间。
4. 这样就可以使得分析人员更加直观地理解需求。

8. 阅读历史文档

1. 这种方法也称为文档考古。对于一些数据流比较复杂的，工作表单较多的项目，有时是难以通过说，或者或观察来了解需求细节的。
2. 这个时候可就可以使用阅读历史文档的方法，对历史存在的一些文档进行研究，从中获得所需要的信息。
3. 这个方法的主要风险是历史的文档可能与新系统的流程数据有一些不吻合的地方，并且还可能存在一些原有系统的缺陷。
4. 要想有效地避免和发现这些问题，就需要分析人员能够运用自己的聪明才智，将其与其他需求捕获技术结合对照。
5. 还有一个负面因素就是，这些历史的文档中记载的信息有可能涉及到客户的商业秘密，因此对数据信息的保密也是分析人员基本的职业道德。

1. 详细调查

1. 是系统分析中的重要环节，主要为系统分析和新系统逻辑模型的建立提供详尽的、准确的、完整的、系统的资料
2. 详细调査的主要内容包括现有系统的运行环境和状况、系统功能、业务流程、资源情况、约束条件和薄弱环节等。

2. 抽样调查

1. 某现有系统进行详细调査时，发现该系统业务复杂，涉及岗位较多，系统的历史遗留文档全面、数量很大时使用。

9. 用户访谈

1. 它是最基本的一种需求获取手段。其形式包括结构化和非结构化两种
2. 结构化是指事先准备好一系列的问题，有针对性的进行；非结构化则是只列出一个粗略的的想法，根据访谈的具体情况来发挥。
3. 最有效的访谈是结合这两种方法进行。

1）用户访谈的痛点

1. 用户访谈也存在着许多困难，例如，用户经常较忙，难以安排时间
2. 面谈时信息量大，记录较为困难
3. 沟通需要很多技巧，同时需要系统分析师具有足够的领域知识等。
4. 在访谈时会遇到一些对于组织来说比较机密和敏感的话题，需要分析人员拥有足够多的经验和较强的沟通能力。

2）用户访谈优点

1. 用户访谈具有良好的灵活性，有较为宽广的应用范围。

10. 用户问卷调查

1. 用户访谈时最大的难处就在于很多关键的人员时间有限，不容易安排到过多的时间；而且客户面经常较广，不可能一一访谈。
2. 因此我们就需要借助问卷调查，通过精心设计要问的问题，然后下发到相关人员的手里，让他们填写答案。这样就可以有效的克服前面提到的两个问题。

1）问卷调查的痛点

1. 与用户访谈相比，问卷调查最大的不足之处就是缺乏灵活性
2. 双方未见面，分析人员无法从他们的表情等其他动作来获取一些更隐性的信息
3. 客户有可能在心理上会不重视一张小小的表格，不会认真对待，从而使得反馈的信息不全面。

2）问卷调查的应用场景

1. 较好的做法是将两种技术结合使用，具体来说就是先设计问题，制作成用户调查问卷，下发填写完后进行知识的分组，整理，分析，以获得基础信息，然后再针对这个结果进行小范围的用户访谈，作为补充。

3）提高问卷返还率的方法

1. 解释问卷目的，如何使用信息；
2. 说明人人都要回答；
3. 拜托领导督促；
4. 在全体会议上解答释疑，说明目的；

11. 需求获取实际应用

1. 联合需求计划
   消除需求中出现的冲突，尽可能获取全面、一致的需求
   尽可能多地让用户参与需求获取过程
   系统的改进需求和期望增加的业务功能
2. 实地观察
   获取已有系统中所实现的模式和过程
3. 用户访谈
   系统的改进需求和期望增加的业务功能
   获取当前业务过程中的详细数据并深入了解这些数据产生的原因
4. 问卷调查
   从企业管理人员、销售人员、各种文档资源等尽可能多的来源获取需求
5. 文档分析
   从企业管理人员、销售人员、各种文档资源等尽可能多的来源获取需求
   获取已有系统中所实现的模式和过程

四. 需求分析

1. 需求分析概念

1. 需求分析是提炼、分析和仔细审查已经获取到的需求的过程。
2. 需求分析的目的是确保所有的项目干系人(利益相关者)都理解需求的含义并找出其中的错误、遗漏或其它不足的地方。
3. 需求分析的关键在于对问题域的研究与理解。
4. 为了便于理解问题域，现代软件工程所推荐的需求分析方法是对问题域进行抽象，将其分解为若干个基本元素，然后对元素之间的关系进行建模。
5. 常见的需求分析方法包括面向对象的分析方法、面向问题域的分析方法、结构化分析方法等。而无论采用何种方法，需求分析的主要工作内容都基本相同。

2. 需求分析特征

1. 需求分析是一种软件工程活动，它在系统级软件分配和软件设计间起到桥梁的作用。
2. 需求分析使得系统工程师能够刻画出软件的功能和性能、指明软件和其他系统元素的接口、并建立软件必须满足的约束。
3. 需求分析任务是发现、求精、建模和规约的过程。包括详细地精化初始由系统工程师建立并在软件项目计划中精化的软件范围，创建所需数据、信息和控制流及操作行为的模型。
4. 但是需要注意的是，在需求分析阶段要得到详细的规约是不可能的。客户可能并不能精确地肯定需要什么，开发者可能不能肯定可用什么特定的方法来适当地完成功能和性能。

3. 需求分析技能

• 解决做什么的问题。此阶段系统分析员应具备以下的能力：

1. 熟悉计算机技术
2. 了解用户业务领域相关的知识
3. 能在用户和软件人员之间借助数据处理的概念进行交流。
   ####  4. 需求分析工作七个方面

1. 绘制上下文范围关系图

1. 这种绘制图定义了系统与外部实体之间的界限和接口的简单模型，它可以为需求确定一个范围

2. 创建用户界面原型

1. 用户界面对于一个系统来说是十分重要的，因此在需求分析阶段，通过快速开发工具开发一个抛弃型原型，或者通过PowerPoint，Flash等演示工具制作一个演示原型，甚至用纸和笔画出一些关键的界面接口示意图，将帮助用户更好的理解所要解决的问题，更好地理解系统。

3. 分析需求可行性

1. 对所有获得的需求进行成本，性能和技术实现方面的可行性研究
2. 以及这些需求项是否和其他需求项有冲突，是否有对外的依赖关系。

4. 确定需求优先级

1. 这是一项很重要的工作，迭代开发已经成为了现代软件开发的一个基础，而需求的优先级是制定迭代计划的一个最重要的依据
2. 对于优先级的描述，可以采用满意度和不满意度指标进行说明
3. 其中满意度表示当需求被实现时用户的满意程度，不满意度表示当需求不被实现时用户的不满意度。

5. 为需求建模

1. 这个模型的主要表现形式就是图表，再加上少量的文字描述，
2. 所谓一图抵千字，图形化的描述需求将使得其更加清晰与易懂。
3. 根据采用的分析方法不同，可以使用不同的图形。
4. 例如OOA中的用例模型和领域模型，SA中的DFD图和ER图等。
5. 需求分析模型主要描述系统的数据，功能，用户界面和运行的外部行为，它是系统的一种逻辑表示技术，并不涉及软件的具体实现细节，
6. 需求分析模型可以帮助系统分析师理解需求，使需求分析任务更加容易实现。同时它也是进行软件设计的一个基础，为软件设计提供一个系统的表示视图。

6. 创建数据字典

1. 对系统中用到的所有数据项和结构进行定义，以确保开发人员使用统一的数据定义。

7. 使用质量概念部署

1. 通过将产品特征属性，与对用户的重要性联系起来。
2. 它是在需求优先级的基础上做了一个升华，其原理与满意度和不满意度指标十分接近。

5. 结构化需求分析

1. 基本思想

• 基本思想就是自顶向下，逐层分解，模块化

2. 分析模型

• 以数据字典为核心，围绕核心的三个层次：数据模型，功能模式，行为模型（状态模型）。

3. 基本假设

• 问题域的定义，问题域有限，通过有限步骤可将复杂问题分解到可解决。

4. 工具

1. 使用ER图来描述数据模型；
2. DFD数据流图
3. 状态转换图STD:  适合用来描述行为模型，用来表示事件驱动。
4. 数据字典

5. 工作步骤

1. 研究“物质环境”，获得当前人工系统的具体模型：先画现有系统的DFD，说明系统的输入输出数据流，说明系统的数据流情况，以及经历哪些处理过程。
   2. 从当前系统的具体模型抽象出系统的逻辑模型。
   3. 分析目标系统与当前系统逻辑上的差别，建立目标系统逻辑模型。
   4. 划清人机界限：在确定的逻辑模型中，哪些采用自动化完成，哪些保留手工操作。

6. 局限性

1. 对问题域的研究力度不大
   2. 分析和设计缺乏清晰界限
   3. 在理解和表达人机界面方面是很差的
   4. SA方法强调的是分析数据流，而对时间，控制方面的描述恰恰是不精确的，所以，SA方法原则上不适用于实时系统。
####  【数据流图】

1. 结构化分析中用到的重要的工具和方法就是数据流图。
2. 它是表达系统内数据的流动并通过数据流描述系统功能的一种方法。

1）数据流图概念

1. DFD图被认为是一个系统模型，在信息系统开发中，一般将它作为需求说明书的组成部分。
2. DFD图从数据传递和加工的角度，利用图形符号通过逐层细分地描述系统内到外各个部件的功能和数据在它们之间传递的情况，来说明系统所完成的功能。

2）数据流图作用

1. DFD是理解和表达用户需求的工具，是系统分析的手段。理解DFD图不需要任何的计算机知识，因此通过它同客户交流很方便。
2. DFD概括地描述了系统的内部逻辑过程，是系统分析结果的表达工具，因而也是系统设计的重要参考资料，是系统设计的起点。
3. DFD作为一个存档的文字资料，是进一步修改和充实开发计划的依据。

3）数据流图四个元素

• DFD图中有四个符号组成，分别是：加工，数据流，外部实体（数据源及数据终点），数据存储

1. 数据流
   具有名字和流向的数据，用标有名字的箭头表示；
2. 加工
   是对数据流的变换，一般用圆圈来表示；
3. 数据存储
   它是可访问的存储信息，一般用直线段来表示；
4. 外部实体
   位于被建模的系统之外的信息生产者或消费者，是不能由计算机处理的成分，它们分别表明数据处理过程的数据来源及数据去向，用标有名字的方框表示

4）使用目标

• 即使面对稍微复杂的问题，逐步分解系统，以分层的DFD清晰的表达整个系统
• 画DFD图的基本步骤其实就是“自顶向下，逐层分解”的这么一个过程。

5）画图原则

1. DFD中的所有图形符号只限于四种基本图形元素；
2. 顶层的DFD图必须包含这四种元素，缺一不可。
3. 顶层DFD中的数据流必须封闭在外部实体之间；
4. 每个加工至少有一个输入数据流和一个输出数据流；
5. 在DFD中，可以按层给加工框编号，编号可以表明该加工在哪一个层次，以及上下层单位父图与子图的应对关系；
6. 规定任何一个数据流的子图必须与它上一层的一个加工对应，两者的输入数据流和输出数据流必须一致。父图与子图的平衡；
7. 可以在DFD中加入数据流，帮助用户理解DFD；
8. 图上每个元素都必须有名字
9. DFD中不可夹带控制流

6）与用例图的比较

• 在面向对象设计中，使用数据流分析法的理由是：

1. 数据流图，涉及了系统内部的分析。而用例分析方法不涉及系统的内部。只通过用例分析系统，总是觉得分析得不够彻底。
2. 有些系统，本身就是以数据处理为主要任务的，应用的逻辑集中在数据的处理上，而不是交互过程上，不适合使用用例分析法。
3. 数据流图容易被人看懂，容易在交流中使用，而用例图使用的人少，许多人对他不熟悉。

7）逻辑DFD和物理DFD区别

1. 逻辑DFD和物理DFD最大的区别在于，逻辑DFD只描述了相关的组成要素，
2. 物理DFD则会涉及到具体的实现技术。

【数据字典】

1）定义概念

1. 数据字典是关于数据的信息的集合，也就是对DFD中包含的所有元素的定义的集合。
2. DFD和数据字典共同构成系统的逻辑模型。

2）作用

1. 没有数据字典，那么DFD图就显得不够严格，没有DFD数据字典难以发挥作用

3）包含信息

1. 在数据字典的每一个词条中应该包含以下信息：名称，别名或编号，分类，描述，何处使用。

4）加工描述方法

• 对加工的描述是数据字典的组成内容之一，常用的加工描述方法有结构化语言，判定树和判定表三种。

1. 结构化语言

1. 介于自然语言和形式语言之间的一种半形式化的语言，在自然语言的基础上加了一些限度，使用有限的词汇和有限的语句来描述加工逻辑。

2. 判定树

1. 若一个动作的执行不只依赖一个条件，而与多个条件有关，那么这项策略的表达就比较复杂。那么此时使用判定树来表达更加直观一些。

3. 判定表

1. 一些条件较多，在每个条件下取值也较多的判定问题，可以用判定表表示。
2. 判定表能清晰地表达复杂的条件组合与应做动作之间的对应关系，判定表的优点是能够简洁，无二义性的描述所有的处理规则。
3. 但判定表表示的是静态逻辑，他不能表达加工的顺序，也不能表达循环结构，因此判定表不能成为一种通用的设计工具。

6. 面向对象需求分析

1. 世界由对象组成
2. 识别对象
3. 描述对象属性和关系
4. 了解对象之间如何协作
5. 完成系统功能

1. 定义

1. 面向对象分析基于用例模型，通过对象建模记录确定的对象、对象封装的数据和行为以及对象之间的关系。
2. 面向对象分析包括3个活动：建模系统功能；发现并且确定业务对象；组织对象并确定其关系
3. 面向对象分析中，并不是所有的名词都表示了问题域内有用的业务对象，通过删除对象的同义词、系统范围之外的名词、不具有独特行为的名词、不清楚的名词和另一个对象的行动或属性的名词来最终清理候选对象列表。

2. 两项任务

1. 建立反映问题域静态关系模型（类图）
2. 建立一个反映系统行为的动态模型（用例模型）

• 面向对象分析的任务

1. 建模系统功能
2. 发现并确定业务对象
3. 组织对象并确定对象间的关系

3. 建立问题域

1. 寻找类（名词动词法）
2. 确定类之间的关联（UML类图）
3. 为类添加职责（成员变量，属性，成员方法）

【OOA】

1）基本概念

1. OOA的基本任务是运用面向对象的方法，对问题域和系统责任进行分析和理解
2. 正确认识其中的事物及他们之间的关系，找出描述问题域及系统责任所需的类和对象，定义它们的属性和服务，以及它们之间所形成的结构，静态联系和动态联系。
3. 最终产生一个符合用户需求，并能反映问题域和系统责任的OOA模型及其详细的说明。
4. OOA的任务是做什么，OOD的任务是怎么做。
5. OOA就是直接以问题域中客观存在的事物或概念识别为对象，建立分析模型，用对象的属性和服务分别描述事物的静态特征和行为，并且保留问题域中事物之间关系的原貌。

2）问题域

1. 问题域是指一个包含现实世界事物与概念的领域，这些事物和概念与所设计的系统要解决的问题有关。

【建立用例模型】

• 面向对象分析的四个阶段：识别参与者，合并需求获得用例，细化用例描述，调整用例模型。其中前三个阶段是必须的。
• 在用例图中主要包括参与者，用例和通信关联三种元素。

1. 通信关联表示的是参与者和用例之间的关系，或用例与用例之间的关系。
2. 箭头表示在这一关系中哪一方是对话的主动发起者，箭头所指方是对话的被动接受者，箭尾所指方是对话的主动发起者。
3. 如果不想强调对话中的主动与被动关系，可以使用不带箭头的关联实线。
4. 在用例模型中，信息流不是由通信关联来表示的，该信息流是默认存在的，并且是双向的，它与箭头所指的方向没有关系。

1）★识别用例参与者

1. 谁使用，谁安装，谁启动，谁维护，谁关闭，谁关闭，系统外部资源；
2. 参与者有主要参与者和次要参与者，开发用例的重点是要找到主要参与者。

2）★合并需求获得用例

1. 找到所有的参与者之后就要仔细的检查参与者，为每一个参与者确定用例。
2. 而其中的依据主要可以来源于已经获取得到的特征表。
3. 首先将特征分配给相应的参与者，然后进行合并操作，最后绘制成用例图。
4. 在确定用例的过程中，不能混淆用例和用例所包含的步骤，要注意区分业务用例和系统用例。

3）绘制用例图

• 用例命名：动词+名词；

4）★细化用例描述

1. 用例建模的主要工作是书写用例规约，而不是画图。用例模版为一个给定项目的所有人员定义了用例规约的结果，其内容至少包括用例名，参与者，目标，前置条件，事件流（基本和扩展事件流）后置条件，其他的还可以包括非功能需求，用例的优先级等。

5）☆调整用例

1. 用例的关系有三种：包含，扩展，泛化。
2. UML用关系把事物连接在一起，其所包含的四种关系中，关联关系描述了一组对象之间的结构关系；泛化关系描述特殊元素的对象可以替换一般元素的对象；实现关系是接口和实例之间的关系。

【分析用例模型】

1. 定义概念类
2. 确定类与类之间的关系
3. 为每个类添加职责
4. 建立交互图

1. 发现领域对象

1. 从名词和名词短语中提取对象和属性；
2. 从动词和动词短语中提取操作和关联，而所有格短语通常表明名词应该是属性而不是对象。

2. 识别对象的属性

1. 属性是概念类所具有的特征，从概念建模的角度来看，属性越简单越好。
2. 属性是描述对象静态特征的一个数据项。可以与用户进行交谈提出问题来帮助寻找对象的属性。

3. 识别对象的关系

1. 包括建立类的泛化关系，以及对象的关联关系。
2. 理清类之间的关系类型，确定关系的多重性和角色的导向性。
3. 多重性是指所在类可以实例化的对象数量，即该类的多少个对象在一段特定的时间内可以与另一个类的一个对象相关联；
4. 导向性表示可以通过关联从源类导向到目标类，也就是说给定关联一端的对象就能够容易并直接的得到另一端的对象。

4. 为类添加职责

1. 类的职责包括两个主要内容分别是类所维护的知识，类能够执行的行为。
2. 可以使用状态图来描述系统中单个对象的行为。

5. 建立交互图

1. 多个对象的行为通常采用对象交互图来表示
2. UML2.0提供的交互图有顺序图，交互概览图，通信图和定时图。
3. 顺序图的基本元素有对象，参与者，生命线，激活框，消息和消息路线，其中消息是顺序图的灵魂。

7. 面向问题域的分析方法

1. PDOA更多的强调描述，而少强调建模。它的描述大致分为关注问题域和关注解系统的待求行为这两个方面。
2. 问题框架是PDOA的核心元素，是将问题域建模成为一系列相互关联的子域。
3. 也可以把问题框架看作是开发上下文图，但不同的是上下文图的建模对象是针对解系统，而问题框架则是针对问题域。
4. 也就是说，问题框架的目标就是大量的捕获更多有关问题域的信息。
5. PDOA方法现在还在研究阶段，并未广泛应用。

8. 问题分析阶段主要任务

• 问题分析阶段主要完成对项目开发的问题、机会或指示的更全面的理解。
• 问题分析阶段的主要任务包括：

1）研究问题领域

利用信息系统框架来列出和定义系统领域
数据 - 列出所有与系统当前存储的数据（在文件、数据库、表格中）有关的内容，并按照业务词汇定义每项内容。
过程 – 定义当前为其实现了业务响应（过程）的每个业务事件
接口 – 定义运行当前系统的所有地点和每个地点的所有用户

2）分析问题和机会

• 因果分析是问题分析阶段一项重要技术，可以得出对系统问题的真正理解，并且有助于得到更具有创造性和价值的方案。
• 因果分析中可以分类有：问题或机会，原因和结果。

1. 问题或机会

1. 用户需要用键盘输入复杂且存在重复的商品信息;
2. 商品订单处理速度太慢;

2. 原因和结果

1. 商品订单需要远程访问库存数据并打印提货单;
2. 数据编辑服务器CPU性能较低;

3）分析业务过程（可选）

4）制定系统改进目标

1. 系统目标

1. 订单处理的平均时间减少30%;
2. 自动生成电子提货单并发送给仓库系统；
3. 订单信息页面自动获取商品信息并填充；

2. 约束条件

1. 系统运维人员数量不能增加
2. 商品编码应与原系统商品编码保持一致

5）修改项目计划

6）阶段确认

五. 需求定义

• 需求定义有两种方法：原型化法和严格定义法两种。需求验证与需求定义不同，需求验证解决的是做什么的问题。

1. 严格定义法

• 用于结构化的开发方法当中。
• 它的缺点有：文件量大，要求规范，编写耗时，开发周期长。开发过程可见性差，用户反馈不及时。

1. 所有需求能够被预定义
2. 开发者与用户进行准确交流
3. 采用图形模型/文字可以体现最终系统
4. 修改定义不完善的系统代价昂贵且困难
5. 生命周期各阶段划分正确

2. 原型化法

• 开发者和用户合作反复的过程，是一种迭代循环的一种开发方式。
• 基本假设：

1. 并非所有的开发需求都能在开发前准确的说明
2. 项目沟通者之间的沟通障碍
3. 需要可供用户参与的系统模型
4. 有快速系统构造工具
5. 大量反复不可避免，需求一旦定义，可遵循严格定义法

3. 系统规格说明书SRS

1. 范围，引用文件，需求，合格性规定，需求可追踪性，尚未解决问题，注解，附录。
2. 需求又包括了需求概述，需求规格，能力需求，接口需求，适应性需求，环境需求，计算机资源需求，设计约束，培训。

4. 需求定义文档

1）概念定义

1. 一份需求定义文档可能是项目文档中被阅读和引用最多的文档。

2）包括内容

1. 系统应该提供的功能和服务
2. 非功能需求，包括系统的特征，特点和属性
3. 限制系统开发或者系统运行必须遵守的约束条件
4. 系统必须连接的其他系统的信息

3）应用

1. 系统所有者和用户使用需求定义文档来确认需求以及任何可能产生的变化；并作为验收的依据。
2. 系统分析人员，设计人员和构造人员使用它来理解需要什么以及处理需求变更，开发用于验证系统的测试用例；
3. 项目经理使用它作为制定项目计划、处理变更及验收的依据

【需求定义原则】

No	需求	是否满足	说明
01	软件应能够纠正一位读错误	满足	-
02	软件一般应提供存储介质的均匀擦写功能，以解决因频繁擦写NandFlash的某—固定块而导致该NandFlash过早损害的问题	不满足	需求描述中不能使用一般这样的模糊术语
03	NandFlash擦写是有寿命的	不满足	所提的需求不具体，未量化，不可测试
04	软件对安全性和可靠性有很高的要求	不满足	很高术语模糊，此提法不可验证

六. 需求验证

1. 需求评审

1. 在软件开发的的每个阶段结束前，都需要进行技术评审。
2. 所谓技术评审是指对工作产品进行检查以发现产品中存在的问题。
3. 其中工作产品也称为工件。它不一定是最终的系统，也可以是一个文档一段代码等。
4. 需求评审就是需求开发阶段结束前进行的技术评审，此时的产品就是SRS。
5. SRS的评审是一项精益求精的技术，它可以发现那些二义性的或者不确定的需求，为项目干系人提供需求问题上达成共识的方法。

2. 需求测试

1. 实际上在需求开发阶段是不可能有真正意义上的测试进行，因为还没有可执行的系统
2. 需求测试仅仅是基于文本需求进行概念上的测试。
3. 然而以功能需求为基础（SA方法）或者从用例派生出来（OO方法）的测试用例，可以使项目干系人更加清楚地了解系统的行为。
4. 虽然没有在系统上执行测试用例，但是涉及测试用例的简单动作可以解释许多需求的很多问题。
5. 这种测试用例通常被称为概念测试用例，即不是真正执行的测试用例，它们可以发现SRS中的错误，二义性和遗漏，还可以进行模型分析，以及作为用户验收测试的基础。
6. 在正式的系统测试中，还可以将他们细化为测试用例。

七. 需求管理

1. 它是CMMI2的一个关键的过程域，目标是为软件需求建立基线，保证客户与开发方对变化需求达成并保持一致。
2. 需求管理的主要活动有变更控制，版本控制，需求跟踪和需求状态跟踪四种分类组成。
3. 需求管理包括：需求范围管理，需求变更管理，需求跟踪管理，需求风险管理。

1）需求范围管理

• 包括了启动，范围定义，范围核实，范围变更控制。

2）需求变更管理

• 变更的原因有：

1. 外部环境变化，
2. 需求分析和整体设计不够详密，有错误和遗漏。
3. 新技术的出现有了新的方案和手段
4. 业务流程发生了变化。

• 利用配置库可以实现对变更的控制和管理。
• 配置项的三种状态：工作态，评审态，受控态。
• 需求变更管理过程包括：

1. 问题分析和变更描述

1. 需要识别和分析需求问题，形成明确的变更协议，以检查它的有效性，从而产生一个更明确的需求变更提议。

2. 变更分析和成本计算

1. 使用可追朔性信息和系统需求的一般知识，对需求变更提议进行影响分析和评估。
2. 变更成本计算应该包括对需求文档的修改，系统修改的设计和实现的成本。一旦分析完成并且被确认，应该进行是否执行这一变更的决策。

3. 变更实现

1. 这要求需求文档和系统设计以及实现都要同时修改。

3）需求跟踪管理

1. 需求跟踪矩阵保存了初始需求和后续工作成果之间的对应关系。
2. 原始用户需求—软件需求—工作产品（功能点，设计元素，代码模块和测试用例）

1. 需求跟踪

1. 定义对其他需求的链接；
2. 定义对其他系统元素的链接；
3. 使用的工具即需求跟踪矩阵；

2. 需求状态跟踪

1. 定义需求状态；
2. 跟踪需求的每一个状态。

4）需求风险管理

1. 无足够用户参与
2. 忽略了用户分类
3. 用户需求的不断增加
4. 模凌两可的需求
5. 不必要的特征
6. 过于精简的SRS
7. 不准确的估算

5）需求变更管理流程

1. 变更申请
2. CCB处理
3. 提出解决方案
4. 项目影响分析
5. CCB评审方案
6. 确认基线
7. 将受控库的基线导入开发库，准备修改代码
8. 修改代码
9. 验证测试
10. 判断程序是否正确
11. 在受控库中建立新的基线，并入产品库
12. 完成变更升级
13. 关闭变更申请

八. 需求分析补充说明

1. 需求是回答做什么，设计是回答如何做。
2. 需求分析就是对处理的对象进行系统调查，主要包括了：系统范围与目标分析，系统组织结构和功能分析，系统性能分析。
3. 其中在系统组织结构和功能分析当中，需要了解组织的目标及其战略规划，组织结构以及各部分的功能，各部门职能的相互关系，分析组织机构的合理性。可以应用以下这几个工具：
      1. 组织结构图：描述组织各部分的领导和被领导关系。
      2. 组织/业务关系图：描述业务和部门的关系。
      3. 业务功能一览表：描述每一种业务所具有的功能
4. 需求分析阶段的主要任务：对现实世界要处理的对象进行详细调查，了解现行系统概况，确定新系统功能的过程中，确定系统边界，收集支持系统目标的基础数据和处理方法。