用户需求

在我们上课的时候，经常听到老师的一个故事，是一个非常真实的事件，在我们软件人的经历中，经常会遇到这种情况。在一个软件上交检查时，你的用户或者老板总会提出一些你没有想到或者一些看似“无理取闹”的要求，他们总会说你们这个软件这个功能没有，那个功能没有，但这却是很正确的。在他们外人的眼里，没有代码复杂性，难度，构架这类的问题，他们关心的只有你的软件能不能显示他们想要的功能和美观。这就需要很重要的需求分析。开发人员和用户之间充分和有效的沟通在需求分析的过程中至关重要，我们要获取和引导需求。 这就是我们需要在开发前进行会议和用户调查的原因，虽然现在我们的软件还到不了用户调查的地步。这也直接体现了NABCD体系的重要性。 N：需求 1.学生录入课程需求。 2.学生对于空教室使用需求（自习或活动占用）。 3。学生对于具体课程的查询需求。 A:做法 基于安卓课程查询，录入系统。 B:好处 1.满足课程表的基本需求 2.便于用户查询空闲教室 3.便于用户对课程的查询 C:竞争 1基于本校学生的特定需求的推出特定功能 D:推广 利用本学校学生的特定需求对本校学生进行推广 这是我们之前软件的NABCD分析，现在着实感觉这很重要。 过去老感觉软件就是自己看着舒服就行，这是给自己做的，这种思想在团队里是活不下去的，也不会形成用户对你的肯定。这是在为了得分而做软件，越往后自己越明白需求分析站着极大的比重

本周阅读了构建之法的11、12、13。 11章的内容承接前面的章节提到了软件的设计与实现。前面的内容讲了如何解决用户需求，本章则讲了如何解决用户的需求。解决的过程要先进行建模，建模的思想在我以前的学习中就有接触，从小学习数学，而解决数学问题的核心是建立模型，列出式子求解，以前也曾学过数学建模这门课。邹欣老师用鸡兔同笼的例子引入，让人感到十分亲切，使得新概念比较容易理解。分析设计的方法有许多，本书则侧重介绍以图形为主构造的模型，其他方法也大致介绍了一下。然后讲了实现设计的工作流程。 12章讲了用户体验。王老师在课上多次强调过用户需求的重要性，软件工程是与人有关的一门课程。可见用户体验是开发环节中必须重视的。本章讲了用户体验的要素、用户体验设计的步骤和目标、评价标准。看过本章发现原来生活中使用的物品的设计有着很多要考虑的方法，而软件的设计也要注意许多方方面面。以前总是写控制应用台程序，都不怎么考虑用户体验。团队开发时一定要多注意这方面。 13章先讲诉了软件测试方法及分类，这部分内容偏理论。而后讲了实战中测试，先纠正了大家的一些不明确的观点，让大家对知识的理解更深入。测试工作中要有文档的书写，并且这些文档要解决问题。 通过这次阅读，我发现了自己在用户需求方面考虑较少，以至于没有良好的用户体验，还有就是没有建模思想，想到哪写到哪，思路比较乱，所以以后我会注意建立建模思想

　1. 引言 　　未来将越来越不可预测，这是新经济最具挑战性的方面之一。 商务 和技术上的瞬息万变会产生变化，这既可以看作要防范的威胁，也可以看作应该欢迎的机遇。 　　 ________Martin Fowler & Jim Highsmith,《敏捷宣言》 　　“长江后浪推前浪，世上新人赶旧人”说的是人类社会的发展之快，象软件业这个大家庭的发展更是日新月异。软件业发展的生命周期中如人类社会一样同样经历着几个不同的阶级。 　2. 软件发展的方向 　　2.1 软件发展的四个阶段 　　l 第一阶段：项目式开发阶段 　　最早期的软件开发都是基于一个具体的项目，这个项目由客户(包括上级部门安排的任务)提出具体的需求，在甲、乙双方以合同的方式约定好开发费用、开发时间以及验收标准后开发方组织人马加班加点去完成合同所约定的任务。这个阶段的一个重要特点是用户的需求是十分清楚的，开发的软件也是给特定用户使用。 　　l 第二阶段：套装式软件开发阶段 　　项目式开发阶段是针对一个客户开发一个具体的项目，这种服务事实是一对一的。显然，作为经历过大数量的开发项目的软件公司，为了降低开发成本，最大化地利用以前的工作，不再满足于自己开发的一个软件只能服务于一个客户，它更希望一个软件能最大化地服务于多个用户。哪怕是不同的项目需求，只要在原有相类似的软件上经过适当的修改和配置就可完成新项目。或者以本项目为基础

增量模型也称渐增模型，使用增量模型开发软件时，把软件产作为一系列的增量构件来设计、编码、集成和测试。 大部分互联网创业公司都愿意选择增量模型的原因主要有： 1：现在很多软件在开发前并不知道用户的需求，所以采用增量模型，先发布基础软件，然后根据用户的使用反馈来总结用户的需求，再一次次添加其功能，完善软件的作用。这样有利于公司的运行，不至于一开始就做出功能完善但却不符合用户需求的软件。另外， 用户的需求是时时刻刻在变的，项目开始的时候或许用户的需求还是明确，可是开发过程中用户需求改了。这样会使公司遭受巨大损失。用增量模型可以减低这种风险。 2：软件开发需要大量资金，使用增量模型可以减低风险。比如，先发布其基础软件，如果用户评价不好，没有收入，可以立即停止其开发 ，减少为这款软件所投入的资金。 3：增量模型是分批地逐步向用户提交产品，整个软件产品被分解成许多个增量构件，从第一个构件交付之日起，用户就能做一些有用的工作。 4：增量模型逐步增加产品功能可以使用户有比较充裕的时间学习和适应新产品，从而减少一个新软件可能给客户带来冲击的可能。 来源： https://www.cnblogs.com/William8023/p/5247873.html

1 多个开源产品可以拿来分析其架构，如eclipse，万维网， 2 需求并不能决定架构，架构是一种高层设计，最重要的是，架构的设计受到很多方面的影响，这些带来影响的因素（技术，商业，社会，涉众的需求，开发组织的结构或者本质—例如开发组织的商业目标和技术特点等，设计师的经验水平，等）也是我们进行架构设计时需要考虑的，同时也可以帮助我们很好的分析一个（商业产品的）架构。 要注意到，完成一个架构的设计会带给前面所提到的因素一定的反馈，得到一定的收获。 3 架构商业周期Architecture Business Cycle：软件架构是技术，商业和社会等诸多因素作用的结果，而软件架构的存在又反过来会影响技术，商业和社会环境，从而影响到未来的架构，这种互相影响的周期—从环境到架构又返回到环境—就叫做架构商业周期 4 架构活动： 1）为系统构建一个商业案例（商业目标） 2）理解系统需求（最重要的是涉众的需求，可以使用面向对象的方法-即用例分析来获取，也可以通过捕获质量属性需求，再者，参考相似系统也可以获得需求） 3）创建或选择架构 4）将架构编成文档，并与有关各方进行交流（编档要面向不同的涉众给予不同文档，便于交流） 5）对此架构进行分析和评价（ATAM或CBAM，注意一点是评估过程不能脱离实际环境） 6）根据此架构实现系统 7）保证系统实现符合架构的要求 5

如果程序员只懂编程，其生存空间会越来越窄，发展也会处处受限。 互联网公司，开发人员的日常工作任务，大致有如下几类： 1. 产品人员需求（业务开发）； 2. 运营人员需求（活动）； 3. 以及技术团队自身技术更迭； 从主动性来看，可能只有最后一种，是程序员自己真心喜欢的，其他的，都是被动接受。 加上不懂业务的程序员，反抗精神不足，基本上产品和运营同学，提什么需求就做什么需求。 我遇到好多程序员，问他对自己实现的功能怎么理解？基本上都会回答：产品/运营同学让这么做的。 我一直也在自己提醒自己：一个开发人员要有产品思维、用户思维。 对程序员来说，功能是你实现的，代码是你一行一行的敲出来的，你是它的缔造者，你最熟悉它。你最应该关心每一个实现的功能点，是否真的能给使用人员带来效果。 常常，听到最多的抱怨：”我们公司产品用户量太小了，没几个人用，没有成就感。”，“我费劲实现的功能都没有使用，当初怎么考虑的这个需求。”。。。你自己难道不应该考虑吗？ 从事开发工作的时间也不短了，一直在传统的互联网工作做业务开发。工具类的、金融类的、电商类的、社交类的，多少都涉猎了。 从技术实现，到技术选型，架构设计，到最后的带团队，开始管理之路。一路走来也颇有体会，忧虑也时常伴随着。对技术，还是不舍得放弃，也在不断的提高自己技术的敏感度，从深度转向广度。 大数据技术，成为了我最近几年的一个技术尝试

作为一名产品经理，它是一个产品的“灵魂”，是一个产品的缔造者和驱动者，负责一个产品从最初的idea，到产品的定位、设计、开发、测试、运营，再到最后的优化迭代，是一个产品整个生命周期的负责人。 在产品整个的生命周期中，产品经理的职责非常重要，将一个创意的idea转化成真实的产品，产品经理发挥了很大的作用，第一步就要对产品进行定位，明确产品的功能属性、目标用户、目标市场、核心需求等等。 一、什么是产品定位？ 产品定位是指确定某产品在消费者或用户心目中的形象和地位，即通过塑造产品或企业的鲜明个性或特色，树立产品在市场上的形象，从而使市场上的目标用户了解和认识本企业的产品。 如国内BAT三大互联网巨头，它们的产品都有属于它们自身特有的定位，百度的产品定位或者特色在于搜索、在于技术；而阿里巴巴的产品定位有着明显的电子商务属性；再者，腾讯的产品更不用说，带有强烈的社交基因。 说白了，对于一个产品的定位就是寻找产品自身的独特利益点所在，以与其他同类产品明显的差异，通过这个差异让消费者或者用户能够对产品产生固定的联想。 产品定位必须解决的五个问题： · 满足谁的需要? · 他们有些什么需要? · 我们提供的是否满足需要? · 需要与提供的独特结合点如何选择? · 这些需要如何有效实现? 二、产品定位的内容 公司要找准产品定位必须首先找准消费者及其需求特征

【 本文内容摘抄自网络 】 ① 在软件开发生命周期中，会遇到两个瓶颈。 第一，是在需求阶段和开发阶段之间，针对不断变化的需求，对软件开发者提出了高要求，所以出现了敏捷开发方法论，强调适应需求、快速迭代、持续交付。 第二、是在开发阶段和构建部署阶段之间，大量完成的开发任务可能阻塞在部署阶段，影响交付，于是有了DevOps。 ② 软件需求包括3个不同的层次―― 业务需求【 表示组织或客户高层次的目标 】、 用户需求【 描述的是用户的目标，或用户要求系统必须能完成的任务 】、 功能需求【 规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求 】。 除此之外，每个系统还有各种非功能需求。 ③MVP模式，暂不理解。 ④用户故事：从用户角度描述用户渴望得到的功能 INVEST Independent（独立性） 可以被单独地开发、测试甚至交付。 有些故事之间会有自然的顺序依赖，但每个部分仍具备单独交付价值。 有些无价值的依赖，我们需要寻找和消除依赖（通常是和其他依赖的故事结合起来取交集，形成一个新的用户故事）。 Negotiable（可协商） 允许、且需要经过协商。 Valuable（有价值） 用户故事必须向用户、客户或产品干系人提供一定的价值。 Estimable（可估算） 可估算的用户故事能够提取任何隐藏的假定和欠缺的验收标准，并且澄清团队对用户故事的共同理解。

软件需求分析就是把软件计划期间建立的软件可行性分析求精和细化，分析各种可能的解法，并且分配给各个软件元素。需求分析是软件定义阶段中的最后一步，是确定系统必须完成哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求。 软件需求分析的任务是：深入描述软件的功能和性能，确定软件设计的约束和软件同其他系统元素的接口细节，定义软件的其他有效性需求，借助于当前系统的逻辑模型导出目标系统逻辑模型，解决目标系统“做什么”的问题。 需求分析可分为需求提出、需求描述及需求评审三个阶段。 需求提出主要集中于描述系统目的。需求提出和分析仅仅集中在使用者对系统的观点上。用户、开发人员和用户确定一个问题领域，并定义一个描述该问题的系统。这样的定义称作系统规格说明，并且它在用户和开发人员之间充当合同。 在问题分析阶段分析人员的主要任务是：对用户的需求进行鉴别、综合和建模，清除用户需求的模糊性、歧义性和不一致性，分析系统的数据要求，为原始问题及目标软件建立逻辑模型。分析人员要将对原始问题的理解与软件开发经验结合起来，以便发现哪些要求是由于用户的片面性或短期行为所导致的不合理要求，哪些是用户尚未提出但具有真正价值的潜在需求。 在需求评审阶段，分析人员要在用户和软件设计人员的配合下对自己生成的需求规格说明和初步的用户手册进行复核，以确保软件需求的完整、准确、清晰、具体

1.基本要求：是否有明确的用户价值，即能否为某些用户在某些场景下的具体需求提供解决方案，如果可以，则具备用户价值 2.基本要求：真实合法，不能欺诈消费者或进行恶意引导 3.进阶要求：和同类产品相比具备差异化优势，这样才能保证在竞争中获得用户青睐 4.高阶要求：设计简洁优雅 举例： 好的产品 微信读书：提供极致的阅读体验 得到：让知识触手可及 抖音：创新的短视频娱乐体验 不好的产品 各种导购类APP，毫无差异化 各种海淘类APP，没有合法明确的资质 来源： CSDN 作者： 青梅竹码 链接： https://blog.csdn.net/weixin_43258908/article/details/103625247