“21天好习惯” 第一期-18

软件需求——第一章 软件需求基础知识

1.1 软件需求的定义

• 软件行业存在这样一个问题，用于描述需求工作的术语没有统一的定义。
• 对同一项需求，不同的人会有不同的描述，称其为用户需求、软件需求、功能需求、系统需求、技术需求、业务需求或产品需求。
• 客户对需求的定义，在开发人员看来可能只是高级别的产品概念；而开发人员的需求概念对用户来说也许就是详细的用户界面设计。
• 需求必须被记录成文档，这一点很重要。

IEEE的软件工程标准术语表则将需求定义为: 用户为解决某个问题或达到某个目标而需具备的条件或能力。系统或系统组件为符合合同、标准、规范或其他正式文档而必须满足的条件或必须具备的能力。

注意:不要一厢情愿地认为项目涉众对需求的理解是一致的。应该事先给出定义，才能保证大家谈论的是同一个问题。

1.1.2 软件需求的层次

软件需求包括3个不同的层次——业务需求、用户需求和功能需求: 除此之外，每个系统还有各种非功能需求。

• 业务需求(Business requirement)表示组织或客户高层次的目标。
• 用户需求(user requirement)描述的是用户的目标，或用户要求系统必须能完成的任务。
• 功能需求(funetional requirement)规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。
• 术语系统需求(system requirement)用于描述包含多个子系统的产品(即系统)的顶级需求。

 

 1.1.3 不属于需求的内容

• 需求规格说明中不包括(除已知约束外的)设计和实现的细节、项目的计划信息，以及测试信息(Leffingwell和Widrig 2000)。
• 项目中通常还包括其他类型的需求，如开发环境需求，进度或预算限制，帮助新用户跟上进度的培训需求，或者发布产品使其转入支持环境的需求。 这些都属于项目需求而不是产品需求 

1.2 需求的开发与管理 

需求领域的术语问题，有的作者称其为需求工程(Sommerville和Kotonya 1998)；也有人称之为需求管理(Leffingwell和Widrig 2000)。 把软件需求工程划分为需求开发和需求管理，如下图所示。

 1.2.1  需求开发

需求开发可进一步细分为获取(Elicitation)、分析(analysis)、规格说明(specification)和确认(Validation)。

 1.2.2  需求管理

需求管理的任务是“与客户就软件项目的需求达成并保持一致“

下图从另一个角度反映了需求开发与需求管理间的区别

 1.3  所有项目都有需求

• 需求在软件项目中的重要地位 ： 软件系统开发过程中最难的部分是对要开发什么作出准确的判断。
• 所有概念性工作中最难的是建立详细的技术需求，包括所有与用户、机器和其他软件系统的接口。 在开始开发软件之前，往往无法确定所有的需求。这种情况下，可以采用迭代和增量方法，每次实现一部分需求，得到用户反馈后再进入下一循环。