架构-软件工程3-需求工程
概述
软件需求：是指用户对系统在功能、行为、性能、设计约束等方面的期望。
是指用户解决问题或达到目标所需的条件或能力，是系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或能力，以及反映这些条件或能力的文档说明。
分为需求开发和需求管理两大过程，如下所示： 
软件需求细分：
- 业务需求（整体全局）：反映企业或客户对系统高层次的目标要求，通常来自项目投资人客户、市场营销部门或产品策划部门。通过业务需求可以确定项目视图和范围。
- 用户需求（用户视角）：描述的是用户的具体目标，或用户要求系统必须能完成的任务。即描述了用户能使用系统来做什么。通常采取用户访谈和问卷调查等方式，对用户使用的场景进行整理，从而建立用户需求。
- 功能需求（计算机化）：从系统的角度来说明软件的需求，包括功能需求、非功能需求和设计约束等。
- 功能需求：也称为行为需求，规定了开发人员必须在系统中实现的软件功能，用户利用这些功能来完成任务，满足业务需要。
- 非功能需求：指系统必须具备的属性或品质，又可以细分为软件质量属性（如可维护性、可靠性、效率等）和其他非功能需求。
- 设计约束：也称为限制条件或补充规约，通常是对系统的一些约束说明，例如必须采用国有自主知识产权的数据库系统，必须运行在UNIX操作系统之下等。
需求工程整体图：
需求开发
需求获取
是一个确定和理解不同的项目干系人的需求和约束的过程。
需求获取参考步骤
- 开发高层的业务模型：建立一个业务模型，描述用户的业务过程，确定用户的初始需求。
- 定义项目范围和高层需求：项目范围描述系统的边界以及系统与系统交互的参与者之间的关系。高层需求不涉及过多的细节，主要表示系统需求的概貌。
常见的建模手段包括：系统上下文图和系统顶层用例图等。 - 识别用户角色和用户代表。用户角色可以是人，也可以是与系统打交道的其他应用程序或硬件部件。如果是其他应用程序或硬件部件，则需要以熟悉这些系统或硬件的人员作为用户代表。
- 获取具体的需求。获取每个涉众的具体、完整和详细的需求。
- 确定目标系统的业务工作流。具体到当前待开发的应用系统，确定系统的业务工作流和主要的业务规则。
- 需求整理与总结。最后对上面步骤取得的需求资料进行整理和总结，确定对软件系统的综合要求即软件的需求。
常见的需求获取法【重要】
- 用户面谈（访谈）：1对1-3，有代表性的用户。其形式包括结构化和非结构化两种。面谈过程需要认真的计划和准备；面谈之后，需要复查笔记的准确性、完整性和可理解性；把所收集的信息转化为适当的模型和文档；确定需要进步澄清的问题。【成本高、要有领域知识支撑】
- 需求专题讨论会：将相关涉众集中在一起集体讨论，与会者可以在应用需求上达成共识，对操作过程尽快取得统一的意见。参加会议的人员包括主持人、用户、技术人员、项目组人员。【交互好、成本高】
- 问卷调查：用户多，无法一一访谈。可用于确认假设和收集统计倾向数据。
- 现场观察：主要是通过观察用户实际执行业务的过程，来直观地了解业务的执行过程，全面了解需求细节。执行业务可能是手工操作，也可能是在原有的业务系统上执行。
- 原型化方法：在需求的早期，用户往往在具体的需求定义上存在很多不确定性。此时往往可以通过在需求阶段采用原型化方法，通过开发系统原型以及与用户的多次选代反馈，解决在早期阶段需求不确定的问题，尤其是在人机界面等高度不确定的需求。
- 头脑风暴法:在一些新业务拓展的软件项目中，由于业务是新出现的，而且业务流程存在高度的不确定性，例如互联网上的新业务系统、App等，一群人围绕该业务，发散思维，不断产生新的观点，参会者敞开思想使各种设想在相互碰撞中激起大脑的创造性风暴，从而确定具体的需求。
需求分析
一个好的需求应该具有无二义性、完整性、一致性、可测试性、确定性、可跟踪性、正确性、必要性等特性，因此，需要分析人员把杂乱无章的用户要求和期望转化为用户需求，这就是需求分析的工作。
结构化分析
【结构化方法】
结构化方法的开发过程一般是先把系统功能视为一个大的模块，再根据系统分析与设计的要求对其进行进一步的模块分解或组合。
结构化分析方法给出一组帮助系统分析人员产生功能规约的原理与技术。它一般利用图形表达用户需求，使用的手段主要有数据流图、数据字典、结构化语言、判定表以及判定树等。
结构化分析的步骤
- 分析业务情况，做出反映当前物理模型的数据流图(DFD)；
- 推导出等价的逻辑模型的DFD（数据流图）；
- 设计新的逻辑系统，生成数据字典和基元描述；
- 建立人机接口，提出可供选择的目标系统物理模型的DFD（数据流图）
- 确定各种方案的成本和风险等级，据此对各种方案进行分析；
- 选择一种方案；
- 建立完整的需求规约
结构化特点
- 自顶向下
- 逐步分解
- 面向数据
行为模型三大模型以及数据字典
功能模型(分层数据流图DFD表示)
基本图形元素：外部实体、加工、数据存储、数据流
- 数据流：由一组固定成分的数据组成，表示数据的流向。在DFD 中，数据流的流向必须经过加工*。
- 加工：描述了输入数据流到输出数据流之间的变换，数据流图中**常见的三种错误如图所示：
- 加工3.1.2 有输入但是没有输出，称之为“黑洞
- 加工3.1.3 有输出但没有输入。称之为“奇迹”
- 加工3.1.1 中输入不足以产生输出，我们称之为“灰洞”
- 数据存储：用来存储数据。
- 外部实体（外部主体）：是指存在于软件系统之外的人员或组织，它指出系统所需数据的发源地(源)和系统所产生的数据的归宿地(宿)
行为模型(状态转换图STD)
数据模型(E-R图)
数据字典
数据字典DD：是一种用户可以访问的记录数据库和应用程序元数据的目录。
数据字典是指对数据的数据项、数据结构、数据流、数据存储、处理逻辑等进行定义和描述，其目的是对数据流程图中的各个元素做出详细的说明。简而言之，数据字典是描述数据的信息集合，是对系统中使用的所有数据元素定义的集合。
数据字典各部分的描述如下：
- 数据项：数据流图中数据块的数据结构中的数据项说明。数据项是不可再分的数据单位
- 数据结构：数据流图中数据块的数据结构说明。数据结构反映了数据之间的组合关系。
- 数据流：数据流图中流线的说明。
- 数据存储：数据流图中数据块的存储特性说明。
- 处理过程：数据流图中功能块的说明。
面向对象的需求分析
【OMT方法，Object Modeling Technique，面向对象建模方法】
OMT方法使用了建模的思想，讨论如何建立一个实际的应用模型，包括对象模型、动态模型和功能模型。对象模型描述系统中对象的静态结构、对象之间的关系、属性和操作，主要用对象图来实现；动态模型描述与时间和操作顺序有关的系统特征，例如，激发事件、事件序列、确定事件先后关系的状态等，主要用状态图来实现动态模型；功能模型描述一个计算如何从输入值得到输出值，它不考虑计算的次序，主要用DFD来实现功能模型。
UML：统一建模语言
【规则、公共机制考的很少】
重点是【关系+图】
需求定义
需求规格说明书（SRS），不是需求基线
严格定义法
- 所有需求都能够被预先定义
- 开发人员与用户之间能够准确而清晰地交流
- 采用图形/文字可以充分体现最终系统
原型法
- 并非所有的需求都能在开发前被准确的说明
- 项目参加者之间通常都存在交流上的困难
- 需要实际的、可供用户参与的系统模型
- 有合适的系统开发环境
- 反复是完全需要和值得提倡的，需求一旦确定，就应遵从严格的方法
需求确认与验证
需求基线=经过评审的需求规格说明书
需求管理
需求变更
【一个项目，形成了需求的基线之后，就不能随便调整了】
为了使开发组织能够严格控制软件项目，应该确保以下事项：
- 仔细评估已建议的变更。
- 挑选合适的人选对变更做出判定
- 变更应及时通知所有相关人员
- 项目要按一定的程序来采纳需求变更，对变更的过程和状态进行控制。
变更控制过程
- 问题分析和变更描述。当提出一份变更提议后，需要对该提议做进一步的问题分析，检查它的有效性从而产生一个更明确的需求变更提议。
- 变更分析和成本计算。当接受该变更提议后，需要对需求变更提议进行影响分析和评估。变更成本计算应该包括对该变更所引起的所有改动的成本，例如修改需求文档、相应的设计、实现等工作成旦分析完成并且被确认，应该进行是否执行这一变更的决策。
- 变更实现。当确定执行该变更后，需要根据该变更的影响范围，按照开发的过程模型执行相应的变更。
变更控制委员会(CCB)是项目所有者权益代表，负责裁定接受哪些变更。
CCB由项目所涉及的多方成员共同组成，通常包括用户和实施方的决策人员。CCB 是决策机构，不是作业机构，通常CCB的工作是通过评审手段来决定项目是否能变更，但不提出变更方案。
变更控制委员会应该有一个总则，用于描述变更控制委员会的目的、授权范围、成员构成、做出决策的过程及操作步骤。过程及操作步骤为：制定决策、交流情况、重新协商约定
变更控制流程的十大步骤
需求追踪
需求跟踪提供了由需求到产品实现整个过程范围的明确查阅的能力。需求跟踪的目的是建立与维护“需求一设计一编程一测试”之间的一致性，确保所有的工作成果符合用户需求。
需求开发工作不易，获取全面的正确的需求也是不易
需求跟踪有两种方式:
- 正向跟踪：检查《产品需求规格说明书》中的每个需求是否都能在后继工作成果中找到对应点。
- 逆向跟踪：检查设计文档、代码、测试用例等工作成果是否都能在《产品需求规格说明书》中找到出处。
正向跟踪和逆向跟踪合称为“双向跟踪”。不论采用何种跟踪方式，都要建立与维护需求跟踪矩阵(即表格)。需求跟踪矩阵保存了需求与后继工作成果的对应关系。