《软件需求》学习笔记

《软件需求》学习笔记

 

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

一、需求层次

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

需求分析过程：

1、  需求收集：

定义项目的视图和范围。

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

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

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

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

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

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

2、  需求分析：

绘制关联图

创建开发原型

确定需求优先级

为需求建立模型

编写数据字典

3、  编写规格说明书

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

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

4、  需求验证

对需求进行审查

用测试用例来验证需求

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

 

 

需求层次

1、  软件需求层次：

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

 

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

 

  

需求开发

3、优秀需求具有的特性

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

1）完整性

2）正确性

3）可行性

4）必要性

5）划分优先级

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

6）无二义性

7）可验证性

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

 

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

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

A)        问题获取

B)        分析

C)        编写规格说明

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

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

 

5、需求工程推荐方法

 

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

 

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、编写软件需求规格说明

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

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

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

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

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

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

 

 

	抛 弃 型	演 化 型
水平	• 澄清并精化使用实例和功能需求 • 查明遗漏的功能 • 探索用户界面方法	• 实现核心的使用实例 • 根据优先级，实现附加的使用实例 • 开发并精化We b站点
垂直	• 证明技术的可行性	• 实现并发展核心的客户/服务器功能层和通信层 • 实现并优化核心算法

9、减少项目风险的方法

可以利用软件原型这种技术减少客户对产品不满意的风险。一个软件原型是所提出的新产品的部分实现。使用原型有三个主要目的：

• 明确并完善需求   原型作为一种需求工具，它初步实现所理解的系统的一部分。用户对原型的评价可以指出需求中的许多问题，在你开发真正产品之前，可以最低的费用来解决这些问题。

• 探索设计选择方案   原型作为一种设计工具，用它可以探索不同的用户界面技术，使系统达到最佳的可用性，并且可以评价可能的技术方案。

• 发展为最终的产品原型   作为一种构造工具，是产品最初子集的完整功能实现，通过一系列小规模的开发循环，你可以完成整个产品的开发。

软件原型的典型应用：

 

	抛 弃 型	演 化 型
水平	• 澄清并精化使用实例和功能需求 • 查明遗漏的功能 • 探索用户界面方法	• 实现核心的使用实例 • 根据优先级，实现附加的使用实例 • 开发并精化We b站点
垂直	• 证明技术的可行性	• 实现并发展核心的客户/服务器功能层和通信层 • 实现并优化核心算法

 

需求管理

10、需求管理的策略、主要活动

需求管理的策略：包括变更控制，需求跟踪（跟踪矩阵、需求状态跟踪如 已建议，已批准，已实现，已验证，已删除）和变更的影响分析。

需求管理的主要活动：

 

 

11、常见的需求管理工具

RequisitePro

CaliberRM

DOORS

这个网站http://tech.it168.com/zt/requiremanage/index.html有这些工具使用方法介绍。

这里推荐几个开源需求管理工具: JRequisite、reqheap

 

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/byxdaz/archive/2009/09/11/4544633.aspx