用户需求分析

需求分析心得体会 1、需求分析的必要性 　　 需求分析是软件计划阶段的重要活动，也是软件生存周期中的一个重要环节，该阶段是分析系统在功能上需要“实现什么”，而不是考虑如何去“实现”。需求分析的目标是把用户对待开发软件提出的“要求”或“需要”进行分析与整理，确认后形成描述完整、清晰与规范的文档，确定软件需要实现哪些功能，完成哪些工作。此外，软件的一些非功能性需求(如软件性能、可靠性、响应时间、可扩展性等)，软件设计的约束条件，运行时与其他软件的关系等也是软件需求分析的目标。通俗来讲就是我们需要通过需求分析确定用户想要什么，需要什么，我们做些什么才能又准确又高效完成用户的要求。同时，需求分析的目标是把用户对待开发软件提出的“要求”或“需要”进行分析与整理，多次与用户沟通确认后，形成描述完整、清晰与规范的文档，确定软件需要实现哪些功能，完成哪些工作。需求分析人员需要对用户的需求有非常深刻的理解。也就是说能和用户在谈论需求时能够谈笑风声，不然将来出现了偏差，是要负责任的。 2、如何进行需求分析 　　为了完成我们的需求分析，我们小组进行了很多次小组讨论，也和老师进行了多次交流。每次初步敲定需求后，我们都会针对现在的需求完成原型的设计，我们一共完成了两个大版本的原型。另外，需求分析也需要我们考虑更多，可能客户的考虑并不全面，我们要学会自己完善需求。总而言之，需求分析最重要的环节就是沟通！沟通

组长本次作业博客链接 一、组队后的团队项目的整体计划安排 阶段 主要任务 计划时间 内容 1 项目选题 第七周 选择可行性强并且能在带给福大学子便利的项目，完成项目描述市场调研，竞品分析等 2 需求分析 第八周 撰写需求分析说明报告，安排具体分工以及初步原型设计 3 设计分工 第九、十周 编码规范、平台环境搭建、初步架构搭建、明确细节分工 4 模块编程 综合对接 第十一、十二周 各模块编码、测试、项目管理同步推进、各模块完成后进行对接 5 测试反馈 第十三周 实景测试反馈优化、形成最终正式版本 6 优化完善 第十四周 根据测试反馈优化，形成最终正式版本 7 项目宣发 第十五、十六周 用户手册、发布、文案 二、团队分工 确定alpha版本需要做哪些事情 需要十分紧凑严格的任务安排，需要时间和熬夜，需要团队成员共同的努力和稳定输出... * alpha版本： 模块序号 模块名 模块具体内容 1 登录注册模块 完成用户的登录与注册 2 推荐模块 根据专业年级只能推荐书籍 3 搜索模块 买家自主搜索书籍，按关键字的相关度或者分类 4 交易模块 买家和卖家之间下单、线下交易 5 社区模块 用户间关于书籍的交流 6 个人基础信息模块 昵称、性别等个人信息的编辑存储 7 个性化模块 多样的界面 各成员分工明细及TODO list 成员 分工明细 TODO list 张逸杰 跟踪项目进程

团队项目-需求分析报告 一、博客链接 组长博客链接 二、组队后的团队项目的整体计划安排 编写需求说明书。 确定各功能模块分工。 完成UI设计，完成基础功能算法，制定测试计划。 完成Alpha版本，编码+测试+项目管理同步推进。 收集用户的试用反馈 完成Beta版本，以反馈为基础进行改良。 编写用户手册。 正式版本发布，进行后续维护和支持。 三、团队分工 姓名 分工 陈明磊 任务分配，撰写需求分析说明书引言部分，PPT 陈思涵 博客 林镕炜 需求说明书非功能需求和验收验证标准部分 实体关系图 韩洪威 原型设计，需求分析说明书原型部分， 状态图 杨润秋 需求分析说明书项目总体描述部分， 状态图 李欣凯 logo设计，需求说明书非功能需求和验收验证标准部分，活动图 陈舒洋 答辩，实体关系图 陈锦杰 需求说明书非功能需求和验收验证标准部分，类图，思维导图，评审表，小组评分，实体关系图 陈振旺 需求说明书非功能需求和验收验证标准部分，用例图 钟伟颀 需求分析说明书项目总体描述部分， 用例图 陈锦鸿 需求分析说明书项目总体描述部分， 用例图 胡浩楠 需求说明书非功能需求和验收验证标准部分， 活动图 四、思维导图 五、评估团队中每个人对本次作业的贡献比例 姓名 贡献度 陈明磊 9% 陈思涵 7% 林镕炜 8% 韩洪威 9% 杨润秋 8% 李欣凯 8% 陈舒洋 8% 陈锦杰 11% 陈振旺 8%

为什么要做竞品分析？无非就是当你有了一个初步的产品想法之后，但是却不能够明确这个想法到底靠不靠谱，它是否真的解决了用户的某些需求，这些需求算不算痛点，也不知道市面上是否已经有了与你想法相似的产品，他们是怎么做的，是否做得足够好，还有哪些待挖掘的机会等等。 此时你脑中的想法一定只是个demo版，非常的初级，是一个朦朦胧胧的状态，甚至你都说不清它到底是来源于哪里，可以是从以往生活经历中随意调取到的一个记忆点，或者是某个月黑风高的夜晚做的一个不知所以然的梦。 例如你在某一天的下午突然冒出一个念头，觉得自己想开个肠粉店，为什么会突然有这样的想法，很有可能就是你中午吃饭的时候闻到一阵飘来的肠粉的香味，而到了下午辘辘饥肠的时候脑里面就自动调取了这一部分记忆使之你有了这个莫名其妙的想法。 当然，想法的来源有时也非常明确，例如说你可能对某个产品的形态很感兴趣，所以你有了做这个产品的想法，或者是当你体验了某个应用商店app，有种透彻了解这类产品的想法，还有就是leader直接给予你的产品任务，例如他会跟你说阿毛啊，我们接下来公司想做一款新产品，是社交通讯类的产品，你好好去研究一下，看看怎么做更好。 因此，这时候的产品想法相对于前者来说来源就是明确的，但是不管来源是否明确，都存在着靠谱或者不靠谱的可能，无法判断这个想法是否有市场机会，你不能一拍脑袋就断定这个想法可不可行，想要真正明确这个想法是否有戏

软件工程自学 emmm我们专业不学习软件工程，自学一点，权当休闲。 1.概述 应对不断变化的需求 开发占比比测试和维护小得多。 1.2 软件开发的三个阶段 私人化的软件环境中，软件的水平与个人的关系很大。 专家系统：提供专业知识与服务 网格计算：云计算 软件开发的初期，一定要先花时间把需求搞清楚 可读性、可理解性越好，可维护性越好 软件开发追求一致性和标准性 技术先进，需求不清楚是中国的现状。没有技术解决不了的，但是主要问题是把需求提清楚 好的需求本身就是一种资源 维护对一个公司的信誉很重要，要考虑到开发公司的流动性 维护费：技术支持（电话、邮件）、上门解决，这是一个长期的盈利（对客户就是花费） 软件的维护是一件很困难的问题。 软件！=程序，软件是由一个完整的配置组成的，还包括文档和数据。 在软件开发的不同阶段进行修改，需要付出的代价是很不相同的。 一旦发生错误应该马上修改 开发费与维护费是两回事。签合同的时候要说好 1.3 软件工程概述 好的项目管理要尽量准时。 一种策略：快速迭代、抢占市场、尽早上架 开发目的的折中、最优化 易于维护的软件，可靠性一般也比较高 可靠性和性能是互斥的，一个是求稳，一个是性能导向的 软件工程的原则： 例如类，就是对一组有共同特性的对象的抽象 局部化：资源的声明、使用和释放应该放在同一个模块中并且应该尽量靠近 一致性：要培训员工使用公司统一的命名

来源：https://blog.csdn.net/Rong_Toa/article/details/80771976 第一章 软件工程概论 1．什么是软件危机？ 软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。这些问题表现在以下几个方面： (1)用户对开发出的软件很难满意。 (2)软件产品的质量往往靠不住。 (3)一般软件很难维护。 (4)软件生产效率很低。 (5)软件开发成本越来越大。 (6)软件成本与开发进度难以估计。 (7)软件技术的发展远远满足不了计算机应用的普及与深入的需要。 2．为什么会产生软件危机？ (1)开发人员方面，对软件产品缺乏正确认识，没有真正理解软件产品是一个完整的配置组成。造成开发中制定计划盲目、编程草率，不考虑维护工作的必要性。 (2)软件本身方面，对于计算机系统来说，软件是逻辑部件，软件开发过程没有统一的、公认的方法论和规范指导，造成软件维护困难。 (3)尤其是随着软件规模越来越大,复杂程度越来越高,原有软件开发方式效率不高、质量不能保证、成本过高、研制周期不易估计、维护困难等一系列问题更为突出，技术的发展已经远远不能适应社会需求。 3．怎样克服软件危机？ (1)充分吸收和借鉴人类长期以来从事各种工程项目中积累的行之有效的有效原理、概念、技术与方法，特别是吸取几十年来人类从事计算机硬件研究和开发的经验教训

项目开展的第二天，我与队友针对这次选题“基于微信小程序的食堂订单送餐系统的实现”开始了需求分析。我们完成了需求分析中的部分内容，确认了编制目的，希望通过此文档来初步介绍这一微信小程序，并借此使得用户能够更加了解其大概功能和使用方法；适用范围，此文档只适用于基于微信小程序的食堂订餐送餐等功能的介绍与使用；前提与约束，我们假设使用我们这一产品的用户已经了解到现在线上点餐等基本功能；用户类型主要分为两类，主要是食堂工作人员和学生。面对学生大数量的点餐送餐，软件需要及时更新发布数据，对于数据的快速响应和准确性有很大的要求；运行环境，无特殊硬件软件的需求，但对于使用者的网络必须保持良好，需要用户开通地理位置的权限，并完成校园认证；设计和执行约束，软件使用可以在微信小程序中找到并使用，且必须符合微信小程序使用的相关规定，必须配备身份认证系统等。用户界面；用户进入需要登录并且进行身份认证，需要配备其他帮助选项或者错误信息显示等。 明天会继续完善需求分析，功能需求等部分。 在今天的任务完成中，主要遇到的问题是第一次自主设计一个独立小程序软件，对小程序的设计要求不太了解，先前也未曾写过此类需求分析，所以查询了各种模板。 来源： https://www.cnblogs.com/hedi/p/11385087.html

交付用户想要的软件 让客户做决定 在设计方面，做决定的时候好必须有开发者参与。可是，在一个项目中，它们不应该做所有决定，特别是业务方面的决定。 Decide what you shouldn’t decide. 开发者（及项目经理）能做的一个最重要的决定就是：判断哪些是自己决定不来的，应该让企业主做决定。你不需要自己给业务上的关键问题做决定。毕竟那不是你的事情。如果遇到了一个问题，会影响到系统的行为或者如何使用系统，把这个问题告诉业务负责人。如果项目领导或经理试图全权负责这些问题，要委婉地劝说他们，这些问题最好还是和真正的业务负责人或客户商议。 当你和客户讨论问题的时候，准备好几种可选择的方案。不是从技术的角度，而是从业务的角度，介绍每种方案的优缺点，以及潜在的成本和利益。和他们讨论每个选择对时间和预算的影响，以及如何权衡。无论他们做出了什么决定，他们必须接受它，所以最好让他们了解一切之后再做这些决定。如果时候他们又想要其他的东西，可以公正地就成本和时间重新谈判。 毕竟，这是他们的决定。 具体技巧 记录客户做出的决定，并注明原因。好记性不如烂笔头，但你选择的记录方法不能太笨重或太繁琐。 不要用过于具体和没有价值的问题打扰繁忙的业务人员。如果问题对他们的业务没有影响，就应该是没有价值的。 不要随意假设具体的问题不会影响他们的业务。如果能影响他们的业务，就是有价值的问题。