本文主要是介绍十三、我们应当怎样做需求分析：查询报表分析，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
在我以往的用例分析中，使用这样格式的用例模式，对于大多数业务操作流程来说是得心应手的，但对于有些功能来说总感觉不对劲。感觉不对劲的，就是那些查询、汇总与报表功能。对于这部分功能，需要我们描述的不是什么操作流程，而更重要的是那些数据项、数据来源、报表格式、数据链接，以及使用者、使用频率的说明。而这些，在以往的用例说明格式中统统都没有，怎么办呢？俗话说“东西是死的人是活的”，把我们的用例格式改改吧。
这是我设计的查询报表类用例的格式，同时还可以在后面配上报表的格式。你也可以根据需要设计你自己的格式，用例不是什么阳春白雪的高级玩意儿，而是沟通你、用户、开发设计人员的桥梁。该说明的都说到了，该分析的都分析了，大家都能看明白，并以此为根据去完成各自的工作，这才是用例说明的实质，其它神马都是浮云。
报表作用：就是描述参与者使用这个报表做什么。如果有多个参与者，每一个都应当描述。
报表内容：用简短的话描述一下。
输出列：罗列报表的输出列，如果需要的话，还应对输出列进行说明，或描述它的数据来源。
使用频率：参与者使用它的频率，便于设计者考虑报表的查询效率。
数据链接：哪些数据项有链接，链接到什么报表，或显示什么数据。
最后依然是那个需求列表，便于业务需求的跟踪。
查询报表的需求分析与一般的业务操作的需求分析存在着巨大的差异。而许多需求分析人员没有认识到这一点，这往往导致对查询报表的分析不到位，为项目的研发带来风险，因此在这里我们认真探讨一下。
一个有效的报表，往往不是对数字的简单堆砌，它通过一组一组的数据，揭示的都是一些客观规律、复杂活动与发展趋势。客户方的领导，特别是那些中层和高层领导，通过对这些报表的阅读，就可以掌握他们的工作进程、加强他们的人员管理、发现他们的管理漏洞、指导他们的战略决策。总之一句话，每个报表都有他们的设计意图。
比如说，一份工作月报，领导希望看到的，是按时间、按项目、按部门统计的各项工作的进展情况，以及有哪些异常情况，以便领导监控各项工作能够顺利完成；一份销售报表，领导希望看到的，是按产品、按区域、按顾客类型统计的各项产品的销售情况，以便领导制订销售计划与各种营销战略。没有弄清楚一个报表的真实意图，就不算真正理解了这个报表的业务需求。
同时，报表的数据项应当都是来源与系统中各项操作的结果数据。许多业务系统的操作流程都是纷繁复杂的，其中还包括各种情况。更复杂的，一些商业智能与分析决策系统，报表所需的各种数据，甚至来源与各种各样的外部系统。分析一个报表的数据来源，就是在梳理各种业务流、数据流，以及各种数据间的关系。如果这方面的分析不到位，最终设计出来的报表往往是不准确的。
另外，用户使用报表的频率，常常决定了报表设计的方式。如果报表中的数据总是在实时变化，并且用户总是在密切关注这些数据的变化，那么报表必须设计成实时查询的；如果用户并不是十分关注数据的实时变化，并且总是以天（或者月，或者年）来查看报表，则报表可以设计成按天（或者月，或者年）来预运算统计数字，使得报表查询效率显著提高，可以保证更多的并发访问。
最后，一个报表的核心就是展现给客户的报表格式，以及报表与报表间的各种链接。需求人员在进行需求分析阶段，应当准确地与客户敲定这些格式，并最终在用例说明中体现出来。报表格式是否体现客户的意图，报表数据项是否都能在系统中取到，数据间的逻辑关系是否正确，报表格式是否技术可行，都是需求分析人员在前期就必须要分析到位的内容。否则，报表是项目后期可能出现频繁需求变更的重灾区。
所有这些分析，都体现在了我提供给大家的用例说明格式中。报表作用体现的是报表对于不同用户的真实意图；输出列体现的是对各个数据项及其数据来源的说明；假设与约束罗列的是报表中各个数据项的运算公式、数据规则与约束；还有使用频率、数据链接、非功能需求，以及最后的界面原型，等等。只要我们把这些都分析到了，我们的查询报表就分析到位了。
这篇关于十三、我们应当怎样做需求分析：查询报表分析的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
