论系统设计中对用户需求的把握

摘要：

用户需求是系统设计中很重要的一部分，获取用户的需求并把它正确的反映到系统的需求规格说明书是一项富有挑战性的任务。本文通过我参与的某市发改局的公共信用信息大数据系统的开发，详细说明了我是如何把用户需求反映到需求规格说明书中。

我们根据面向对象的开发思想对需求规格说明书的格式做了一些调整，体现了用例驱动的特性。在该说明书中，我们适当地使用图形描述工具，并将图形与文字进行合理编排，其中使用了用例图、上下文范围图、活动图和业务类图。同时，采用快速原型的思想与用户进行沟通，并在说明书中加入了必要的系统界面原型图。这些沟通方法与工具大都比较成功，特别是利用用例图和界面原型的沟通效果良好，业务类图的使用效果不太理想。我们发现，要想需求规格说明书取得良好效果，针对不同的阅读对象做出调整是必要的。

正文：

2017年6月，我参与了某市发改局公共信用信息大数据系统的开发，项目组成员共34人，在项目中，我作为系统分析员，主要负责系统分析与系统设计方面的工作。项目历时6个月，于2018年1月正式上线。

该市各委办局信息系统建设参差不齐，部分委办局甚至没有信息系统，市发改局作为建设单位，根据社会信用体系规划建设要求，建设市信用信息共享平台一体化和市信用门户网站一体化，实现信用信息共享共用，提升信用产品和信用服务应用水平。

公共信用信息大数据系统是一个基于公共信用信息建立起来的系统，利用现有电子政务网和省政务信息资源数据共享交换平台，征集该市机关、企事业单位公共信用信息，构建一个目录体系、两个数据处理系统、三个应用服务系统即两个门户网站、四个公共信用信息数据库组成的一个平台。子系统包含信用门户网、信用政务系统、大数据应用系统、API管理系统、中小微管理系统、商事主体网、数据汇聚系统；另外还需要和省、国家进行数据对接。

IPO图是传统需求规格说明书使用的工具或方法，即对每个模块进行详细设计的工具，包括数据输入、数据输出和数据加工三个主要内容。IPO图对过程的描述完整、清晰、简洁、准确，但单单使用IPO图会使需求分析存在较大的风险，一是此描述可能不够深入，未真正挖掘出用户的需求；二是设计无法真正体现出需求。使用UML图形工具可以很大程度上解决上述问题，但也带来了与用户沟通的问题。我们在进行核心的业务管理系统开发时，通过有选择地使用并简化图形，甚至对一些图形做出必要的调整，再辅以简要的文字说明，使用户理解我们的需求描述。同时，使用Axure RP画出各个系统的界面原型，就系统操作流程及相关界面关键元素与用户进行深入的交流，很好地完成了与客户的沟通任务。

1. 在需求说明书加入UML相关图形

在系统分析过程中，我们通过用例确定系统范围，获取用户需求，随着分析的深入和用户交流的反馈，需求逐步明确，用户得到分解和细化。在此过程中，产生了用例图、顺序图、活动图等UML图形，同时还有对于用例图的用例的详细说明，即用例规约。接下来的问题是如何准确反映我们所获取的用户需求，即既要求准确反映，又要用户能看明白，特别是能引导用户进行思考，从而发现描述不准确甚至是遗漏的需求。

我们对传统的需求规格说明书的格式进行了调整，加入了相关用例分析的图形元素。整个需求规格说明包括项目概述、系统需求说明、系统设计约束、附件及说明等四大部分。项目概述描述项目背景、目标之类项目相关的一些基本情况，并特别地加入规格说明书中所用到的图形工具的简要介绍以及图形符号的说明。系统设计规约主要内容是界面设计要求、性能要求以及安全等方面的要求。在附件及说明中，我们列出了本系统所涉及的相关法律法规及文件列表，系统所使用的报告模板、数据上报模板、数据查询模板等。

系统需求说明是需求规格说明书最主要的部分，包括系统范围、详细的功能需求和数据需求三部分。对于系统范围的描述，我们使用了上下文范围图。该图把整个待开发系统看做一个黑盒子，并在图中画出与此系统进行交互的用户和其他的软硬件系统，来理清系统的边界和范围。该图是使用Visio工具画的，后面其他UML图形也都是用Visio工具绘制。用户包括信用办管理员、局办管理员、局办使用者。外界系统包括省和国家双公示系统、省政务信息资源数据共享交互平台。数据需求描述我们使用了业务类图，主要参照类图的画法，但不涉及属性和方法，只描述有哪些主要的业务类及其之间的关系。

详细的功能需求描述我们使用了用例图和活动图。我们先是根据上下文范围图分解系统，然后对各系统的功能模块绘制用例图。用例图只涉及两种符号：角色和用例，用户很容易直观看出该子系统有那些功能模块，后面再进一步完善了用例之间的关系。对于较为复杂的业务功能，我们使用了活动图，比如双公示管理用例中，涉及到的参与者主要有信用办管理员、局办管理员。局办管理员对本部门的双公示信息进行上传；当数据未提交时，可以对数据的状态和更新时间进行修改或删除；可以对数据进行公示申请，如果行政相对人是自然人则不公示，不需要经过信用办管理员；如果是法人，公示申请需要信用办管理员公示；局办管理员对已公示数据想不公示，则可以进行撤下申请，由信用办管理员审批，可以同意撤下，撤下后该数据在门户网站不可见；也可以驳回撤下；信用办管理员可以将未推送数据推送到省和国家系统。该活动图清晰地描述了整个过程的逻辑关系，通过图形的形式用户更容易接受。

2. 利用系统界面原型

我们使用Axure RP绘制各个系统的界面原型，原型包括整个界面的构成、界面的交互效果、界面的元素、颜色与布局等，并可以通过浏览器进行操作，交由用户试用。利用该界面原型，用户可以直观地知道我们将要开发的系统是什么样，是不是自己想要实现的效果，引导用户思考并提出反馈意见。除了界面原型，还会针对界面原型上的元素以表格的形式进行元素说明，包括元素名称、说明、备注，相当于对原型的文字说明。

这样，我们通过相关的图形工具，特别是活动图和界面原型，与用户进行了充分而深入的交流，准确地获取用户的需求并如实地反映到需求规格说明书中。其中，我们认为界面原型在于用户的沟通过程起着重要的作用。通过Axure RP工具，可以快速地将界面原型绘制出来，一开始需求比较模糊的时候，原型比较粗糙，因为该市以前没建设过信用系统，用户自己对需求的理解只能是参考其它城市的做法，通过反复的沟通，逐步将原型细化。比如该系统包含了很多业务处理功能，红黑名单数据上报、异议申诉、信用发布、双公示管理、失信被执行人、线上承诺等，用户就提出了一些更好的建议，像事项这么多，需要一个一个点进去看才知道需要处理，如果有一个待办事项功能，所有的待办事项都在这里提醒和处理，那就方便很多。这个是我们一开始设计没想到了，用户看到界面原型后提出来的建议。

采用以上方法取得了很好的效果，用户期望都很清晰地表达出来，与此同时还提出了一些用户以前没有想到的功能，减少了以后需求变更的概率。但也有不足的地方，在与用户的交流中发现用户基本上不看业务类图，虽然我们已经把该图简化了，但由于用户对于业务类图这种图形描述方式不是很熟悉，而且比较抽象，不想业务功能描述直观，所以用户对此关注比较少。因此，如何才能更好地对数据需求进行描述，还需我们更进一步思考，以及在今后的项目中不断总结。同时我们也发现，要求用户像开发人员一样了解各种需求分析方法和工具是不现实的，需求规格说明需要针对不同的阅读对象，包括用户和开发人员、测试人员，做出不同的调整，使其发挥最佳的作用。