关于软件工程系统需求的分析探讨.doc
关于软件工程系统需求的分析探讨 [摘 要 ] 对软件开发中的需求变更的产生原因及对项目的影响做了分析和讨论 ,介绍和研究了不同方法学中对于需求变更管理的要求和处理过程 ,并对这些主流的方法学中的变更管理过程做了一些总结和比较。 [关键词 ]软件工程 需求分析 系统分析 软件工程 (Software Engineering,简称为 SE)是一门研究用工程化方法构建和维护有效的、实用的和高质量的软件的学科。它涉及到程序设计语言 ,数据库 ,软件开发工具 ,系统平台 ,标准 ,设计模式等方面。在现代社会中 ,软件应用于多个方面。典型的软件比如有电子邮件 ,嵌入式系统 ,人机界面 ,办公套件 ,操作系统 ,编译器 ,数据库 ,游戏等。同时 ,各个行业几乎都有计算机软件的应用 ,比如工业 ,农业 ,银行 ,航空 ,政府部门等。这些应用促进了经济和社会的发展 ,使得人们的工作更加高效 ,同时提高了生活质量。 一、软件工 程系统需求分析 需求分析包括提炼、分析和仔细审查已收集到的需求 ,以确保所有的风险承担者都明白其含义并找出其中的错误、遗漏或其它不足的地方。分析员通过评价来确定是否所有的需求和软件需求规格说明都达到了优秀需求说明的要求。分析的目的在于开发出高质量的需求 ,这样就能做出实用的项目估算并可以进行设计、构造和测试。通常 ,把需求中的一部分用多种形式来描述 ,如同时用文本和图形来描述。分析这些不同的视图将揭示出一些更深的问题 ,这是单一视图无法提供的。分析还包括与客户的交流以澄清某些混淆 ,并明确哪些需求是更为重要的。其目的是确保所有风险承担者尽早地对项目达成共识并对将来的产品有个相同而清晰的认识。 二、软件开发工程中需求分析的重要性 作为一个整体工程 ,软件生命周期的各个时期和阶段是无法区分重要性的大小。在这里 ,针对上述一些错误观念 ,只想阐述一下软件开发工程中需求分析的重要性。软件需求是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。通过对应问题及其环境的理解与分析 ,为问题涉及的信息、功能及系统行为建立模型 ,将用户需求精确化、完全化 ,最终形成需求规格说明 ,这一系列的活动即构成软件开发生命周期的需求分析阶 段。其在整个软件开发过程中的重要性主要表现在以下 3 点 : 1. 需求分析是获得用户需求的有效途径 开发软件是为用户服务的。为了开发出真正满足用户需求的软件产品 .首先必须知道用户的需求。对软件需求的深入理解是软件开发工作获得成功的前提条件 ,不论软件开发工作者把设计和编码工作做得如何出色 .不能真正满足用户需求的程序只能是偏离软件开发的正确方向 ,只会使用户失望 ,给开发者带来烦恼。 2. 需求分析是决定项目成功的关键因素 需求分析是一个项目的开端 ,也是项目建设的基石。在以往的建设失败的项目中 80%的是 由于需求分析的不明确而造成的。因此一个项目成功的关键因素之一 ,就是对需求分析的把握程度 ,项目的整体风险具体就表现在需求分析不明确、业务流程不合理上 ,用户不习惯或者不愿意去用承建方的软件 ,或者很难去用 ,从而造成了项目失败。 3. 需求分析是系统分析和软件设计的桥梁 需求分析过程是确定顾客需求的过程。而一个项目的软件工程师与他们的顾客往往使用不同的词汇 :顾客知道自己的需要 ,却不懂得如何用计算机技术实现 ;而软件设计人员和程序员往往缺乏理解实际事物的运行过程和商业过程的技巧。那么使用通过专门训练的专业的作业 或系统分析员 ,就填补了商业和电脑世界之间的鸿沟。他们从持有关键信息的用户获得可用的信息 ,并把这些用户信息转化为清晰的和完整的形式。这些能被软件工程师理解的形式就是他们进行下一阶段系统设计的依据。 三、需求处理效率分析 影响需求分析的因素有很多 ,比如客户不清楚需求 ;需求自身经常变动 ;分析人员或客户理解有误等等。 MIS 的系统需求处理效率 ,直接关系到开发人员能否在规定时间内完成开发任务 ,新的需求产生 ,需求人员及时有效的分析新需求 ,编写一份清晰、准确的需求文档 ,避免留下模糊不清的需求 ,否则 ,就只好靠开发人员 去猜测这些模糊不清的需求 ,而往往开发出来的功能不符合业务需求 ,这样既耽误时间 ,又增加开发人员与业务人员之前的误导 ,互相埋怨。同时其很大程度上影响信息部门的部门形象及与业务单位的互动关系 ,从以下两个方面来探讨下需求处理效率 : 首先是业务分析。业务分析的效率首先取决于对业务流程的理解能力 ,所以应跟业务人员多沟通 ,更好地了解客户的业务 ,才能使产品更好地满足需要 ,这将有助于开发人员设计出真正满足客户需求并达到期望的优秀软件。优秀的需求人员可以提出比业务单位更好的需求 ,或者主动发掘需求。有时效率还取决于需求人员与 业务人员的亲合度与信任度 ,需求单上做的是台面文章 ,背后可能隐藏着重要的讯息 ,能否挖掘出这些潜在资讯 ,并与显性资讯有效整合 ,很可能影响我们是否做了正确的事情。通常客户所说的“需求”已经是一种实际可行的实施方案 ,分析人员应尽力从这些解决方法中了解真正的业务需求 ,同时还应找出已有系统与当前业务不符之处 ,以确保产品不会无效或低效 ;在彻底弄清业务领域内的事情后 ,分析人员就能提出相当好的改进方法 ,有经验且有创造力的分析人员还能提出增加一些用户没有发现的很有价值的系统特性。 其次是系统分析。取决于对系统架构与逻辑的整 体了解程度 ;特别突出“整体”二字 ,是因为“头痛医头 ,脚痛医脚”的做法 ,是用短期的高效率换长期的负效率的笨方法。而往往现在的后期维护 MIS 都是采用这样的方法 ,哪个功能出现问题 ,临时修改功能 ,只是保证此处功能在 MIS 平台正常运作 ,而忽略了平台中相关功能之前的关联性 ,往往会出现这样的问题 ,一个功能中的问题解决了 ,而在其他功能中出现类似的问题 ,或是因为修改此功能导致其他功能不可用的情况。