用户需求

产品经理学习记录 产品经理学习记录 产品经理 需求定义 什么是需求，需求的要素，需求的来源，需求后续落地 经济学定义：人们 有能力 购买并且 愿意 购买(使用)某个具体商品的欲望。( 意愿度 和 能力 ) 需求分析是互联网产品经理工作中最基本的能力，也是需要花最多时间修炼的能力。 期望-->具象行为-->核心需求 需求一定是简洁的，如果对于需求的描述不够清楚，说明不是一个核心的或者是关键的需求点，在需求背后需要做的行为才是复杂或者有更多的动作的。 行为背后的诉求 亲友群里面发拜年红包 --> 关爱，稳定 使用搜索引擎寻找的信息 --> 分析，决策 在脉脉上面吐槽领导 --> 发泄、安全 在朋友圈晒娃 --> 肯定、赞美 APP购物点外卖 --> 生理 长生不老 --> 生理 求职网站更新简历 --> 关注、安全 使用iphone8，独特“刘海”造型 --> 认同、尊重 离职创业 --> 自我实现 两个理论 马斯洛需求理论 高级阶段 ：自我实现的需求(比如：发挥潜能、实现理想) 中级阶段 ：尊重的需求(比如：受到尊重肯定) ；社会需求(比如：爱情、友谊、归属感) 初级阶段 ：安全需求(比如：对保护、秩序、稳定的需求)；生理需求(比如：身体对食物、温暖、性的需求) 需求也是分阶段的，分层次的 Kano模型 反向型需求 ：提供后用户满意度反而下降 基本型需求 ：用户不说也要做到(稳定

什么是功能，什么是软件，什么是产品，期初，我的理解产品和软件是一个东西，都由功能构成。经历一段时间工作和学习后，发现这个想法不对。 功能组合在一起是软件，软件本质是完成特定功能或流程的集合体，外形没有要求，注重功能实现，它可以简单，也可以复杂，可以个人开发，也可以公司，本质是某种需求的实现，不牵涉商业。 产品也是需求的集合体，它一般外形优美，功能庞大而复杂，以用户为导向，通过某种方式获得并留住用户，实现资本积累，主要公司提供。 软件以需求为导向，产品以营利和用户为导向，所以我认为软件和产品是两个东西。 程序员第一步，做的东西功能，完成能力积累，开始做软件，这是一次升级，从点连成线，再进一步是产品，根据人文环境，定义需求，制造的商品。 以上个人愚见。 来源： https://my.oschina.net/wangzonghui/blog/3132707

一、需求&原型 改进 需求的修改： 我们通过发放问卷的方式进行调研，了解了在校大学生对自身目标管理的情况 ，以及影响他们完成的主要因素，不同用户对目标小程序功能的需求， 数据详情见： https://www.cnblogs.com/liujiamei/p/11802627.html ， 针对问卷的数据反馈与分析，我们对项目需求做出了以下的修改： 问题1：我们本来想要做一个可以朋友间共定目标的，大部分用户认为还是比较介意别人看到自己的目标，并且觉得小程序本来就是为了便捷而生的，不必要做复杂的互动 修改1：由互动改为一个目标广场，用户可以自行选择是否发布，是否匿名，减少小程序上不必要的社交 问题2：用户认为提醒功能服务通知推送会对他们造成困扰，不作推送用户也会自己点进去看 修改2：减少推送的频率，或者不作推送也可 问题3：用户看完我们的第一阶段的需求，认为我们的小程序功能过于复杂，给予我们的建议是做一个模块做精即可 修改3：修改系统的主要功能为个人目标的推进，再从这个版块向其它分支拓展。 完善规格说明书： 　　我们上一周做的需求分析包括了面向用户分析（问卷加讨论的方式调研），产品功能分析（包括了产品的原型图），性能需求，以及验收标准的分析，对项目的目的背景都做了分析，总体来说是比较完善的，但是我们在对于产品的概述上还不够完善与吸引用户，所以我们对产品的概述上作出了调整与修改： 项目概述

一. 工程实践项目分析 在使用用例以及用例建模的方法之前，我简要介绍一下我的工程实践项目： 首先，我所选的是一个企业项目，题目为 “物联网组网智能分析引擎” ； 其次，项目描述为：通过爬取现有物联网设备组网的数据或采用现场调研的方式，运用数据挖掘方法对这些数据进行分析，为开发新型物联网设备提供参考与依据。数据分析结果可以包括成本、典型组网方式、开发周期、测试标准、交付周期、功能。 所以，能够提取出其中的关键词为：物联网；数据挖掘及可视化； Web 编程等。 下面的内容主要分为两个部分，一是叙述用例一些基本知识，二是针对于我的工程实践项目，展示用例的分析以及建模的过程。 二. 用例建模的作用与步骤 2.1 什么是用例方法？优势何在？ 首先来看一下传统的需求表述方式——"软件需求规约"(Software Requirement Specification)。 传统的软件需求规约基本上采用的是功能分解的方式来描述系统功能，在这种表述方式中，系统功能被分解到各个系统功能模块中，我们通过描述细分的系统模块的功能来达到描述整个系统功能的目的。 采用这种方法来描述系统需求，非常容易混淆需求和设计的界限，这样的表述实际上已经包含了部分的设计在内。由此常常导致这样的迷惑：系统需求应该详细到何种程度？一个极端就是需求可以详细到概要设计，因为这样的需求表述既包含了外部需求也包含了内部设计

　我的工程实践为搭建一个传感器信息展示网站，功能是帮助用户找到符合自己需求的传感器产品。 1.抽取Abstract use case 　　这里抽象出两个参与者：开发者和用户 　　对于开发者： 　　　　抽象出的系统用例有： 　　　　　　　　　　注册/登录 　　　　　　　　　　退出系统 　　　　　　　　　　管理用户信息，包括修改用户访问权限，维护用户账号，增加用户，删除用户，查看用户详细资料 　　　　　　　　　　管理产品信息，包括增加产品信息，删除产品信息，修改产品信息 　　对于用户： 　　　　抽象出的系统用例有： 　　　　　　　　　　注册 　　　　　　　　　　登录 　　　　　　　　　　退出系统 　　　　　　　　　　修改个人信息 　　　　　　　　　　收藏/删除产品 　　　　　　　　　　按需求搜索产品 　　　　　　　　　　产品对比 　　　　　　　　　　偏好设置 2.用例图 3.Expanded use case 按需求搜索产品:用户可以通过输入产品的名字或者型号，或者选定筛选条件来过滤展示结果 产品对比：可同时对比多个产品的参数，特性，选出最符合需求的产品。 来源： https://www.cnblogs.com/lambdoor/p/11781442.html

《网上书店系统》 班级：软件工程 173 姓名 + 学号： 田巧 1713033084 （ 16% ） 王静 1713033085 （ 16% ） 王瑶 1713033086 （ 16% ） 徐蕊 1713033087 （ 16% ） 张婷婷 1713033088 （ 20% ） 张王莉 1713033089 （ 16% ） 一、项目的介绍 1、典型用户：读者 2、需求：购买书籍 3、产品名称：网上书店 4、其他竞争产品：淘宝、京东等 5、我们能够根据用户的需求，快速的匹配相对应的书籍，为用户提供更好更全面的服务。 二、系统功能分析 2.1 系统需求分析 系统的主要目的是实现一个图书管理系统。系统用户分别为管理员和读者。管理员经口令认证进人系统后，管理员可完成维护系统的功能，包括管理图书和管理读者。读者则完成查询图书、修改个人资料、查询个人购买信息的功能，工作完成后可以退出系统。 2.2 功能需求描述 随着互联网的高速发展，网上购物已经成为了当今主流，网上购书也不例外。所以设计一个网上书店系统可以轻松解决人们的便利购书。 系统主要是为方便用户定制开发的，因此针对网上购书而言，网上书店系统的主要功能为: 用户功能模块： (1)用户注册和登录 设计用户注册和登录界面，用户根据账号和密码登录系统进行身份验证。 (2)修改个人信息 (3)浏览图书信息 (4)图书订单信息 ①添加图书

参加一个朋友公司的用户访谈活动，访谈开始前，朋友请谈谈对活动访谈提纲的看法，看了一遍又一遍，就是看不出好在哪，不好在哪，这弄得有点尴尬，只好恭维人家说做得不错，才勉强躲过一劫，否则就糗大了。 我们经常说用户是懒的，其实产品经理何尝不是？都想走捷径，能懒则懒，所以对工具和模板是情有独钟，这也无可厚非，只要能提高工作效率，都可为我所用，这也是一种本事。在此我们主要阐述5种非常重要的需求工具。 1.用户问题（痛点）分析 (1).问题/机会领域的名称：ABC。 (2).问题描述：ABC是影响收入或数据最主要的消极因素，影响许多其他领域。 (3).宽度分三档：60%以上（大）、30%～60%（中）、30%以下（小）； (4).问题的严重性分三档：60%以上（高）、30%～60%（中）、30%以下（低）； (5).问题的频率分三档：60%以上（高）、30%～60%（中）、30%以下（低）。 (6).问题的重要性： 由于____，影响细分用户的宽度是____。 由于____，问题的严重性是____。 由于____，问题的频率是____。 (7).与关键问题相关的一些发现： A.缺乏____（定义） 用户这样说：“……” 用户这样说：“……” B.害怕____（详细说明） 用户这样说：“……” 用户这样说：“……” C.____（详细说明） 用户这样说：“……” 用户这样说：“……” 完成分析后

为了指导软件开发，可以用不同的方式将软件生命周期中的所有开发活动组织组织起来从而形成不同的开发模型。 瀑布模式 瀑布模型严格遵守软件生命周期各阶段的固定顺序:计划、分析、设计、编程、测试和维护，上一阶段完成才能进入到下一阶段，整个模型像一个飞流直下的瀑布一下，如图所示 特点: 阶段间具有顺序性和依赖性 前一阶段完成后,才能开始后一阶段 前一阶段的输出文本为后一阶段的输入文本 推迟实现的观点 质量保证: 每个阶段必须交付出合格的文档 对文档进行审核 缺点: 开始需要把需求做到最全 惧怕用户测试中的反馈,惧怕需求变更 过于理想化缺乏灵活性 螺旋模型 限制条件: 适应于内部的大规模软件开发:螺旋模型强调风险分析,许多客户都无法接受和相信这种分析因此 适合于大规模软件项目(执行风险分析将大大影响项目的利润,进行风险分析就毫无意义) 软件开发人员应该擅长寻找可能的风险,准确地分析风险,否则将会带来更大的风险 优点: 设计上的灵活性,可以在项目的各个阶段进行变更. 以小的分段来构建大型系统,使成本计算变得简单容易 客户始终参为保证了项目不偏离正确方向以及项目的可控性 客户始终掌握项目的最新信息,从而他或她能够和管理层有效地交互. 客户认可这种公司内部的开发方式带来的良好的沟通和高质量的产品. 缺点: 很难让用户确信这种演化方法的结果是可以控制的.建设周期长,而软件技术发展比较快

数据仓库概念 数据仓库是一个面向主题的、集成的、非易失的、随时间变化的用来支持管理人员决策的数据集合 面向主题:操作型数据库的数据组织面向事务处理任务，而数据仓库中的数据是按照一定的主题域进行组织。主题是指用户使用数据仓库进行决策时所关心的重点方面，一个主题通常与多个操作型信息系统相关。 集成:数据仓库的数据有来自于分散的操作型数据，将所需数据从原来的数据中抽取出数据仓库的核心工具来，进行加工与集成，统一与综合之后才能进入数据仓库； 非易失的:数据仓库中的数据通常以批量方式载入和访问，在数据仓库环境中一般不进行更新 随时间而变化:数据仓库中的每个数据单元只是在某一时间是准确的。在一些情况下，数据中加有时戳，而在另一些情况下记录则包含一个事务的时间。总之，在任何情况下，记录都包含某种形式的时间标志用以说明数据在那一时间是准确的。 数据仓库发展 数据仓库和决策支持系统的起源可以追溯到计算机与信息系统发展的初期。 1. 20世纪60年代：穿孔卡和纸带作为最常用的存储介质，应用以报表处理为特征。 主文件和磁带的使用量的迅速增长，出现了大量冗余数据，导致： 1）更新数据时需要保持数据一致性 2）程序维护的复杂性 3）开发新程序的复杂性 4）支持所有主文件需要大量硬件 2. 20世纪70年代：出现磁盘存储器，数据库管理系统以及在线事务处理（OLTP） 3. 20世纪80年代

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