需求分析

为什么需要数据仓库？ 传统的数据库中，存放的数据都是一些定制性数据较多，表是二维的，一张表可以有很多字段，字段一字排开，对应的数据就一行一行写入表中，特点就是利用二维表表现多维关系。 但这种表现关系的上限和下限就定死了，比如QQ的用户信息，直接通过查询info表，对应的username、introduce等信息即可，而此时我想知道这个用户在哪个时间段购买了什么？修改信息的次数？诸如此类的指标时，就要重新设计数据库的表结构，因此无法满足我们的分析需求。 在产品脑图中可以很清晰的看到根据业务需求设计所需的字段，因此也导致 数据库是根据业务需求进行设计 。 那么有的会问，为什么一开始就不考虑好这个扩展性呢？为什么数据库一开始就不以数据仓库的形式设计？ 首先数据仓库，从字面上理解就可以感受到这是一个很大的空间，而且存储的物品很杂，里面会存放酱油、沐浴露、洗发精等物品，而数据库是存放酱油、盐等厨房用品，洗浴又是一个数据库。 另外一个就是，国内互联网的发展，一开始大家都是做个软件出来，大家一起用，这个时候只要满足的了需求即可，现今不止是需求还有用户的体验等各种方面，需要根据这些分析指标做调整。 小结： 数据库是跟业务挂钩的，而数据库不可能装下一个公司的所有数据，因此数据库的设计通常是针对一个应用进行设计的。 数据仓库是依照分析需求、分析维度、分析指标进行设计的。 什么是数据仓库？ 数据仓库

完成工作：优化了原型设计的界面，在考虑需求分析后对原型增加了新的内容。网上查阅了开发小程序的相关教程。 明日计划：准备在课堂上介绍团队的原型设计与需求分析。之后继续学习使用软件开发小程序。 小结：今天打开微信小程序开发工具感觉两眼一抹黑，不知道怎么使用，查阅了网络上的教程后对软件的功能界面有了了解，能够使用一些基本功能。 来源： https://www.cnblogs.com/emiya471/p/11396778.html

今天完成的工作： 将需求分析整理完成，下图是需求分析部分文字，至此本周任务已完成。完成前后端的分工。下载完成微信开发者工具，并了解了基本功能。在微信开放文档中了解了如交互、导航栏等之后可能会用到的微信 API 。在 CSDN 上初步学习使用 java 、 spring 与 mysql 搭建本地的服务器。 明日计划： 开始搭建数据库，着手 API 接口的设计。熟悉 sprinboot 的功能作用，尽快完成服务器的搭建。 小结： 在各种软件给开发工作带来便捷的同时，也更加意识到了 idea 的重要性。在集体学习中共同进步，优秀的同学很多，虽然难以望其项背，但也是对自己的警醒和鼓舞。 来源： https://www.cnblogs.com/Askia/p/11396695.html

今日完成： 完善需求分析，基本上做好了用户端的需求分析， 在墨刀上进行原型设计，选取了模板，在模板上加以修改，能够更快地进行原型设计 明日计划： 继续完善需求分析，做好商家端的需求分析， 完成初步原型设计 个人小结; 需求分析也是比较麻烦的一部分，需要考虑到很多细节， 本来打算加上定位，后来考虑到学校食堂，用户多为学生和教师，地点也主要分布在校园和宿舍内，所以直接填写收货地址更为方便。 商家端的需求分析更为困难，需要设计接触比较少的商家端运行模式， 时间紧迫，加油。 来源： https://www.cnblogs.com/ysjzyy/p/11391120.html

1.今天完成：MockingBot企业版中创建项目，将小组成员加入同一项目中；开始参照墨刀中的产品需求模板写需求分析；用ProcessOn完成思维导图，对产品需求有进一步的认识。 2.明日计划：需求分析文档完善，写完功能介绍和产品逻辑，开始原型设计。有时间的话看看关于微信小程序开发的文档和网课。 来源： https://www.cnblogs.com/Jane165/p/11385428.html

今天完成的工作：共同完成绘制产品框架图，初步学习了墨刀工具，开始撰写需求分析，逐步完成产品概述和功能介绍。 明日计划：继续完善需求分析，计划于明天绘制流程图，为后续工作做准备，并使用墨刀进行原型设计，完成界面的初步设计。 小结：进行了初步的讨论和对工具的熟悉，但是对微信小程序的开发流程仍然比较陌生。在需求分析的基础上，也应逐步着手对开发流程的了解，也是为之后的分析夯实基础。借助产品研发结构图，绘制研发流程图，以便更好的理清思路。同时不断学习JavaScript和Java，以克服日后可能在开发方面遇到的问题。 来源： https://www.cnblogs.com/Askia/p/11385389.html

当天完成的工作： 与组员一起共同完成绘制产品框架图，初步学习了墨刀工具，开始撰写需求分析，逐步完成产品概述和功能介绍。 第二天的计划： 继续完善需求分析，我们计划于明天绘制流程图，为后续工作做准备。使用墨刀进行原型设计。 每日小结： 我们今天进行了初步的工作，发现我们对小程序的制作流程仍然很陌生。我认为流程图能让我们理清开发思路，因此我们需要尽快了解所需知识，绘制流程图。我们了解到开发过程中前端会用到JavaScript，后端会使用Java。由于我们对JavaScript和Java不够熟悉，也需在着手编写小程序之前进行深入的学习。 来源： https://www.cnblogs.com/yvonnewang/p/11385150.html

一、什么是需求分析呢？ 　　软件 需求分析 就是把软件计划期间建立的 软件可行性分析 求精和细化，分析各种可能的解法，并且分配给各个软件元素。需求分析是软件定义阶段中的最后一步，是确定系统必须完成哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求。 通俗的讲，对用户的意图不断揭示和确认的过程，要对经过系统可行性分析所确定的系统目标做更为详细的描述。 下面举个栗子： 假如你是个软件工程师，夏天到了，有位客户跟你说要给他们的家禽养殖场开发一个温感控制系统，这个时候要需要与客户沟通，来确定客户到底想要一个什么样子的温感控制系统。我们应该注意三点： 1 . 准确的理解和描述客户需要的功能。 客户说，我的温感系统系统可以感知当前天气温度，当温度过高时，采取洒水模式给环境降温，当天气太潮湿，可以开启除湿模式....客户滔滔不绝的讲了一大堆，你也都非常忠实的按照自己的理解再一一的向客户描述一遍，以便于确认客户的需求是否正确。 2 . 帮助客户挖掘需求。 等客户把自己的需求说完了，你发现客户没有跟你说该养殖场的规模是多大的，是在露天的环境下还是在室内的，于是，你向客户提议说：“你看，咱们这个养殖场的规模是多大的，是在室内呢还是在室外，我们应该怎么样设计监控范围呢？”，客户连连的拍着脑门说，我差点给忘记了，我们这个养殖场是室内的，有两层，一层有500平左右。 3 . 分析客户需求的可行性

郑昀 创建于2016/3/30 最后更新于2016/4/8 关键词：技术预研课题，平台设计，应用场景，故事，信息架构，业务流程，数据流程 本文档适用人员：全体研发 提纲： 如何从零开始搭建一个技术平台？ 应用场景其实就是我们的愿景 从应用场景推导出故事 从故事推导出信息架构和业务流程 一，如何从零开始？ 如果让你把下面这套技术体系串联起来，从零开始构建一个技术平台，你如何做需求分析呢，在没有产品经理帮助你梳理的情况下？ 下面这些系统涵盖了我们研发测试运维日常工作的方方面面： idCenter ：它定义用户、用户组、权限。研发测试都有了唯一的身份和权限集合，贯穿所有系统。 iDB ：数据库自动化运维系统能把数据库建帐号、授予权限、建表、改表结构、刷库这些日常操作都变成流程， DBA审核通过后就可以自动执行，以及自动回滚。 Touchstone ：容器私有云的管理控制台，管理镜像库、应用、容器、主机等。日常发布就在这里做。 JobCenter ：定时任务调度和管理。 Summoner ：大型计算任务的调度和管理。云纵佣金计算就是在这上面跑的。 Notify ：异步消息可靠推送。所有的异步消息都走这个中间件。 Discache ：管理 memcached和 redis。 OAP ：运维自动化系统。主要是资产管理、资源管理和发布。 Secret ：天机和鹰眼。数据库、 Java、 PHP

毫无疑问, 任何企业信息化项目启动的源头来自于系统业务需求调研，业务需求调研在软件工程价值链中处于首当其冲的位置,做好业务需求调研对于项目成败的重要性是不言而喻的。而如何做好业务需求调研却又不是件容易的事，因为它既是门科学更是门艺术，更需要长期的经验积累。 业务需求调研的方法多样，通常包括复查原有的表格和描述、主持与用户的业务访谈、原型建立、分发收集调查表、研究供应商的解决方案等方法。 而其中的业务需求访谈是一门被证明形之有效的技术和方法，然而怎样做好它，对有效的获得和分析业务需求均起着至关重要的作用。我们应当像重视软件开发过程那样关注管理业务访谈的过程和法则,做到“访谈前有准备,访谈时有效果,访谈后有总结”。如此一来,我们的需求访谈工作才能进入良性循环,我们的软件开发才能有保障。 正如人类发展历史蕴含着隐含的潜规则，业务需求访谈亦有其内在的法则所在，本文旨在挖掘这些规则以期同仁在业务需求访谈工作中有所参照和收获。 1、业务需求访谈前要从内容和目标上做好精心准备。 我们知道系统需求是新系统必须完成的功能和局限性。系统需求肯定不是生来就有的，也不是天生就存在需求分析员的脑海中，那么业务需要又在哪里呢？它存在于业务人员的脑海里,它存在与企业实践运作体系中。或者说它们并不一定存在，需求分析员的职责就在于通过包括业务需求访谈在内的各种方法使系统需求得以显示它清晰的本来面目。