《需求工程--软件建模与分析》笔记

第一部分：绪论

• 软件的发展经历了以“机器”“应用”“企业”为中心的三个阶段。这也是软件从一开始的新型项目到逐渐完整的一个制作体系形成的过程。其中关于需求规格说明和需求管理的缺陷是软件开发中最常见的两类重要问题。而导致需求问题的原因中，未能很好的理解和掌握。应用型软件的模拟特性以及由此而产生的一系列影响的要求。软件可以分为三种类别：面向专业用户的纯工具型软件、面向普通用户的纯工具型软件和应用型软件。应用型软件正确的工作基础是具有包括目的性、正确性和显示可理解性的模拟性。需求问题的具体原因有非技术性和社会性因素重视不足的态度问题，传统需求分析方法的缺陷的外部问题。

• 需求工程是所有需求处理活动的总和，它收集信息、分析问题、整合观点、记录需求并验证其正确性，最终反映软件被应用后与其环境互动形成的期望效应。需求工程包括需求开发（需求获取、需求分析、需求规格说明、需求验证）和需求管理两个方面。需求工程师需要具备认知学和社会学等方面比如认知心理学，人类学，社会学，语言学，哲学知识等理论指导和专业、分析、交流、观察、建模、写作、创新和协调等技能。

• 当软件系统被用来解决某些问题时，这些问题的问题集合域就是问题域，而软件系统通过影响问题域能够帮助人们解决问题成为解系统。通过映射建立的共同知识就是问题域和解系统之间的共享现象，也就是两者之间实现交互和互相影响的途径与接口。

• 需求分为功能需求、性能需求、质量属性、对外接口。约束。功能需求包括业务需求、用户需求和系统（级）需求。其他四项可划为非功能需求。其中性能需求常见的包括速度、容量、吞吐量、负载和实时性。约束主要有系统开发及运行的环境、问题域内的相关标准和商业规则。优秀的需求应该具备完整性、正确性、精确性、可行性、必要性、无歧义和可验证的特性。需求并没有反映用户的真实需要、模糊和歧义的需求、信息遗漏、不必要的需求、不切实际的期望等是常见的需求定义错误。

• 从这部分的需求绪论可以看到许都需求方面的整体定义，但并没有具体的步骤指导。从整体定义上来看，需求工程是一个庞大而繁琐的过程，如何抓住软件的功能重点是需求工程的最终目的。

第二部分：需求获取

• 通过第一部分的理论知识，需求工程的第一步行动就是需求获取。需求获取的困难有用户和开发人员的背景不同和立场不同，普通用户缺乏概括性综合性的表述能力，用户存在认知困难，用户越俎代庖和缺乏用户参与等几个方面。每个方面又是具体而复杂的。对于需求获取一定要有一个完整的规划和充足的耐心。获取信息的内容包括需求、问题域描述、环境与约束。获取信息的来源包括涉众、硬数据、相关产品、重要文档、相关技术标准和法规。获取信息的方法包括传统的问卷调查等，集体获取方法（头脑风暴），原型方法，模型驱动方法（uml），认知方法（任务分析和协议分析），基于上下文的方法。获取信息的过程包括在整体上制定组织方案、维护项目的前景和范围、接受需求的不稳定性、控制探索性工作。防止遗漏需求和结束获取。具体的实例影响和作用可以参考上一本书的阅读笔记。最后整理记录保存。

• 软件系统的涉众可以定义为所有能够影响软件系统的实现，或者会被实现后的软件系统所影响的个人和团体。常见的涉众类别有用户，客户，开发者，管理者，领域专家，政府力量，市场力量等。涉众群体不是固定不变的。按照复杂程度可以将信息系统分为小型系统，组织级系统，战略信息系统，组织间系统四种类型。涉众分析包括涉众识别，涉众描述，涉众评估（包括基于涉众扩展特征建立的分布图进行优先级评估，最终得到参与者，环境设定者，被影响者，观众四种类型。还有风险评估和共赢分析），涉众选择（包括以完整采样，态度积极，数量适中，比例恰当为标准的代表采样，参与策略，用户替代源等）。硬数据，包括定量（数据收集表格，统计报表）和定性（整个组织的描述文档，业务指导文档，业务备忘）硬数据两种。常用的硬数据采样技术是随机抽样和分层抽样。

• 需求获取的方法之一是面谈，利用面谈可以获得事实和问题，被会见者的观点，被会见者的感受，组织和个人的目标。面谈中包括两种基本问题类型，开放式问题和封闭式问题，各有优缺点。面谈结构包括金字塔结构，即封闭问题到开放问题的过度结构。漏斗结构，即开放到封闭结构。菱形结构，前两种结构的结合。除了开放问题和封闭问题，还有探究式问题，诱导性问题，双筒问题，元问题，程序性提示等几个其他重要的问题类型。在面谈之前，需要做阅读背景资料，确定面谈主题和目标，选择被会见者，准备被会见者，确定问题和类型等准备。面谈中需要建立一个理想氛围和环境，保持有礼貌的倾听，控制面谈过程，保持面谈主题，使用探究式问题，观察被会见者，使用道具支持。结束后感谢被会见者。记录面谈可以采用笔录，录音摄像（征得被会见者的同意）。面谈结束需要复查面谈记录，总结面谈信息，完成面谈报告。面谈包括结构化面谈，半结构化面谈，非结构化面谈等几个方面。还有群体面谈。除了面谈，还有调查问卷，头脑风暴等方式。

• 原型通常是一个系统的一部分或者一个模型。原型方法通过在用户和需求工程师之间设立一个有形的物件，使得双方的交流更加简单和有效。一方面可以使用户更好的理解需求工程的假设，一方面可以使需求工程师通过观察用户的反馈加深对用户的理解，明确自己的假设正确性。原型类别有演示原型，样板原型，拼凑原型，演示化原型，水平和垂直原型。原型开发方法包括探索式，实验式，演化式。原型方法包括过程，确定需求，开发，评估，修正。优点是及早解决系统开发中的不确定性，风险是会使需求不够完善。

• 常见的观察方法有采样观察，民族志（长期浸入式），话语分析，协议分析，任务分析等。通过对突现，局部，暂时，涉身，开放，模糊，等几个情景性的性质中得到需要采用观察方法解决的问题有:理解复杂的协同事件，获取工作中的异常处理，获取与用户认识不一致的实际知识，了解用户的认知和获取默认知识。其中民族志的优点是能够得到信息的深度理解和让真实世界的社会性因素可见化，缺点是耗时，结果难以传递到开发过程。

• 需求获取的常见模型驱动方法有:面向目标的方法（目标的获取，分析和实现），基于场景的方法，基于用例的方法。用例就是一种场景的文本化表现方式，详细用法就是uml的设计。

• 模型语言有语法，语义和语用。常见的需求分析技术包括，上下文图，数据流图，实体联系图，功能实体矩阵，功能分解图，过程依赖图，用例图，类图等uml建模过程。常见需求分析技术，可以通过wieringa和zachman进行分类（书p206/209）。需求分析方法有传统分析，结构化分析，信息工程和面向对象分析。实践中的需求分析需要需求分析技术的使用，非功能需求的建模，确定需求优先级，新技术方法的需要等。

• 过程建模是结构化分析方法的典型技术，也就是分析需求获取活动获得的信息，发现系统的功能和其与外界的交互，建立能够实现系统功能的过程分解结构，形成系统的过程模型，并用图形的方式将过程模型描述出来。过程建模使用的主要技术有:上下文图，数据流图，微规格说明（过程规范），数据字典。因为已经学过uml建模，大致理解各个方面。最后是逻辑DFD，物理DFD与传统的DFD三种建模方法的区别和优缺点。

• 过程模型更多的是侧重数据产生与使用的时间，地点和方式，而没有描述数据的定义，结构和关系等特性。数据建模就是描述的后者。数据建模包括概念，物理和逻辑数据模型。使用ERD描述数据模型的方法，ERD的创建方法主要有三种：依据充分描述信息的创建，依据硬数据表单的创建，复杂情况下的创建。现在实现ERD与过程模型同步的技术中，功能/实体矩阵是一种比较常见的技术。

• 面向对象建模就是有关uml的各种图和建模方式的描述。

• 需求规格说明活动就是将需求极其软件解决方案进行定义和文档化，并传递给开发人员的需求工程活动。编写需求规格说明文档：清晰明确结构化的文档可以将软件系统的需求信息和解决方案更好的传递给所有的开发者；可以拓展人们的知识记忆能力；可以成为各方人员之间有关软件系统的协议基准；可以成为项目开发活动的一个重要依据；可以尽早发现和减少可能的需求错误，从而减少项目的返工，降低项目的工作量；可以成为有效的智力资产。需求规格说明文档的类型不同表现在，名称，内容，组织方式，表达方式，用途和作用，使用的辅助性。需求规格说明文档的写作需要注意：内容的组织，表达方式，细节描述。优秀的需求规格说明文档应该具备正确性，无歧义，完备性，一致性，根据重要性和稳定性分级，可验证，可修改，可跟踪。

• （1）需求验证确保需求集是正确，完备和一致的，技术上是可解决的，它们在现实世界中的满足是可行和可验证的。方法有需求评审，原型与模拟，开发测试用例，用户手册编制，利用跟踪关系，自动化分析。
  （2）需求确认的目的是确保需求的内容正确性。
  （3）系统验证：正确地建立系统，确保系统能够在预期的环境中正确地执行设定的功能。
  （4）系统确认：建立的系统是正确的。问题修正有需求澄清，发现缺失需求，解决需求冲突，修正不切实际的期望的几种。

• 需求基线就是被明确和固定的需求集合，内容包括软件需求自身和软件需求相关的描述信息。基线的维护包括配置管理和状态维护两个方面。还有需求跟踪，控制变更等模块。

• 需求工程的过程管理：需求工程过程需要依赖的环境因素有市场特性，领域特性，技术成熟度，组织文化，项目特性等。需求工程过程的建立包括建立过程框架和选择工作组件两个步骤。需求工程过程需要专门特定的评价标准和改进方法。评价可以参照REGPG的66个实践。改进的实施步骤有评价当前过程，计划改进活动，培训参与人员，实现新过程，度量新过程，确定下一步行动等六个步骤。过程改进中需要注意以下事项：将需求工程过程放在软件过程的背景下实施改进，改进的实施要建立在现有过程的评价之上，过程的改进要针对目标，过程的改进要有计划，过程的改进应该是渐进和持续的。

• 关于项目的含义对编程系统产品的论述给出很好的启发，区分了下面几个概念：程序、编程产品、编程系统、编程系统产品。需求工程中的项目管理活动包括资源管理、活动管理和交付物件管理。资源支持主要有一定数量技能良好的可用人员；可行的时间限制和充足的资金支持；可用的系统运行环境、软件工具、道具、文档模板、可复用资源等其他资源支持。维持需求团队内部的有效共同应该建立一致的目标，建立有效的共同机制，利用有效的沟通技巧，利用辅助的工具和技术等。需求风险管理就是管理风险的活动，关注软件开发活动和任务的风险和不确定性，并采取行动减少其中的不确定性或者降低风险的影响范围。过程包括风险识别，风险分析，制定风险管理计划，风险跟踪，风险控制等几个方面。