《软件需求工程》阅读笔记02

2 .需求开发

建议需求开发过程：

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

2. 确定用户类

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

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

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

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

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

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

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

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

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

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

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

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

 

 

2.1    通过业务需求确定项目视图和范围

2.2    确定需求来源

确定需求的来源，将用户分类，与不同类的代表进行沟通

2.3    聆听客户的需求

1.      及早并经常进行座谈

2.      通过流程图和决策树描述用户的决策过程

3.      避免讨论不成熟的细节（如用户界面）

4.      使用USE CASE分析法，并编写Use Case 文档

5.      利用图形分析模型辅助

6.      用户的需求可分为9大类

a)        业务需求

b)        Use Case

c)        业务规则

d)        功能需求

e)        质量属性，即非功能需求，如可靠性，易用性等

f)          外部接口需求，如“从某些设备读取信号”

g)        限制，如“必须使得系统可以WINDOWS和LINUX平台上运行”

h)        数据定义，如“用户ID必须为3位以上的数字、字母组合”

i)          解决思想，即用户自己建议的解决方案。分析人员应该探讨客户为什么提出这种方案

7.      如果需求不能在前期全部确定，尽量确定出一个“基线”

2.4    编写需求文档

2.4.1    需求规格说明书

精确地阐述一个软件系统必须提供的功能和性能以及它所要考虑的限制条件

需求一定要编号

不完整的需求要用“TBD(to be determined)”来标识，并指明由谁、在什么时候确定

使用IEEE 830-1998需求规格说明书模板

2.4.2    数据字典

数据字典应该独立成文

例：身份证号=15位或18位字母和数字的组成的字串，但只有最后一个字符可以使用字母

2.4.3    图形建模方法

数据流图，实体关系图，状态转化图，对话图，类图等

2.5    质量属性

从用户角度：

a.       有效性，系统真正可用时间所占的百分比

b.      高效性，效率、性能

c.       灵活性

d.      完整性，即安全性

e.       互操作性，与其他系统进行交互以利用现有资源的能力

f.        可靠性，无故障执行一段时间的概率

g.       健壮性，即可容错性

h.       可用性，即易用性

从开发者角度：

a.       可维护性，纠正一个缺陷的简易程度

b.      可移植性，从一个环境移植到另一个环境的工作量

c.       可重用性

d.      可测试性，如“一个模块的最大循环复杂度不能超过 20”

2.6    通过原型法减少项目风险

建立原型是为了解决在产品开发的早期不确定的问题

两种类别：

1.      抛弃型原型

2.      进化型原型，可作为构造产品的基础

可以让人模拟软件系统，“快速地开发出一个原型”

2.7    设定需求优先级

必要性

常用的三级划分：

1.      基本的。必须实现

2.      条件的。可以增强功能，但没有也可以接受

3.      可选的。实现不实现均可

2.8    需求质量验证

2.8.1    需求评审

IBM制定了一个审查的推荐过程

2.8.2    开发测试用例

可以帮助找出需求中的错误