文档介绍：-
. z.
1．概念　　需求的定义包括从用户角度〔系统的外部行为〕，以及从开发者角度〔一些内部特性〕来阐述需求。　　关键的问题是一定要编写需求文档。我曾经目睹过一个工程中途更换了所有的 z.
工程方案与需求一致。　　估计变更需求所产生影响并在此根底上协商新的承诺，这种承诺具体表达在工程解决方案上。　　让每项需求都能与其对应的设计、源代码和测试用例联系起来以实现跟踪。　　在整个工程过程中跟踪需求状态及其变更情况。　　以上几点说明是我总结了成功实施工程后系统分析人员的经历，同时也根据国内外的其他系统实施的相关成功经历，进展了总结。
4．需求的类型　　下面这些定义是需求工程领域中常见术语的定义。　　软件需求包括三个不同的层次：业务需求、用户需求和功能需求〔也包括非功能需求〕。1．业务需求〔business requirement〕反映了组织机构或客户对系统、产品高层次的目标要求，它们在工程视图与范围文档中予以说明。2．用户需求(user requirement) 文档描述了用户使用产品必须要完成的任务，这在使用实例〔use case〕文档或方案脚本说明中予以说明。3．功能需求(functional requirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。在软件需求规格说明书〔SRS〕中说明的功能需求充分描述了软件系统所应具有的外部行为。软件需求规格说明在开发、测试、质量保证、工程管理以及相关工程功能中都起了重要的作用。对一个大型系统来说，软件功能需求也许只是系统需求的一个子集，因为另外一些可能属于子系统〔或软件部件〕。　　作为功能需求的补充，软件需求规格说明还应包括非功能需求，它描述了系统展现给用户的行为和执行的操作等。它包括产品必须遵从的标准、标准和合约；外部界面的具体细节；性能要求；设计或实现的约束条件及质量属性。所谓约束是指对开发人员在软件产品设计和构造上的限制。质量属性是通过多种角度对产品的特点进展描述，从而反映产品功能。多角度描述产品对用户和开发人员都极为重要。　　下面以一个字处理程序为例来说明需求的不同种类。业务需求可能是："用户能有效地纠正文档中的拼写错误〞，该产品的包装盒封面上可能会标明这是个满足业务需求的拼写检查器。而对应的用户需求可能是"找出文档中的拼写错误并通过一个提供的替换项列表来供选择替换拼错的词〞。同时，该拼写检查器还有许多功能需求，如找到并高亮度提示错词的操作；显示提供替换词的对话框以及实现整个文档范围的替换。　　从以上定义可以发现，需求并未包括设计细节、实现细节、工程方案信息或测试信息。需求与这些没有关系，它关注的是充分说明你终究想开发什么。工程也有其它方面的需求，如开发环境需求或发布产品及移植到支撑环境的需求。尽管这些需求对工程成功也至关重要，但它们并非本书所要讨论的。
5．需求分析的原则　　不重视需求过程的工程队伍将自食其果。需求工程中的缺陷将给工程成功带来极大风险，这里的"成功〞是指推出的产品能以合理的价格、及时地在功能、质量上完全满足用户的期望。下面将讨论一些需求风险。
不适当的需求过程所引起的一些风险:
1. 无足够用户参与　　客户经常不明白为什么收集需求