软件工程作业——需求工程的方法和技术

一、常用的需求获取方法：

• 用户面谈
  用户面谈是一种最基本的需求获取手段，它是指分析人员以个别访谈或小组会议的形式与用户进行初步的沟通。用户访谈的形式包括结构化和非结构化两种，结构化是指分析人员按照一定准则事先准备好一系列问题，通过用户对问题的回答来获取有关目标软件方面的内容；非结构化则是只列出一个粗糙的想法，根据访谈的具体情况来进行发挥。　
  优点：可以与项目相关人员进行交谈和讨论；具有私密性，使被访者可以直率地和无隐瞒地回答问题；便于探查一些附加信息或反馈信息；有利于与客户建立良好的关系。
  缺点：访谈是一种非常费时和高成本的方式；难以解决不同的项目干系人之间的冲突和矛盾。
  使用场合：适用于在初步理解整体概念的情况下讨论和交流一些细节问题。

• 问卷调查
  通过设计要问的问题，然后下发到相关的人员手中，让他们填写，再从所填写的内容中获取系统的需求信息。
  优点：可以在短时间内收集到大量的信息，成本较低；问卷采用不记名方式，调查对象可以畅所欲言，得到的信息可以在短时间内汇总。
  缺点：它的针对性太强，更多是客观题，不能主观回答，没有发挥空间；设计问卷需要花费大量时间；回收成本大，不能判别未填写对象。
  使用场合：在完成最初的面谈和分析后，问卷调查可作为一项协作技术收到良好的效果。

• 现场观摩
  走到客户的工作场所，一边观察，一边听客户讲解，安排人员跟随客户一起工作一段时间。这样就可以使得分析人员对客户的需求有更加直观的理解。
  优点：通过实地操作得到的信息会更加准确和真实
  缺点：比较费时间，观察者个人对观察结果影响很大，被观察者可能对观察结果存在异议。
  使用场合：适用于初步准确获得客户需求。

• 需求专题讨论会
  项目主要风险承担人在短暂而紧凑的时间段内集中在一起，一般为一或两天，与会者可以在应用需求上达成共识、对操作过程尽快取得统一意见。
  优点：有助于了解系统需求；有利于共享系统开发的成果；可以与足够多的项目干系人进行讨论和交流，且节省时间。
  缺点：需要占用参与人员比较长的整块时间；主持人的能力和会议的准备工作要做得好。
  适用场合：适用于讨论和审查软件系统方案和模型，解决不同项目干系人之间的冲突和矛盾。

• 原型化方法
  尽可能快地建造一个粗糙的系统，这系统实现了目标系统的某些或全部功能，但是这个系统可能在可靠性、界面的友好性或其他方面上存在缺陷。能够对一些具体问题进行基于实物的有效沟通，从而尽早解决软件开发中存在的各种不确定性。
  优点：利用原型法技术能够快速实现系统的初步模型，供开发人员和用户进行交流,以便较准确地获得用户的需求
  缺点：用户容易产生误解，认为软件系统可以在原型的基础上很容易地构建，但实际上该原型的内部结构和程序质量比较差。
  适用场合：适用于用户需求不明确或描述不清楚的情况。

二、常用的需求分析方法：

• 功能分解方法。
  将新系统作为多功能模块的组合。各功能义可分解为若干子功能及接口，子功能再继续分解。便可得到系统的雏形，即功能分解—功能、子功能、功能接口。
  优点：能够直观表示系统中的功能
  缺点：无法体现功能细节

• 结构化分析方法
  结构化分析方法是一种从问题空间到某种表示的映射方法，是结构化方法中重要且被普遍接受的表示系统，由数据流图和数据词典构成并表示。结构化分析可定义为数据流、数据处理或加工、数据存储、端点、处理说明和数据字典。
  优点：考虑问题的方式较为合理，先确定主要系统功能，然后逐层深入，由简到难，逐渐将一个大致的总体结构具体化，最终全部实现其功能。结构化的模块化使得问题难度降低，编写的程序也更加简明，可读性更高
  缺点：由于要对一个整体问题不断分解，要处理的条件和信息也会越来越多，有时候会给开发人员编程时造成麻烦，这也使得结构化方法能处理的复杂问题难度有一定的限制。不利于维护。

• 信息建模方法
  信息建模可定义为实体或对象、属性、关系、父类型/子类型和关联对象。此方法的核心概念是实体和关系，基本工具是E-R图，其基本要素由实体、属性和联系构成。该方法的基本策略是从现实中找出实体，然后再用属性进行描述。可以快速给出有关事件发生顺序或活动同步约束的问题，能够在逻辑上形成模型来整理繁杂的需求细节。
  优点：E-R图是各种数据模型的共同基础，因而比数据模型更一般、更抽象、更接近现实世界。
  缺点：在E-R建模中，数据和应用相分离，E-R图仅仅着眼于数据，不能提供更多关于业务流程的信息。

• 面向对象的分析方法
  面向对象的分析方法的关键是识别问题域内的对象，分析它们之间的关系，并建立三类模型，即对象模型、动态模型和功能模型。面向对象主要考虑类或对象、结构与连接、继承和封装、消息通信，只表示面向对象的分析中几项最重要特征。类的对象是对问题域中事物的完整映射，包括事物的数据特征(即属性)和行为特征(即服务)。
  优点：其开发软件的思维与人类思维方法一致，用户更容易理解。而由于面向对象的封装性，局部的改变不会影响整体系统的功能，使得管理人员调试维护起来也很方便，可靠性也更高。而面向对象方法也使用了模块化的思想，将复杂问题分解成独立的小问题，降低了难度和成本。
  缺点：面向对象虽然对于用户使用起来很方便，但对于开发人员抽象对象的能力有很高的要求。对于对象的建立不但要准确，还要全面，并且符合模块的要求，若整体模块划分不合理，对功能会有很大的影响

三、需求规格说明

• 采用SRS模板
• 指明需求的来源
• 为项目需求注上标号
• 记录业务规范
• 创建需求跟踪能力矩阵

四、常用的需求验证方法：

• 审查需求文档
  组织一个由不同代表（如分析人员，客户代表，设计人员，测试人员等）组成的小组，对SRS及相关模型进行仔细的审查。

• 原型与模拟
  确定合适原型，准备需求验证。将需求验证涉及的复杂过程或场景定义出来，以辅助需求验证过程的开展。根据已定义过程和场景，按照原型执行过程，发现需求的缺陷、问题并记录，以待后续修正。

• 开发测试用例
  根据用户需求所要求的产品特性写出黑盒功能测试用例，以此检验是否达到了客户期望的要求，是否有被疏忽的需求，需求模型、对话框和原型等是否正确

• 编写用户手册
  在需求开发早期可起草一份用户手册，用它作为需求规格的参考并辅助需求分析。可以验证功能需求，验证项目范围，验证异常流程需求，验证环境与约束需求。

• 利用跟踪关系
  从业务需求到用户需求到系统需求：如果业务需求和用户需求没有得到用户需求和系统需求的充分支持，那么软件需求规格说明文档就存在不完备的缺陷。从系统需求到用户需求到业务需求：如果不能依据跟踪关系找到一条系统需求的前项用户需求和前项业务需求，那么该需求就属于非必要的需求。

五、需求管理的过程

• 确定需求变更控制过程
• 建立变更控制委员会
• 进行需求变更影响分析
• 跟踪所有受需求变更影响的工作产品
• 建立需求基准版本和需求控制版本文档
• 维护需求变更的历史记录
• 跟踪每项需求的状态
• 衡量需求稳定性
• 使用需求管理工具