系分考试准备的论文（1）论系统设计中对用户需求的把握

论系统设计中对用户需求的把握<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

摘要：

　　在系统分析与设计的过程中如何将用户需求正确的反映到系统中去，避免开发完成的系统却不是用户需要的软件成为系统分析人员的首要任务。本文将以我2004年在某自来水公司实施的水务综合管理系统为例，详细讨论了在系统分析过程中如何对用户的需求进行把握所采取的方法与措施。在需求分析中我主要做了如下工作：（1）、将与系统相关的用户进行分类以明确用户需求的来源及优先级；（2）、采用多种方式和途径获取用户的需求；（3）、利用Rational Rose创建的用例与用户进行沟通；（4）、在用户需求分析的过程中注意用户对系统的非功能性需求进行提取与处理。最后对收集的需求编写成用户需求规格说明（SRS）交由用户进行确认。通过上述措施准确的把握了用户需求并顺利完成系统的开发。同时也对需求分析过程中存在的一些不足之处进行了简要的总结。

正文：

本人所在的某市级自来水公司经过多年的信息化建设，已经形成了数个应用系统如客户用水工程系统、用水抄表计量系统、营业收费管理系统、欠费催收系统、生产调度系统及客户服务系统等。由于原系统都是由各部门或分公司为主导建设的，因业务需求的“局部性”及当时技术条件的限制导致系统之间很难共享信息，已经不再适应公司业务发展的需要。为此，公司领导经过研究决定于2004年利用自身技术力量重新开发设计一套水务综合管理系统，我作为技术部的负责人及主要技术骨干，主持并参与了系统的方案选型、系统分析、设计及部分开发工作。

在对水务系统进行开发设计之前，我对公司原来所用的几个应用系统进行了详细的调研后，发现原来系统因为建设过早或公司业务已经发生改变，目前都不同程度的存在不适应用户需求的情况，在关键业务的处理过程中也存在处理步骤繁琐、处理速度很慢等系统非功能性的一些问题。随着公司业务的发展用户也提出了许多新的需求，但因原系统不方便扩充也未能及时的得到满足。为此，如何准确的把握用户在新的业务环境下对系统提出的功能或非功能性需求，成为系统分析、设计工作中的头等大事，也直接影响着后期软件开发工作的进度及成果。在软件需求工程中对于用户需求的获取与把握属于需求的开发过程，接着我将就如何在软件需求分析中正确把握用户需求进行详细的讨论。

用户需求是对业务需求的细化，为了在用户需求分析阶段不会超出系统开发的范围，在业务分析的基础上我们建立了系统视图（范围）以规范用户需求分析的边界。对于水务系统范围的简要描述为：水务综合管理系统是为自来水公司日常经营管理服务的，提供对客户用水从报装工程施工、用水计量、费用结算直至客户不再用水整个过程中业务处理的集成管理环境。并对客户用户过程中单个或多个水表生命周期（从安装、检修、维护到报废拆表）进行全程管理，为企业领导管理决策及相关业务人员业务工作提供支持和服务，并对客户信息查询、报障提供及时的响应。确定系统视图后对于用户要求分析阶段的工作我们主要注意了以下几个方面的问题。

首先，将与系统相关的用户进行分类以明确用户需求的来源及优先级。对于像我司这种涉及企业所有业务的大型应用系统的开发来说，用户需求的调查对象多种多样涉及到不同的部门或人员，为此为了更方便的从用户处获取有效的需求，我们将用户分成不同的类如首先将其分为管理人员、业务人员、最终客户等，通过这种划分明确了需求的来源，在需求分析的理解出现不一致时可以有确定用户为系统分析人员提供“决策”。用户类不一定都指人也可以是其它应用程序接口或硬件组件，如在抄表计量业务流程的分析时，相关的业务人员要求系统能够简便一些，在经过系统分析人员进行详细的分析后发现是老系统对抄表机传输接口的处理不当造成的，通过对其进行记录后来在系统的设计中解决了此问题。

其次，采用多种方式和途径获取用户的需求。在需求分析的初期我要求系统分析人员要深入到用户的工作现场中以观察用户是如何工作的，从而正确的把握用户需求的实质。如在完成客户档案登记的业务中，原来系统只提供给数据组一个窗口进行录入操作，而通过系统分析人员对其实际工作的观察发现客户在报装时就已经形成了部分资料，对此发现我们在新系统中的工程报装模块出现的客户信息进行了提取，从而极大的提高了操作人员的工作效率。在需求分析中我也注意了多种沟通方式的利用，如果对于复杂的业务处理流程则采用用户与分析人员的小组会议进行正式的讨论，而对于最终客户的一些需求则采用电话或Email的方式与之联系。通过以上方式的采用极大的提高了用户需求分析的速度与质量。

再次，利用Rational Rose创建的用例与用户进行沟通。系统分析人员在开始阶段对用户需求的确认主要是通过需求文档与用户进行沟通的，在实际的需求分析过程中我发现用户并不能看懂系统分析文档，对于需求分析的准确性也就无法保证。为此我们及时采用了Rational Rose创建的用例（Use Case）来展现用户的业务处理过程，并使用用例文档对其进行简要的描述，这样用户就能够很好的理解系统能够帮助其完成的工作任务，一般通过两到三次的沟通就能够确定用户的需求，极大的提高了用户需求获取的质量与效率。同时也使用了传统的一些需求描述方式，如对于复杂的业务处理过程，我们就采用了判定树的方式进行描述。在用例文档的描述中我们汲取了前面的教训，使用通俗的语言进行表达以方便与用户进行沟通，如对于前置条件和后置条件我们就换成了前提条件及处理结果，避免了用户理解冗长而晦涩的专业用语，有利于与用户进行沟通并可简单明了的表达用户使用系统所要完成的任务。

最后，在用户需求分析的过程中注意用户对系统的非功能性需求进行提取与处理。在系统需求分析的过程中用户往往不会对系统的非功能性需求，如可操作性、界面的简便性及系统性能提出明确的要求，而这也往往是系统分析人员容易忽略的一个方面。为此，在系统分析的过程中我要求系统分析人员注意用户描述中的“简单”、“快一些”等词语的分析。如在了解处理客户扣款银行文件时用户抱怨系统处理不方便，而且在处理时其它业务都得停下来等。分析人员在知识这个情况时及时了解到系统在处理此业务时采用了独占的方式访问数据库，而且由于每次需求处理的记录都上万条，所以造成了以上情况。为此用户需求中的一些隐性的非功能性需求也得到了很好的处理，对于后期的系统设计有很好的帮助作用。

    需求分析阶段的成果是用户需求规格说明（ SRS ），完成 SRS 后再用户代表进行沟通确定以为系统的设计开发工作设定一条基线。通过综合采用如上所述的方法，在用户需求分析的过程中系统分析人员很好的把握了用户的需求，使得需求获取的效率与质量都有明显的提高，为系统的设计工作奠定了良好的基础。总的来说我们的需求分析工作是成功的，在系统设计开发阶段没有出现因需求不完全而停工的情况，系统已于 2004 年底顺利完成并能够较好的满足用户的要求，得到了公司领导及同事的认可。同时，在用户需求的把握上也存在一些不足之处，（ 1 ）、系统分析人员对于 Rational Rose 的使用不是很熟练导致需求开发的速度有所降低；（ 2 ）、在用户需求与分析人员的理解存在冲突时过份迁就用户而使部分需求用例开发的质量不高。

转载于:https://www.cnblogs.com/JackyXu/archive/2006/01/19/320084.html