系统分析师备考第十三章-系统分析及需求工程

欢迎你来读这篇博客，这篇博客主要是关于系分考点·系统分析及需求工程的分享。
其中包括了关于我的经验和收集的知识分享。

正文

软件需求

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

分为需求开发和需求管理两大过程

• 需求开发
  • 需求获取
  • 需求分析
  • 需求定义(需求规格说明书)
  • 需求验证
• 输出需求基线
• 需求管理（支持需求开发）
  • 变更控制
  • 版本控制
  • 需求跟踪
  • 需求状态跟踪

业务需求:反映企业或客户对系统高层次的目标要求，通常来自项目投资人客户、市场营销部门或产品策划部门。通过业务需求可以确定项目视图和范围。

用户需求:描述的是用户的具体目标，或用户要求系统必须能完成的任务即描述了用户能使用系统来做什么。通常采取用户访谈和问卷调查等方式，对用户使用的场景进行整理，从而建立用户需求。

系统需求:从系统的角度来说明软件的需求，包括功能需求、非功能需求和设计约束等。

• 1)功能需求:也称为行为需求，规定了开发人员必须在系统中实现的软件功能用户利用这些功能来完成任务，满足业务需要。
• 2)非功能需求:指系统必须具备的属性或品质，又可以细分为软件质量属性(如可维护性、可靠性、效率等)和其他非功能需求。
• 3)设计约束:也称为限制条件或补充规约，通常是对系统的一些约束说明，例如必须采用国有自主知识产权的数据库系统，必须运行在UNIX操作系统之下等。

质量功能部署

质量功能部署(QFD)是一种将用户要求转化成软件需求的技术，其目的是最大限度地提升软件工程过程中用户的满意度。为了达到这个目标，QFD将软件需求分为三类，分别是常规需求、期望需求和意外需求。

• (1)常规需求。用户认为系统应该做到的功能或性能，实现越多用户会越满意。
• (2)期望需求。用户想当然认为系统应具备的功能或性能，但并不能正确描述自己想要得到的这些功能或性能需求。如果期望需求没有得到实现，会让用户感到不满意。
• (3)意外需求。意外需求也称为兴奋需求，是用户要求范围外的功能或性能(但通常是软件开发人员很乐意赋予系统的技术特性)
  ，实现这些需求用户会更高兴，但不实现也不影响其购买的决策。

需求获取

需求获取:是一个确定和理解不同的项目干系人的需求和约束的过程

常见的需求获取法包括:

• (1)用户访谈:1对1-3，有代表性的用户。其形式包括结构化和非结构化两种。
• (2)问卷调查:用户多，无法一一访谈。
• (3)采样:从种群中系统地选出有代表性的样本集的过程。样本数量=0.25*(可信度因子/错误率)**2
• (4)情节串联板:一系列图片，通过这些图片来讲故事。
• (5)联合需求计划(JRP):通过联合各个关键用户代表、系统分析师、开发团队代表一起，通过有组织的会议来讨论需求。
• (6)需求记录技术:任务卡片、场景说明、用户故事、Volere白卡。

需求分析

需求分析:一个好的需求应该具有无二义性、完整性、一致性、可测试性确定性、可跟踪性、正确性、必要性等特性，因此，需要分析人员把杂乱无章的用户要求和期望转化为用户需求，这就是需求分析的工作。

需求分析的任务：

• (1)绘制系统上下文范围关系图
• (2)创建用户界面原型
• (3)分析需求的可行性
• (4)确定需求的优先级
• (5)为需求建立模型
• (6)创建数据字典
• (7)使用QFD(质量功能部署)

结构化的需求分析结构化特点:自顶向下，逐步分解，面向数据.

三大模型:功能模型(数据流图)、行为模型(状态转换图)、数据模型(E-R图)以及数据字典。

数据流图描述数据在系统中如何被传送或变换，以及如何对数据流进行变换的功能或子功能，用于对功能建模，数据流图相关概念如图:

数据流图是可以分层的，从顶层(即上下文无关数据流)到0层、1层等，顶层数据流图只含有一个加工处理表示整个管理信息系统，描述了系统的输入和输出，以及和外部实体的数据交互。

• (1)对象:由数据及其操作所构成的封装体，是系统中用来描述客观事务的个实体，是构成系统的一个基本单位。一个对象通常可以由对象名、属性和方法3个部分组成。

• (2)类:现实世界中实体的形式化描述，类将该实体的属性(数据)和操作(函数)
  封装在一起。对象是类的实例，类是对象的模板。

  • 类可以分为三种:实体类、接口类(边界类)
    和控制类。
    • 实体类的对象表示现实世界中真实的实体，如人、物等
    • 接口类(边界类)
      的对象为用户提供一种与系统合作交互的方式，分为人和系统两大类，其中人的接口可以是显示屏窗口、Web
      窗体、对话框、菜单、列表框、其他显示控制、条形码、二维码或者用户与系统交互的其他方法。系统接口涉及到把数据发送到其他系统，或者从其他系统接收数据。
    • 控制类的对象用来控制活动流，充当协调者

• (3)抽象:通过特定的实例抽取共同特征以后形成概念的过程。它强调主要特征，忽略次要特征。一个对象是现实世界中一个实体的抽象，一个类是一组对象的抽象，抽象是一种单一化的描述，它强调给出与应用相关的特性，抛弃不相关的特性。

• (4)封装:是一种信息隐蔽技术，将相关的概念组成一个单元模块，并通过-个名称来引用。面向对象封装是将数据和基于数据的操作封装成一个整体对象对数据的访问或修改只能通过对象对外提供的接口进行。
  这种关系使得某类对象可

• (5)继承:表示类之间的层次关系(父类与子类)以继承另外一类对象的特征，又可分为单继承和多继承。

• (6)多态:不同的对象收到同一个消息时产生完全不同的结果。包括参数多态包含多态(父子类型关系)、过载多态(类(
  不同类型参数多种结构类型)强制多态:(强制类型转换)四种类型。多态似于重载，一个名字不同含义)
  、由继承机制支持，将通用消息放在抽象层，具体不同的功能实现放在低层。

• (7)接口:描述对操作规范的说明，其只说明操作应该做什么，并没有定义操作如何做。

• (8)消息:体现对象间的交互，通过它向目标对象发送操作请求:

• (9)覆盖:子类在原有父类接口的基础上，用适合于自己要求的实现去置换父类中的相应实现。即在子类中重定义一个与父类同名同参的方法。

• (10)函数重载:与覆盖要区分开，函数重载与子类父类无关，且函数是同名不同参数。

• (11)绑定是一个把过程调用和响应调用所需要执行的代码加以结合的过程在一般的程序设计语言中，绑定是在编译时进行的，叫作静态绑定。动态绑定则是在运行时进行的，因此，一个给定的过程调用和代码的结合直到调用发生时才进行。

面向对象的分析:是为了确定问题域，理解问题。包含五个活动:认定对象组织对象、描述对象间的相互作用、确定对象的操作、定义对象的内部信息。

统一建模语言UML

UML(统一建模语言):是一种可视化的建模语言，而非程序设计语言，支持从需求分析开始的软件开发的全过程。

从总体上来看，UML的结构包括构造块、规则和公共机制三个部分。

• (1)构造块。UML有三种基本的构造块，分别是事物(thing)、关系(relationship)和图(diagram)
  。事物是UML的重要组成部分，关系把事物紧密联系在一起，图是多个相互关联的事物的集合。
• (2)公共机制。公共机制是指达到特定目标的公共UML方法。
• (3)规则。规则是构造块如何放在一起的规定。

事物：

• 结构事物:模型的静态部分，如类、接口、用例、构件等;
• 行为事物:模型的动态部分，如交互、活动、状态机;
• 分组事物:模型的组织部分，如包;
• 注释事物:模型的解释部分，依附于一个元素或·组元素之上对其进行约束或解释的简单符号。

关系：

• 依赖:一个事物的语义依赖于另·一个事物的语义的变化而变化
• 关联:是一种结构关系，描述了一组链，链是对象之间的连接。分为组合和聚合，都是部分和整体的关系，其中组合事物之间关系更强。两个类之间的关联，实际上是两个类所扮演角色的关联，因此，两个类之间可以有多个由不同角色标识的关联。
• 泛化:一般/特殊的关系，子类和父类之间的关系
• 实现:一个类元指定了另一个类元保证执行的契约

UML图分类。了解

静态图：类图、对象图、用例图、部署图。
动态图：序列图、通信图、状态图、活动图。
组件图：构件图。

UML4+1视图

• (1)逻辑视图。逻辑视图也称为设计视图，它表示了设计模型中在架构方面具有重要意义的部分，即类、子系统、包和用例实现的子集
• (2)进程视图。进程视图是可执行线程和进程作为活动类的建模，它是逻辑视图的一次执行实例，描述了并发与同步结构。
• (3)实现视图。实现视图对组成基于系统的物理代码的文件和构件进行建模。
• (4)部署视图。部署视图把构件部署到一组物理节点上表示软件到硬件的映射和分布结构。
• (5)用例视图。用例视图是最基本的需求分析模型

需求定义

需求定义(软件需求规格说明书SRS):
是需求开发活动的产物，编制该文档的目的是使项目干系人与开发团队对系统的初始规定有一个共同的理解，使之成为整个开发工作的基础。SRS是软件开发过程中最重要的文档之一，对于任何规模和性质的软件项目都不应该缺少

需求定义方法

• (1)严格定义也称为预先定义，需求的严格定义建立在以下的基本假设之上:
  所有需求都能够被预先定义。开发人员与用户之间能够准确而清晰地交流。采用图形(或文字)可以充分体现最终系统。
• (2)原型方法，迭代的循环型开发方式，需要注意的问题:
  并非所有的需求都能在系统开发前被准确地说明。项目干系人之间通常都存在交流上的困难，原型提供了克该服困难的一个手段。特点:
  需要实际的、可供用户参与的系统型。有合适的系统开发环境。反复是完全需要和值得提倡的，需求一旦确定，就应遵从严格的方法。

需求验证

需求验证:也称为需求确认，目的是与用户一起确认需求无误，对需求规格说明书SAS进行评审和测试，包括两个步骤:

• 需求评审:正式评审和非正式评审。
• 需求测试:设计概念测试用例。

需求验证通过后，要请用户签字确认，作为验收标准之一，此时，这个需求规格说明书就是需求基线，不可以再随意更新，如果需要更改必须走需求变更流程。

需求管理

定义需求基线:通过了评审的需求说明书就是需求基线，下次如果需要变更需求，就需要按照流程来一步步进行。

需求变更和风险

主要关心需求变更过程中的需求风险管理，带有风险的做法有:
无足够用户参与、忽略了用户分类、用户需求的不断增加、模棱两可的需求、不必要的特性、过于精简的SRS、不准确的估算

变更产生的原因:外部环境的变化、需求和设计做的不够完整、新技术的出现、公司机构重组造成业务流程的变化。

变更控制委员会CCB:也称为配置控制委员会，其任务时对建议的配置项变更做出评价、审批，以及监督已经批准变更的实施。

双向跟踪，两个层次：

• 正向跟踪表示用户原始需求是否都实现了，反向跟踪表示软件实现的是否都是用户要求的，不多不少，可以用原始需求和用例表格(需求跟踪矩阵)来表示
• 若原始需求和用例有对应，则在对应栏打对号，若某行都没有对号，表明原始需求未实现，正向跟踪发现问题:若某列都没有对号，表明有多余功能用例软件实现了多余功能，反向跟踪发现问题。

参考资料

• 官方教材-系统分析师综合教程

启示录

富贵岂由人，时会高志须酬。

能成功于千载者，必以近察远。