软件需求分析

软件需求分析

软件需求分析所要做的工作是深入描述软件的功能和性能，确定软件设计的限制和软件同其它系统元素的接口细节，定义软件的其它有效性需求。 　　进行需求分析时，应注意一切信息与需求都是站在用户的角度上。尽量避免分析员的主观想象，并尽量将分析进度提交给用户。在不进行直接指导的前提下，让用户进行检查与评价。从而达到需求分析的准确性。 　　分析员通过需求分析，逐步细化对软件的要求，描述软件要处理的数据域，并给软件开发提供一种可转化为数据设计、结构设计和过程设计的数据和功能表示。在软件完成后，制定的软件规格说明还要为评价软件质量提供依据。

需求分析的任务

　　开发软件系统最为困难的部分就是准确说明开发什么。最为困难的概念性工作便是编写出详细技术需求，这包括所有面向用户、面向机器和其它软件系统的接口。同时这也是一旦做错，将最终会给系统带来极大损害的部分，并且以后再对它进行修改也极为困难。目前，国内产品的庞杂，一家企业可能有几个系统并立运行，它们之间接口是系统开发人员最头痛的问题。对于商业最终用户应用程序，企业信息系统和软件作为一个大系统的一部分的产品是显而易见的。但是对于我们开发人员来说，并没有编写出客户认可的需求文档，我们如何知道项目于何时结束？而如果我们不知道什么对客户来说是重要的，那我们又如何能使客户感到满意呢？ 　　然而，即便并非出于商业目的的软件需求也是必须的。例如库、组件和工具这些供开发小组内部使 　　用的软件。当然你可能偶尔勿需文档说明就能与其他人意见较为一致，但更常见的是出现重复返工这 　　种不可避免的后果，而重新编制代码的代价远远超过重写一份需求文档的代价，这些血的教训正在国 　　内的软件开发者身上发生。 　　近来，我遇到一个开发小组开发包括代码编辑器在内的一套内部使用的计算机辅助软件。不幸的是， 　　当他们开发完这个工具后，发现这个工具不能打印出源代码文件，使用者当然希望有这个功能。结果 　　这个小组只好手工抄写源代码文档以供代码检查。这说明那怕需求明确无误并构思准确，如果我们没 　　有编写文档，软件达不到期望目标也只能是咎由自取了。 　　相反的情况，我曾见一个要集成到“错误跟踪系统”中的简单界面写了一页需求说明。而操作系统系 　　统管理员在为处理脚本时发现简单的一张需求清单竟是如此有用。他们依据需求对系统进行测试时， 　　此系统不仅非常清晰地实现了所有必需功能，而且未发现任何错误。 　　事实上，需求文档在开发过程中一直起指导作用。

需求的类型

　　下面这些定义是需求工程领域中常见术语的定义。 　　软件需求包括三个不同的层次：业务需求、用户需求和功能需求（也包括非功能需求）。 　　1．业务需求（business requirement）反映了组织机构或客户对系统、产品高层次的目标要求，它们 　　在项目视图与范围文档中予以说明。 　　2．用户需求(user requirement) 文档描述了用户使用产品必须要完成的任务，这在使用实例（use 　　case）文档或方案脚本说明中予以说明。 　　3．功能需求(functional requirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的 　　任务，从而满足了业务需求。 　　在软件需求规格说明书（SRS）中说明的功能需求充分描述了软件系统所应具有的外部行为。软件 　　需求规格说明在开发、测试、质量保证、项目管理以及相关项目功能中都起了重要的作用。对一个大 　　型系统来说，软件功能需求也许只是系统需求的一个子集，因为另外一些可能属于子系统（或软件部 　　件）。 　　作为功能需求的补充，软件需求规格说明还应包括非功能需求，它描述了系统展现给用户的行为和 　　执行的操作等。它包括产品必须遵从的标准、规范和合约；外部界面的具体细节；性能要求；设计或 　　实现的约束条件及质量属性。所谓约束是指对开发人员在软件产品设计和构造上的限制。质量属性是 　　通过多种角度对产品的特点进行描述，从而反映产品功能。多角度描述产品对用户和开发人员都极为 　　重要。 　　下面以一个字处理程序为例来说明需求的不同种类。业务需求可能是：“用户能有效地纠正文档中 　　的拼写错误”，该产品的包装盒封面上可能会标明这是个满足业务需求的拼写检查器。而对应的用户 　　需求可能是“找出文档中的拼写错误并通过一个提供的替换项列表来供选择替换拼错的词”。同时，该 　　拼写检查器还有许多功能需求，如找到并高亮度提示错词的操作；显示提供替换词的对话框以及实现 　　整个文档范围的替换。 　　从以上定义可以发现，需求并未包括设计细节、实现细节、项目计划信息或测试信息。需求与这些 　　没有关系，它关注的是充分说明你究竟想开发什么。项目也有其它方面的需求，如开发环境需求或发 　　布产品及移植到支撑环境的需求。