《软件需求》学习笔记

现在的位置: 首页 > 自动控制 > 工业·编程 > 正文

RSS

上篇下篇

《软件需求》学习笔记

2012-08-12 06:46 ⁄ 工业·编程 ⁄ 共 3894字 ⁄ 字号小中大 ⁄ 暂无评论

前几天读了Karl E.Wiegers《软件需求》，书的内容写得非常好。我这里谈谈读了此书之后的一些感受。概括起来包括以下几点：

一、需求层次

二、需求开发（需求工程方法、需求来源、如何获取需求并给出一些指导方法）

需求分析过程：

1、需求收集：

定义项目的视图和范围。

学习与了解本行业的知识，这样与用户比较容易沟通。

访问有潜力的用户,对用户进行分类并找各自合适的代表，找出新软件产品的用户需求。注意与用户沟通技巧。

对目前市场上竞争产品进行研究，进行功能提取与解决方案分析，写成文档。

收集了用户在使用现有系统过程中所遇到问题的信息，还接受了用户关于系统改进的想法。

市场调查和用户问卷调查。

观察正在工作的用户，预见用户在使用当前系统时所遇到的问题，并能分析新的系统可有效支持工作流程与功能。

2、需求分析：

绘制关联图

创建开发原型

确定需求优先级

为需求建立模型

编写数据字典

3、编写规格说明书

采用软件需求规格说明模版，可以采用CMMI中的需求规格说明模版。

正确的、完整的表达所描述的需求。

4、需求验证

对需求进行审查

用测试用例来验证需求

三、需求管理方法以及常用需求管理工具管理需求

需求层次

1、软件需求层次：

层次	内容描述	呈现方式
业务需求	组织机构或客户对系统、产品高层次的目标要求。	项目视图与范围文档中予以说明
用户需求	用户使用产品必须要完成的任务	Use Case
功能需求	必须实现的软件功能	需求规格说明文档中功能需求说明
非功能需求	系统展现给用户的行为和执行的操作等，包括产品必须遵从的标准、规范和合约；外部界面的具体细节；性能要求；设计或实现的约束条件及质量属性。	需求规格说明文档中非功能需求说明

2、软件需求各组成部分之间的关系，实际上也就是业务需求、用户需求、功能需求、非功能需求等之间的关系。

clip_image001

需求开发

3、优秀需求具有的特性

7大特性，多注意优先级与可验证性，因为这两点在项目中实际关注的比较少。

1）完整性

2）正确性

3）可行性

4）必要性

5）划分优先级

给每项需求、特性或使用实例分配一个实施优先级以指明它在特定产品中所占的分量。如果把所有的需求都看作同样重要，那么项目管理者在开发或节省预算或调度中就丧失控制自由度。

6）无二义性

7）可验证性

检查一下每项需求是否能通过设计测试用例或其它的验证方法，如用演示、检测等来确定产品是否确实按需求实现了。如果需求不可验证，则确定其实施是否正确就成为主观臆断，而非客观分析了。

4、需求工程的结构（需求开发与需求管理）

1. 需求开发，分为四个步骤

A) 问题获取

B) 分析

C) 编写规格说明

D) 验证(评审，编制测试用例)

2. 需求管理，即需求追踪、变更控制等

5、需求工程推荐方法

知

识

技

能

• 培训需求分析人员

• 培训用户代表和管理人员

• 培训应用领域的开发人员

• 汇编术语

需

求

管

理

• 确定变更控制过程

• 建立变更控制委员会

• 进行变更影响分析

• 跟踪影响工作产品的每项

• 编写需求文档的基准版本

• 维护变更历史记录

• 跟踪需求状态

• 衡量需求稳定性

• 使用需求管理工具

项

目

管

理

• 选择合适的生存周期

• 确定需求的基本计划

• 协商约定

• 管理需求风险

• 跟踪需求工作

需

求

开

发

获取

• 编写项目视图与范围

• 确定需求开发过程

• 用户群分类

• 选择产品代表

• 建立核心队伍

• 确定使用实例

• 召开应用程序开发

• 联系（J A D）会议

• 分析用户工作流程

• 确定质量属性

• 检查问题报告

• 需求重用

分析

• 绘制关联图

• 创建开发原型

• 分析可行性

• 确定需求优先级

• 为需求建立模型

• 编写数据字典

• 应用质量功能调配

（Q F D）

编写规格说明书

• 采用软件需求规格说明模版

• 指明需求来源

• 为每项需求注上标号

• 记录业务规范

• 创建需求跟踪能力矩阵

验证

• 审查需求文档

• 依据需求编写测试用例

• 编写用户手册

• 确定合格的标准

需求工程注重应用“最佳方法”。不要想着把所有这些方法都用于你的下一个项目。而应该考虑将其中的一些方法推荐到你的需求工具箱中。不管你的项目处在开发的哪个阶段，你都可以马上开始应用某些方法，譬如变更管理的处理。其它如需求获取等可以在你的下一个项目开始时付诸应用。当然其它一些方法也可能并不适合你目前的项目。

6、需求来源、需求收集方法

软件需求可以来自方方面面，这取决于所开发产品的性质和开发环境。需从不同用户代表和来源收集需求，这说明了需求工程是以相互交流为核心的性质。下面是几个软件需求的典型来源。

1）. 访问并与有潜力的用户探讨为找出新软件产品的用户需求，最直截了当的方法是询问他们。

2）. 把对目前的或竞争产品的描述写成文档

文档可以描述一种所必须遵循的标准或产品所必须遵循的政府或工业规则。

3）. 系统需求规格说明

一个包含软、硬件的产品需要一个高档次的系统需求规格说明以介绍整个产品。系统需求的子集被分配到每个软件子系统中（Nelsen 1990）。附加的详细软件功能需求将从有关软件

的系统需求里获得。

4）. 对当前系统的问题报告和增强要求指导用户和提供技术支持的工作人员是最有价值的需求来源。他们收集了用户在使用现有系统过程中所遇到问题的信息，还接受了用户关于系统改进的想法。

5）. 市场调查和用户问卷调查

调查有助于从广大有潜力的用户那里获得大量定量的数据，务必调查相关的用户并询问一些能产生反响的好问题。

6）. 观察正在工作的用户

对当前系统的用户和将来系统的有潜力的用户，分析员观察“日常工作”以获得经验，这些经验能提供很有价值的信息。分析员可通过观察用户与所关联的任务环境的工作流程来预见用户在使用当前系统时所遇到的问题，并能分析新的系统可有效支持工作流程的方面（McGraw and Harbison 1997; Beyer and Holtzblatt 1998）。比起仅仅简单地询问用户，并记下用户在处理任务时的步骤来说，直接观察用户的工作流程可以对他们的活动有更正确的理解。分析员必须抽象和总结用户的直接活动，以确保所获得的需求具有普遍性，而不仅仅代表单个用户。一个富有技巧的分析员还可以为改进用户的当前事务处理过程提出一些见解。

7）. 用户任务的内容分析

通常通过开发具体的情节（s c e n a r i o）或活动顺序（有时称作“情节” ），可以确定用户利用系统需要完成的任务，分析员由此可以获得用户用于处理任务的必要的功能需求。这是使用实例方法的精髓。

7、需求开发活动指导方针

对于需求开发没有一个简单的、公式化的途径。下面列出了1 4个步骤，你可以利用它们指导你的需求开发活动。

1）. 定义项目的视图和范围

2）. 确定用户类（比如市场人员、财务人员、生产人员等）

3）. 在每个用户类中确定适当的代表

4）. 确定需求决策者和他们的决策过程

5）. 选择你所用的需求获取技术

6）. 运用需求获取技术对作为系统一部分的使用实例进行开发并设置优先级

7）. 从用户那里收集质量属性的信息和其它非功能需求

8）. 详细拟订使用实例使其融合到必要的功能需求中

9）. 评审使用实例的描述和功能需求

10）. 如果有必要，就要开发分析模型用以澄清需求获取的参与者对需求的理解

11）. 开发并评估用户界面原型以助想像还未理解的需求

12）. 从使用实例中开发出概念测试用例

13）. 用测试用例来论证使用实例、功能需求、分析模型和原型

14）. 在继续进行设计和构造系统每一部分之前，重复 6 ~ 1 3步

8、编写软件需求规格说明

可以用三种方法编写软件需求规格说明：

• 用好的结构化和自然语言编写文本型文档。

• 建立图形化模型，这些模型可以描绘转换过程、系统状态和它们之间的变化、数据关系、

逻辑流或对象类和它们的关系。

• 编写形式化规格说明，这可以通过使用数学上精确的形式化逻辑语言来定义需求。

由于形式化规格说明具有很强的严密性和精确度，因此，所使用的形式化语言只有极少数软件开发人员才熟悉，更不用说客户了。虽然结构化的自然语言具有许多缺点，但在大多数软件工程中，它仍是编写需求文档最现实的方法。包含了功能和非功能需求的基于文本的软件需求规格说明已经为大多数项目所接受。图形化分析模型通过提供另一种需求视图，增强了软件需求规格说明。

clip_image002