软件需求学习笔记

软件项目中40%-60%的缺陷都是由需求分析阶段的过失所致。

确定和管理用户需求是问题最多的两个环节。

软件和系统项目涉众（stake holder）有：客户、用户、需求分析人员、开发、测试、文档编制人员、项目经理、法律人员、生产人员、市场营销人员。

需求必须被记录成文档。

软件行业对需求是什么没有统一的定义。

需求定义1：产品为向涉众（并非所有涉众都是用户）提供价值而必须具备的特性。

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

需求的层次如下：
业务需求：远景与范围文档，组织希望达到的目标，也被称为项目轮廓图和市场需求文档。

用户需求：用户的目标，用例、场景描述，事件，响应表等形式。

功能需求：开发人员必须在产品中实现的软件功能，也被称为行为需求。

系统需求：包含多个子系统的产品的顶级需求，既可以包含软件子系统，也可以包含硬件子系统。

质量属性：

外部界面：

约束：

软件需求规格说明书：SRS

文档、

在开发之前，即使无法确定所有需求，也可以用迭代和增量方法，每次实现一部分需求，得到用户反馈后再进入下一循环。但不能以此为借口直接开始编码，应该仔细分析需求。

需求分析员的工作，收集需求，分析需求，记录需求，需求开发，需求变更管理。

要学会记录需求，记录需求不能，发现需求才难。只有记录了需求，才可以对需求进行排序，并估算人力和资源，及在必须缩小时做出取舍。

需求问题导致的主要后果是返工，重复已经做好的事情，返工成本占总开发成本的30％-50％，而返工的情况，70％-80％是需求错误导致的。

返工的成本指已开发的系统不符合用户需求需求重新开发，延误了本项目的进度，浪费了大量的人力和财力，还延续了下一个项目的进度。

项目成功是以商定的成本和进度交付满足用户对功能和质量期望的产品。

直接从产品的实际用户处收集需求这一过程是不可替代的。

业务需求:来自于描述了客户，公司或其他涉众希望达到的业务目标，为项目的其他部分提供了参考框架。所有其他产品特性和需求都必须满足业务需求。

用户需求:来自于实际使用产品的人。用户可以描述出他们需要使用产品完成哪些任务，以及希望系统具备哪些产品质量特性。

功能需求