软考高级之系统架构师之软件需求工程
概述
一个完整的软件生存周期是以需求为出发点。软件需求是指用户对系统在功能、行为、性能、设计约束等方面的期望。
需求开发：
- 需求获取
- 需求分析
- 需求定义（需求规格说明书）
- 需求验证
需求管理:
- 变更控制
- 版本控制
- 需求跟踪
- 需求状态跟踪
需求开发和需求管理是相辅相成的，需求开发是主线、目标，需求管理是支持、保障。
分类
需求分类：从不同的角度有不同的分类方式，每一种分类方式都提供一个对需求进行理解的视角。
软件需求包括三个不同的层次（分类）：业务需求、用户需求和功能及非功能需求。
-
业务需求：表示组织或客户高层次的目标，通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求描述组织为什么要开发一个系统，即组织希望达到的目标。使用前景和范围文档来记录业务需求，这份文档有时也被称作项目轮廓图或市场需求文档
-
用户需求：描述用户的目标，或用户要求系统必须能完成的任务
-
功能需求：规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。
-
业务需求（整体全局）
-
用户需求（用户视角）
-
系统需求（计算机化）
另一种分类方式：
- 基本需求（明示，常规需求）
- 期望需求（隐含）
- 兴奋需求（意外需求）
另有一说：软件需求包括功能需求、非功能需求、设计约束三个主要部分。
需求特性
软件需求的基本特征：可验证性。
理想情况下，每一项用户、业务需求和功能需求都应具备下列性质：
- 完整性：每一项需求都必须完整地描述即将交付使用的功能
- 正确性：每一项需求都必须正确地描述将要开发的功能
- 可行性：需求必须能够在系统及其运行环境的已知能力和约束条件内实现
- 必要性：每一项需求记录的功能都必须是用户的真正需要
- 无歧义：每一项需求声明对所有读者应该只有一种一致的解释
- 可验证性：如果某项需求不可验证，那判定其实现的正确与否就变成主观臆断。
需求开发
需求开发的过程有四个主要活动：
- 需求获取：积极地与用户进行交流，捕捉、分析和修正用户对目标系统的需求，并提炼出符合解决问题的用户需求，产生《用户需求说明书》
- 需求分析：目的是对各种需求信息进行分析并抽象描述，为目标系统建立一个概念模型
- 需求定义：目标是根据需求调查和需求分析的结果，进一步定义准确无误的产品需求，产生《需求规格说明书》。系统设计人员将依据《需求规格说明书》开展系统设计工作
- 需求验证：指开发方和用户共同对需求文档评审，经双方对需求达成共识后做出书面承诺，使需求文档具有商业合同效果。
需求获取
需求获取有很多方法：
用户访谈：用户访谈是最基本的一种需求获取手段，其形式包括结构化和非结构化两种。用户访谈是通过1对1（或1对2，1对3）的形式与用户面对面进行沟通，以获取用户需求。用户访谈具有良好的灵活性，有较宽广的应用范围。但是，也存在着许多困难，例如，用户经常较忙，难以安排时间；面谈时信息量大，记录较为困难；沟通需要很多技巧，同时需要系统分析师具有足够的领域知识等。另外，在访谈时，还可能会遇到一些对于企业来说比较机密和敏感的话题。因此，这看似简单的技术，也需要系统分析师具有丰富的经验和较强的沟通能力。
采样：是指从种群中系统地选出有代表性的样本集的过程，通过认真研究所选出的样本集，可以从整体上揭示种群的有用信息。对于信息系统的开发而言，现有系统的文档（文件）就是采样种群。当开始对一个系统做需求分析时，查看现有系统的文档是对系统有初步了解的最好方法。但是，系统分析师应该查看哪些类型的文档，当文档的数据庞大，法——研究时，就需要使用采样技术选出有代表性的数据。采样技术不仅可以用于收集数据，还可以用于采集访谈用户或者是采集观察用户。在对人员进行采样时，上面介绍的采样技术同样适用。通过采样技术，选择部分而不是选择种群的全部，不仅加快数据收集的过程，而且提高效率降低开发成本。采样技术使用数理统计原理，能减少数据收集的偏差。但是，由于采样技术基于统计学原理，样本规模的确定依赖于期望的可信度和已有的先验知识，很大程度上取决于系统分析师的主观因素，对系统分析师个人的经验和能力依赖性很强，要求系统分析师具有较高的水平和丰富的经验。
联合需求计划：为了提高需求获取的效率，越来越多的企业倾向于使用小组工作会议来代替大量独立的访谈。联合需求计划（Joint Requirement Planning，JRP）是一个通过高度组织的群体会议来分析企业内的问题并获取需求的过程，它是联合应用开发（Joint Application Development，JAD）的一部分。
需求分析
需求分析是一种软件工程活动，它在系统级软件分配和软件设计间起到桥梁的作用，需求分析使得系统工程师能够刻画出软件的功能和性能，指明软件和其他系统元素的接口，并建立软件必须满足的约束。
需求分析允许系统分析师细化软件的分解，并建立将被软件处理的数据、功能和行为模型。最后，需求规约为开发者和客户提供了软件开发完成后质量评估的依据。需求分析为软件设计师提供可被翻译成数据、架构、界面和过程设计的模型。
需求分析的任务是发现、求精、建模和规约的过程，包括详细地细化由系统工程师建立并在软件项目计划中明确的软件范围，创建所需数据、信息和控制流及操作行为的模型，此外，还要分析可选择的解决方案，并将它们分配到各软件元素中去。
在需求分析阶段要得到详细的规约是不可能的。客户可能并不能精确地肯定需要什么，开发者可能不能肯定可用什么特定的方法来适当地完成功能和性能。
需求抽取和分析的过程
- 发现需求
- 需求分类和组织
- 需求优先级划分和协商
- 需求规格说明
DFD
数据流图，是SA方法中的重要工具，是表达系统内部数据的流动并通过数据流描述系统功能的一种方法。
DFD还可被认为是一个系统模型，在信息系统开发中，如果采用结构化方法，则一般将DFD作为需求规格说明书的一个组成部分。用例模型描述一组用例、参与者及它们之间的关系。
通常使用数据字典作为该工具的补充说明：
- DFD是理解和表达用户需求的工具，是需求分析的手段。由于DFD简明易懂，不需要任何计算机专业知识就可以理解它，因此，系统分析师可以通过DFD与用户进行交流
- DFD概括地描述了系统的内部逻辑过程，是需求分析结果的表达工具，也是系统设计的重要参考资料，是系统设计的起点
- DFD作为一个存档的文字材料，是进一步修改和充实开发计划的依据。
面向数据流的分析方法：结构化分析方法。
OOA
面向对象分析，主要活动
- 建立需求模型，即用例图
- 确定系统边界
- 发现参与者
- 定义用例
- 建立基本模型，即类图
- 发现对象、定义它们的类
- 定义对象的内部特征——属性和操作
- 定义对象的外部关系——一般-特殊结构、整体-部分结构、关联和消息
- 建立辅助模型
- 划分包，建立包图
- 建立顺序图
- 建立活动图
- 建立构件图
- 建立部署图
- 建立其他模型图
- 建立模型规约：对模型中的成分进行规范的定义和文字说明
- 原型开发：可选，结合其他活动反复进行
以上各个OOA过程总体来说是一个反复进行，不断完善的过程，以建立基本模型为中心，进行需求模型、基本模型、辅助模型的建立、修复与完善。
需求定义
需求定义的过程也就是形成需求规格说明书的过程，通常有两种需求定义的方法：严格定义方法和原型方法。
严格定义方法，也称为预先定义，需求的严格定义建立在以下基本假设之上：
- 所有需求都能够被预先定义。这意味着在没有实际系统运行经验的情况下，全部的系统需求均可通过逻辑推断得到。但这种假设在许多场合是不能成立的。
- 开发人员与用户之间能够准确而清晰地交流。
- 采用图形（或文字）可以充分体现最终系统。在使用严格定义需求的开发过程中，开发人员与用户之间交流与沟通的主要工具是定义报告，包括文字、图形、逻辑规则和数据字典等技术工具。
原型化的需求定义过程是一个开发人员与用户通力合作的反复过程。从一个能满足用户基本需求的原型系统开始，允许在开发过程中提出更好的要求，根据用户的要求不断地对系统进行完善，它实质上是一种迭代的循环型的开发方式。
使用原型方法时需注意几个问题：
- 并非所有的需求都能在系统开发前被准确地说明
- 项目干系人之间通常都存在交流上的困难
- 需要实际的、可供用户参与的系统模型
- 有合适的系统开发环境
- 反复是完全需要和值得提倡的。需求一旦确定，就应该遵从严格定义的方法
需求验证
需求验证的四种基本方法是检查，演示，测试和分析。这四种方法本质上是分层的，因为每种方法都会越来越严格地验证产品或系统的要求：
- 检查：在检查需求时，会校对需求文档，以确保不会遗漏任何引出说明，还检查所有要求之间的可追溯性级别。为此，需要创建可追溯性矩阵，该矩阵确保所有要求都得到适当考虑，并且指定的所有内容都是合理的。还会检查需求的格式，看看需求是否清晰。
- 原型设计：这是一种为开发人员构建的系统构建模型或模拟的方法。这是利益相关者和用户之间非常流行的需求验证技术，因为它可以帮助他们轻松识别问题、检测缺失的需求并了解技术如何帮助他们。可以联系用户和利益相关者并获得他们的反馈。
- 测试设计：在测试设计期间，遵循测试团队构建一些测试场景的小程序。测试必须从需求规范中派生此过程的目的是找出规范中的错误或遗漏的细节，从而导致难以定义测试场景。
- 需求审查：在需求评审期间，一组知识渊博的人以结构化和详细的方式分析需求并识别潜在问题。随后聚在一起讨论问题并找出解决问题的方法。准备一份清单，供审阅者填写以提供审阅的正式输出。最后完成最终批准签字。
需求验证原则
根据 IREB 教学大纲，考虑以下四个需求验证原则可以提高验证结果的质量：
- 正确的利益相关者的参与
- 分离识别和纠正错误
- 从不同的角度进行验证
- 反复验证
需求管理
需求管理是一个对系统需求变更、了解和控制的过程，通常包括定义需求基线、处理需要变更和需求跟踪方面的工作。需求管理过程与需求开发过程相互关联，当初始需求导出的同时就启动需求管理计划，一旦形成需求文档初稿，需求管理活动就开始。
需求管理强调：控制对需求基线的变动；保持项目计划与需求的一致；控制单个需求和需求文档的版本情况；管理需求和联系链，或者管理单个需求和其他项目可交付产品之间的依赖关系；跟踪基线中的需求状态。
关于需求管理过程域内的原则和策，可以参考：
- 需求管理的关键过程领域不涉及收集和分析项目需求，而是假定己收集了软件需求，或者已由更高一级的系统给定了需求
- 开发人员在向客户以及有关部门承诺某些需求之前，应该确认需求和约束条件、风险、偶然因素、假定条件等
- 关键处理领域同样建议通过版本控制和变更控制来管理需求文档。
需求管理的活动包括：
- 变更控制
- 版本控制
- 需求跟踪
- 需求状态跟踪
需求变更控制
一个大型的软件系统的需求总是有变化的。对许多项目来说，系统软件总需要不断完善，一些需求的改进是合理的而且不可避免，要使得软件需求完全不变更，也许是不可能的，但毫无控制的变更是项目陷入混乱、不能按进度完成，或者软件质量无法保证的主要原因之一。一个好的变更控制过程，给项目风险承担者提供正式的建议需求变更机制，可以通过变更控制过程来跟踪已建议变更的状态，使已建议的变更确保不会丢失或疏忽。需求变更管理过程：
- 问题分析和变更描述。这是识别和分析需求问题或者一份明确的变更提议，以检查它的有效性，从而产生一个更明确的需求变更提议
- 变更分析和成本计算。使用可追溯性信息和系统需求的一般知识，对需求变更提议进行影响分析和评估。变更成本计算应该包括对需求文档的修改、系统修改的设计和实现的成本。一旦分析完成并且确认，应该进行是否执行这一变更的决策
- 变更实现。这要求需求文档和系统设计以及实现都要同时修改。如果先对系统的程序做变更，然后再修改需求文档，这几乎不可避免地会出现需求文档和程序的不一致。自动化工具能够帮助变更控制过程更有效地运作。许多团队使用商业问题跟踪工具来收集、存储和管理需求变更。用这样的工具创建的最近提交的变更建议清单，可以用作CCB会议的议程。问题跟踪工具也可以随时按变更状态分类报告出变更请求的数目。因为可用的工具、厂商和特性总在频繁地变化，所以这里无法给出有关工具的具体建议。
但工具应该具有以下几个特性，以支持需求变更过程：
- 可以定义变更请求中的数据项；
- 可以定义变更请求生命周期的状态转换模型；
- 可以强制实施状态转换模型，以便只有授权用户可以做出允许的状态变更；
- 可以记录每一个状态变更的日期和做出这一变更的人；
- 可以定义当提议者提交新请求或请求状态被更新时，哪些人可以自动接收电子邮件通知；
- 可以生成标准的和定制的报告和图表。
有些商业需求管理工具内置有简单的变更建议系统。这些系统可以将提议的变更与某一特定的需求联系起来，这样无论什么时候，只要有人提交一个相关的变更请求，负责需求的每个人都会收到电子邮件通知。
一个大型软件系统的需求通常是会发生变化的。在进行需求变更时，可以参考以下的需求变更策：
- 所有需求变更必须遵循变更控制过程；
- 对于未获得批准的变更，不应该做设计和实现工作；
- 变更应该由项目变更控制委员会决定实现哪些变更；
- 项目风险承担者应该能够了解变更数据库的内容；
- 决不能从数据库中删除或者修改变更请求的原始文档；
- 每一个集成的需求变更必须能跟踪到一个经核准的变更请求
版本控制
需求跟踪
需求跟踪包括编制每个需求与系统元素之间的联系文档，这些元素包括别的需求、体系结构、其他设计部件、源代码模块、测试、帮助文件和文档等。跟踪能力信息使变更影响分析十分便利，有利于确认和评估实现某个建议的需求变更所必须的工作。利用需求跟踪能力链（traceability link）可以跟踪一个需求使用的全过程，也就是从初始需求到实现的前后生存期。跟踪能力是优秀需求规格说明书的一个特征，为了实现跟踪能力，必须统一地标识出每一个需求，以便能明确地进行查阅。
客户需求向前追溯到软件需求。这样就能区分出开发过程中或者开发结束后，由于客户需求变更受到影响的软件需求，这也就可以确保软件需求规格说明包括所有客户需求。
从软件需求回溯响应的客户需求。这也就是确认每个软件需求的源头。如果使用实例的形式来描述客户需求，那么客户需求与软件需求之间的跟踪情况就是使用实例和功能性需求。从软件需求向前追溯到下一级工作产品。由于开发过程中系统需求转变为软件需求、设计、编码等，所以通过定义单个需求和特定的产品元素之间的（联系）链，可以从需求向前追溯到下一级工作产品。这种联系链告诉我们每个需求对应的产品部件，从而确保产品部件满足每个需求。从产品部件回溯到软件需求。说明每个部件存在的原因。如果不能把设计元素、代码段或测试回溯到一个需求，可能存在画蛇添足的程序。然而，如果这些孤立的元素表明一个正当的功能，则说明需求规格说明书漏掉一项需求。
需求跟踪矩阵RTM