软件需求读书笔记_2006年3月31日

2006年3月31日

软件需求的定义

　　软件行业存在这样一个问题，用于描述需求工作的术语没有统一的定义。对同一项需求，不同的人会有不同的描述，称其为用户需求、软件需求、功能需求、系统需求、技术需求、业务需求或产品需求。客户对需求的定义，在开发人员看来可能只是高级别的产品概念；而开发人员的需求概念对用户来说也许就是详细的用户界面设计。定义的多样性导致了令人迷惑和沮丧的沟通问题。

　　需求必须被记录成文档，这一点很重要。公凭一堆电子邮件、便条、会议记录，以及对走廊中几次交谈的模糊印象就自称掌握了需求，那纯属自欺欺人。

　　咨询专家Brian Lawrence提出，需求是“任何促成设计决策的因素”。很多信息都属于这一范围。

　　IEEE的软件工作标准术语表（1990）则将需求定义为：

• 用户为解决某个问题或达到某个目标而需具备的条件或能力。
• 系统或系统组件为符合合同、标准、规范或其他正式文档而必须满足的条件或必须具备的能力。
• 上述第一项或第二项中定义的条件和能力的文档表达。

　　这一定义既体现了用户对需求的看法（系统的外部行为），也代表了开发人员的观点（一些深层的特性）。术语用户隶属于涉众，因为并非所有涉众都是用户。

　　我对需求的理解是：产品为向涉众提供价值而必须具备的特性。

　　下面这条定义则确认了需求类型的多样性（Sommervill和Sawyer 1997）：

　　需求是对应该实现什么功能的说明――可以是对系统运行方式或系统特征与属性的描述；还可能是对系统开发过程的约束。

　　很显然，对于需求是什么没有一个统一的定义。为便于交流，我们需要协商决定一组限定词来修饰“需求”这个内涵丰富的术语，并认识到用可通用的形式记录需求的重要性。

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