《软件需求管理》美K.E.维格斯Karl+E.Wiegers著003

《《软件需求管理》美K.E.维格斯Karl+E.Wiegers著003》由会员分享，可在线阅读，更多相关《《软件需求管理》美K.E.维格斯Karl+E.Wiegers著003（8页珍藏版）》请在金锄头文库上搜索。

1、下载第 3章 需求工程的推荐方法1 0年前，我曾热衷于追求软件的开发方法论的研究，将整套整套的模型、技术等用于解决项目难题。但现在我更注重应用“最佳方法” 。最佳方法强调将软件工具包拆分成多个子包以分别应用于不同的问题，而并不是去设计或购买一整套的解决方案。即使你采用了一套商业上的方法，你也应当在其中增加那些在业界被认为行之有效的推荐技术。“最佳方法”这个词值得讨论一下：谁能确定什么是“最佳”的呢？而且，得到这个结论的依据何在？一种方案是把这方面的专家召集起来分析众多不同组织中成功和失败的项目（ Browm 1996） 。专家们将那些成功项目中提供高效的方法和失败项目中导致低效甚至无效的方法都

2、归纳出来。这样，专家们就能找到公认的能收到实效的关键方法。这些方法即是“最佳方法” ，其本质就是有助于项目成功的有效方法。本章的标题是“需求工程的推荐方法”而非“最佳方法” 。下面分七类介绍了四十余种方法，能有助于开发小组做好需求工作，推荐方法如表 3 - 1所列。表 3-1 需求工程推荐方法知 识 技 能 需 求 管 理 项 目 管 理 培训需求分析人员 确定变更控制过程 选择合适的生存周期 培训用户代表和管理人员 建立变更控制委员会 确定需求的基本计划 培训应用领域的开发人员 进行变更影响分析 协商约定 汇编术语 跟踪影响工作产品的每项变更 管理需求风险 编写需求文档的基准版本和控制版本

3、跟踪需求工作 维护变更历史记录 跟踪需求状态 衡量需求稳定性 使用需求管理工具需求开发获 取 分 析 编写规格说明书 验 证 编写项目视图与范围 绘制关联图 采用软件需求规格说明模版 审查需求文档 确定需求开发过程 创建开发原型 指明需求来源 依据需求编写测试用例 用户群分类 分析可行性 为每项需求注上标号 编写用户手册 选择产品代表 确定需求优先级 记录业务规范 确定合格的标准 建立核心队伍 为需求建立模型 创建需求跟踪能力矩阵 确定使用实例 编写数据字典 召开应用程序开发 应用质量功能调配联系（ J A D）会议 （ Q F D） 分析用户工作流程 确定质量属性 检查问题报告 需求重用并非

4、上面所有的条目都是最佳方法，或许也并非全部经过了系统地评估。但无论如何，我和许多实践者都觉得这些技术是很有效的 (Sommerville and Sawyer 1997)。其中每一条都在本章给予了简要介绍，并在其他章节或其他更详细地讨论技术来源的地方给出了参考文献。表 3 - 2把表 3 - 1中的方法按实施的优先顺序和实施难度进行了分组。由于所列的方法都是有所裨益的，故最好是循序渐进，先从那些相对容易实施而对项目有很大影响的方法开始。表 3-2 实施需求工程的推荐方法优先级别 难 度高 中 低 确定需求开发过程 确定使用实例 培训应用领域的开发人员 确定需求的基本计划 确定质量属性 编写项目

5、视图与范围 协商约定 确定需求优先级 用户群分类 采用软件规格说明模板 绘制关联图 确定变更控制过程 指明需求来源 建立变更控制委员会 为每项需求注上标号 审查需求文档 编写需求文档的基准版本和控制版本 培训用户代表和管理人员 培训需求分析人员 汇编术语 为需求建立模型 建立核心队伍 选择产品代表 管理需求风险 创建开发原型 编写数据字典 使用需求管理工具 分析可行性 记录业务规范 创建需求跟踪能力矩阵 确定合格的标准 依据需求编写测试用例 进行变更影响分析 跟踪需求状态 跟踪影响工作产品的每项变更 选择合适的生存周期 召开应用程序开发联系 分析用户工作流程（ J A D）会议 检查问题报告

6、需求重用 编写用户手册 应用质量功能调配（ Q F D） 维护变更历史记录 衡量需求稳定性 跟踪需求工作不要想着把所有这些方法都用于你的下一个项目。而应该考虑将其中的一些方法推荐到你的需求工具箱中。不管你的项目处在开发的哪个阶段，你都可以马上开始应用某些方法，譬如变更管理的处理。其它如需求获取等可以在你的下一个项目开始时付诸应用。当然其它一些方法也可能并不适合你目前的项目。第 4章介绍一些用于评价需求工程的方法，并可设计一张实施需求方法改进的步骤图。具体的改进方法在此处和第 4章中都给予介绍。3.1 知识技能绝大部分的软件开发人员都没有接受过高效需求工程所需技能的正规培训。但许多开发人员在职业

7、生活中的某个阶段总会扮演一个需求分析员的角色，与客户一起工作：收集，分析，编写需求文档。不能过高期望开发人员在需求工程的信息沟通中的“天份” 。一定的培训将有助于提高需求分析员的能力和水平。第 3章 需求工程的推荐方法 19下载高中低因为需求对项目成功极为重要，所有的项目风险承担者都应该对需求工程的重要性、合理性及其方法有一个基本的了解。把项目风险承担者（例如开发人员，市场人员，客户，测试人员和管理人员）召集起来进行为期一天的需求过程概要学习，这对建立一个合作团队是很有效的。所有参与者都会更好地明白各自所面临的挑战是什么，以及为了整个团队获得成功大家都需要作些什么。同样，开发人员也能对应用领域

8、的术语和一些基本概念有大致的了解。1 ) 培训需求分析人员 所有的开发人员都应接受一个基本的需求工程培训。但那些负责收集 ( c a p t u r i n g )、编写文档和分析用户需求的人员应当进行为期一周或更长时间的培训。把高水平的需求人员组织起来，通过良好的信息交流，了解应用领域并有效地应用需求工程中的成熟技术。2) 培训软件需求的用户代表和管理人员 参与软件开发的用户代表应接受为期一天左右关于需求工程的培训，开发管理者和客户管理者也应参加。这样的培训将使他们明白强调需求的重要性，以及忽略需求带来的风险。参加过我组织的需求讨论会的一些用户表示，他们在此之后更能理解软件开发人员了。3)

9、让开发人员了解应用领域的基本概念 组织一些简短的关于客户业务活动、术语、目标等方面的讨论会以帮助开发人员对应用领域有个基本了解。这能减少误解及工程中的返工。你可能要为每位开发人员安排一个用户伙伴以便在项目过程中解释业务术语和概念。产品代表就应该扮演这样的角色。4) 编写项目术语汇编 为减少沟通方面的问题，编一部术语汇编将项目应用领域的专用词汇给予定义说明，既要包括那些有多种含义与用法的术语，也要包括那些在专用领域和一般使用中有不同含义的词。3.2 需求获取第 1章讨论了需求的三个层次：业务，用户和功能。在项目中它们在不同的时间来自不同的来源，也有着不同的目标和对象，并需以不同的方式编写成文档。

10、业务需求（或产品视图和范围）不应包括用户需求（或使用实例） ，而所有的功能需求都应该源于用户需求。同时你也需要获取非功能需求，如质量属性。你可以在下列章节中找到相关主题的详细内容： 第 4章 确定需求开发过程。 第 6章 编写项目视图和范围文档。 第 7章 将用户群分类并归纳其特点，为每个用户类选择产品代表（ product champion） 。 第 8章 让用户代表确定使用实例。 第 11章 确定质量属性和其它非功能需求。1) 确定需求开发过程 确定如何组织需求的收集、分析、细化并核实的步骤，并将它编写成文档。对重要的步骤要给予一定指导，这将有助于分析人员的工作，而且也使收集需求活动的安排

11、和进度计划更容易进行。2) 编写项目视图和范围文档 项目视图和范围文档应该包括高层的产品业务目标，所有的使用实例和功能需求都必须遵从能达到的业务需求。项目视图说明使所有项目参与者对项目的目标能达成共识。而范围则是作为评估需求或潜在特性的参考。3) 将用户群分类并归纳各自特点 为避免出现疏忽某一用户群需求的情况，要将可能使20 第一部分 软件需求：是什么和为什么 下载用产品的客户分成不同组别。他们可能在使用频率、使用特性、优先等级或熟练程度等方面都有所差异。详细描述出它们的个性特点及任务状况，将有助于产品设计。4) 选择每类用户的产品代表 为每类用户至少选择一位能真正代表他们需求的人作为那一类用

12、户的代表并能作出决策。这对于内部信息系统的开发是最易实现的，因为此时，用户就是身边的职员。而对于商业开发，就得在主要的客户或测试者中建立起良好的合作关系，并确定合适的产品代表。他们必须一直参与项目的开发而且有权作出决策。5) 建立起典型用户的核心队伍 把同类产品或你的产品的先前版本用户代表召集起来，从他们那里收集目前产品的功能需求和非功能需求。这样的核心队伍对于商业开发尤为有用，因为你拥有一个庞大且多样的客户基础。与产品代表的区别在于，核心队伍成员通常没有决定权。6) 让用户代表确定使用实例 从用户代表处收集他们使用软件完成所需任务的描述 使用实例，讨论用户与系统间的交互方式和对话要求。在编写

13、使用实例的文档时可采用标准模版，在使用实例基础上可得到功能需求。7) 召开应用程序开发联系会议 应用程序开发联系（ J A D）会议是范围广的、简便的专题讨论会（ w o r k s h o p） ，也是分析人员与客户代表之间一种很好的合作办法，并能由此拟出需求文档的底稿。该会议通过紧密而集中的讨论得以将客户与开发人员间的合作伙伴关系付诸于实践（ Wood and Silver 1995） 。8) 分析用户工作流程 观察用户执行业务任务的过程。画一张简单的示意图（最好用数据流图）来描绘出用户什么时候获得什么数据，并怎样使用这些数据。编制业务过程流程文档将有助于明确产品的使用实例和功能需求。你甚

14、至可能发现客户并不真地需要一个全新的软件系统就能达到他们的业务目标（ McGraw and Harbison 1997） 。9) 确定质量属性和其它非功能需求 在功能需求之外再考虑一下非功能的质量特点，这会使你的产品达到并超过客户的期望。这些特点包括性能、有效性、可靠性、可用性等，而在这些质量属性上客户提供的信息相对来说就非常重要了。10) 通过检查当前系统的问题报告来进一步完善需求 客户的问题报告及补充需求为新产品或新版本提供了大量丰富的改进及增加特性的想法，负责提供用户支持及帮助的人能为收集需求过程提供极有价值的信息。11) 跨项目重用需求 如果客户要求的功能与已有的产品很相似，则可查看需

15、求是否有足够的灵活性以允许重用一些已有的软件组件。3.3 需求分析需求分析（ requirement analysis）包括提炼、分析和仔细审查已收集到的需求，以确保所有的风险承担者都明白其含义并找出其中的错误、遗漏或其它不足的地方。分析员通过评价来确定是否所有的需求和软件需求规格说明都达到了第 1章中优秀需求说明的要求。分析的目的在于开发出高质量和具体的需求，这样你就能作出实用的项目估算并可以进行设计、构造和测试。通常，把需求中的一部分用多种形式来描述，如同时用文本和图形来描述。分析这些不同的视图将揭示出一些更深的问题，这是单一视图无法提供的（ Davis 1995） 。分析还包括与客户的交流以澄清某些易混淆的问题，并明确哪些需求更为重要。其目的是确保所有风险承第 3章 需求工程的推荐方法 21下载担者尽早地对项目达成共识并对将来的产品有个相同而清晰的认识。下面几章对需求分析中的任务进行了详细讨论： 第 6章 绘制系统关联图。 第 9章 建立数据字典。 第 1 0章 为需求建立模型。 第 1 2章 建立用户接口原型。 第 1 3章 确定需求优先级。1) 绘制系统关联图 这种关联图是用于定义系统与系统外部实体间的界限和接口的简单模型。同时它也明确了通过接口的信息流和物质流。2) 创建用户接口原型 当开发人员或用户不能确定需求时，开发一个用户接口原型 一个可能的局部实现