对软件需求分析的认识

对软件需求分析的认识自从学习了软件工程这门课程之后，我对软件及其开发有了更加浓厚的兴趣，同时我也认识到软件工程在软件开发中的重要性。目前国内软件在开发中还没有对软件开发的过程进行明确规定，文档不完整，也不规范，软件项目的成功往往归功于软件开发组的一些杰出个人或小组的努力。这种依赖于个别人员上的成功并不能为全组织的软件生产率和质量的提高奠定有效的基础，只有通过建立全过程的改善，采用严格的软件工程方法和管理，并且坚持不懈地付诸实践，才能取得全组织的软件过程能力的不断提高，使软件开发更规范合理。软件工程理论认为，在软件生命周期中，需求分析（RequirementsAnalysis）是最重要的一个阶段。软件需求分析的质量对软件开发的影响是深远的、全局性的，高质量需求对软件开发往往起到事半功倍的效果，所谓“磨刀不误砍柴功”。在后续阶段改正需求分析阶段产生的错误将付出高昂的代价。而对于软件需求分析，简单的来说就是要决定“做什么，不做什么，达到用户所期望的效果”，就好比我们自己平常做一件事之前，都会有做好计划，软件开发亦不例外。用软件工程的定义来讲，它就是深入描述软件的功能和性能，确定软件设计的限制和软件同其它系统元素的接口细节，定义软件的其它有效性需求。下面是一些有关需求分析的有关知识：一、现在很多管理类文档将需求分为合理需求和不合理需求两种类型，这种分类方式本身并没有错误，但在实际判断起来却很难，主要是无法清晰的界定合理和不合理的属性，用户和研发人员的出发点是不一样的，每个研发人员也都有各自的认识，很难确定合理与不合理的标准。因此将需求按重要程度进行分级，是必不可少的步骤。需求分类好了，自然就可以在以重要需求为出发点，兼顾次要需求的基础上来进行设计。在开发者与用户（代表）交流时，切记避免使用如“大概”、“应该”、“可能”等词语，这是初入行者和懒于写文档的人都容易出现这种问题，但结果是，概括性的语言无限放大了大家对需求的理解，造成歧义。所以，需求越具体、详细就越好，磨刀不误砍柴功。二、需求分析是分多阶段的，理想的流程是需求交流—〉分析整理—〉需求确认—〉变更控制（用户追加或补充的需求内容才能称为需求变更），实际情况下该流程会多次循环往复，在这个过程当中，变更控制显得异常重要，它既是原需求的终止，又是新需求的开始，做好变更控制，往往事半功倍。因此，需求变更贯穿了需求说明书经过论证之后的所有软件管理过程。同时需求变更需要有专门的人员记录，这个人最好是项目组内部的人员，记录内容包括需求变更具体内容、发生于哪个阶段、以及由谁提出的等内容。项目经理需要每天关注需求变更记录，每周必须对需求变更产生的影响进行预估，并将预估结果记入到需求变更记录当中，以便于确定今后的工作计划。还有三、分析员占有的位置分析员通过需求分析，逐步细化对软件的要求，描述软件要处理的数据域，并给软件开发提供一种可转化为数据设计、结构设计和过程设计的数据和功能表示。在软件完成后，制定的软件规格说明还要为评价软件质量提供依据。四、任务开发软件系统最为困难的部分就是准确说明开发什么。最为困难的概念性工作便是编写出详细技术需求，这包括所有面向用户、面向机器和其它软件系统的接口。同时这也是一旦做错，将最终会给系统带来极大损害的部分，并且以后再对它进行修改也极为困难。目前，国内产品的庞杂，一家企业可能有几个系统并立运行，它们之间接口是系统开发人员最头痛的问题。对于商业最终用户应用程序，企业信息系统和软件作为一个大系统的一部分的产品是显而易见的。但是对于我们开发人员来说，并没有编写出客户认可的需求文档，我们如何知道项目于何时结束？而如果我们不知道什么对客户来说是重要的，那我们又如何能使客户感到满意呢？然而，即便并非出于商业目的的软件需求也是必须的。例如库、组件和工具这些供开发小组内部使用的软件。当然你可能偶尔勿需文档说明就能与其他人意见较为一致，但更常见的是出现重复返工这种不可避免的后果，而重新编制代码的代价远远超过重写一份需求文档的代价，这些血的教训正在国内的软件开发者身上发生。近来，我遇到一个开发小组开发包括代码编辑器在内的一套内部使用的计算机辅助软件。不幸的是，当他们开发完这个工具后，发现这个工具不能打印出源代码文件，使用者当然希望有这个功能。结果这个小组只好手工抄写源代码文档以供代码检查。这说明那怕需求明确无误并构思准确，如果我们没有编写文档，软件达不到期望目标也只能是咎由自取了。相反的情况，我曾见一个要集成到“错误跟踪系统”中的简单界面写了一页需求说明。而操作系统系统管理员在为处理脚本时发现简单的一张需求清单竟是如此有用。他们依据需求对系统进行测试时，此系统不仅非常清晰地实现了所有必需功能，而且未发现任何错误。事实上，需求文档在开发过程中一直起指导作用。五、软件需求分析-需求的类型下面这些定义是需求工程领域中常见术语的定义。软件需求包括三个不同的层次：业务需求、用户需求和功能需求（也包括非功能需求）。1．业务需求（businessrequirement）反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。2．用户需求(userrequirement)文档描述了用户使用产品必须要完成的任务，这在使用实例（usecase）文档或方案脚本说明中予以说明。3．功能需求(functionalrequirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。在软件需求规格说明书（SRS）中说明的功能需求充分描述了软件系统所应具有的外部行为，软件需求规格说明是软件需求的最终产物，它在后续的开发、测试、质量保证、项目管理以及相关项目功能中都起了重要的作用。对一个大型系统来说，软件功能需求也许只是系统需求的一个子集，因为另外一些可能属于子系统（或软件部件）。作为功能需求的补充，软件需求规格说明还应包括非功能需求，它描述了系统展现给用户的行为和执行的操作等。它包括产品必须遵从的标准、规范和合约；外部界面的具体细节；性能要求；设计或实现的约束条件及质量属性。所谓约束是指对开发人员在软件产品设计和构造上的限制。质量属性是通过多种角度对产品的特点进行描述，从而反映产品功能。多角度描述产品对用户和开发人员都极为重要。下面以一个字处理程序为例来说明需求的不同种类。业务需求可能是：“用户能有效地纠正文档中的拼写错误”，该产品的包装盒封面上可能会标明这是个满足业务需求的拼写检查器。而对应的用户需求可能是“找出文档中的拼写错误并通过一个提供的替换项列表来供选择替换拼错的词”。同时，该拼写检查器还有许多功能需求，如找到并高亮度提示错词的操作；显示提供替换词的对话框以及实现整个文档范围的替换。从以上定义可以发现，需求并未包括设计细节、实现细节、项目计划信息或测试信息。需求与这些没有关系，它关注的是充分说明你究竟想开发什么。故而，软件需求分析是软件工程不可或缺的一个步骤，因为这是你成功的必经之道。