教育产品怎么做用户需求收集

1. UI设计怎么做用户需求分析方法有哪些

1. 用户目标

这里有一些我们要试着回答的问题.这些问题帮助我们理清自己的思路，根据这个思路我们会得到一些答案，这些答案会让我们知道有什么需要填补的知识空白？这些都会指导设计过程中每一个细节

2. 我们的设想

我们自己或者我们的团队首先会有一个自己的目标与事先这一目标的设想，这些是我们相信我们已经知道的。我们团队的设想是什么？我们是怎么理解我们的用户的？包括他们的行为和对他们需求的潜在解决方案。

3. 具体方法

这些方法告诉我们怎样去填补知识空白。基于有限时间和有限的用户，我们该选择什么方法？

一旦你回答了上面的问题，整理一份单页研究计划给你的领导，你可以从选择的调研方法中开始收集你需要的知识：

4. 开始动手

通过我们已选择的方法收集数据。

5. 综合起来

解决我们用研的问题，证实或推翻我们的假设。解释我们收集到的数据来发现存在哪些设计可以努力的机会和深藏的点

用户目标

假定你正处于为一款帮助人们在饿了的时候能立马有个人送来可口的饭菜这一产品时。你的团队正在讨论是否为送来的菜品拍照促进他们在社交网络中分享该软件，连同他们的评论一起分享。

“分享外卖美食”团队某些成员会这么称呼它并连连点头“这听起来很酷，哇塞，好棒棒哦，终于能在朋友圈秀宅男的幸福生活了” 但是你不能明确知道这个功能的适用人群，为什么用户想用它。

放下线框制作和代码编写，和你团队成员一起坐下，快速讨论你们已经知道和了解的产品目标。为促进这次讨论，让你的团队成员准备一系列设定的问题来帮助他们辨别他们所需要填补的知识空白。他们最好把这些问题写在便利贴上，一个问题一个条儿，这样比较容易管理和讨论。

这些设定问题是5个“W”（WHAT、WHEN等等）和1个“H”（HOW）开头的结构的问句，类似于一个记者写一篇新闻报道时需要回答的一些问题：

例如：

态度相关设想

“使用外卖软件的用户喜欢听取他们朋友的评论。”

行为相关设想

“外卖用户只愿意分享他们吃的新奇事物，美味事物。”

方法

一旦你确定了研究目标和一堆设计设想，你也需要考虑哪种研究方法适合达到你的目标。通常，为了达到调研目标，我会在以下分类中选择不止一种方法，把它们结合起来进行调研。

1：实景观察法

你花时间到用户生活和工作的地方去，能帮助你建立一个关于他们居住环境和潜在未满足需求的基本理解。

2：纸质原型

这个领域的方法包括日常研究，卡片分类，纸面原型和其他一些参与式的设计活动。一旦我很好的理解了我的用户的专业知识和信仰，我就可以开始深层次探究迎合他们需求的内容，功能和产品。这些可以在与研究参与者密切合作中产生潜在设计解决方法时完成，当然也可以在设计设想初期接受他们的真实反馈。

开始动手

当调查结果跟你原来的设想有差异时，不要试图改变用户想法，而是站在中立态度上试着询问原因，了解这是否是用户的真实想法。

针对调研的问题，进行解决方案设计（此时你最初的设想会大面积瓦解）

需求来源可以大致已经搜集完了，其中产品数据、用研是从产品侧提出，更有老大（老板）敏锐的眼光则是“人为”思考的结果。这个每个老大不同我就不好说了嘛

通过不同渠道收集到一堆需求之后，不可能全部都能做，需要按照一定规则和流程，筛选出来最有价值的需求，将有限的投入产出最大化。这里有个方法就是“关键词检索”，无论是功能方面的，用户属性方面，场景方面，找出简短的词或者语句表现出来，能想到的全部写在便签条上不要限制自己的思维，贴在黑板上，之后对便签条上的内容进行分类整合，然后筛选出大家公认最应该留下的。除了后来的用研资料，你一开始的设想如果同队对用户的反馈后大致吻合也写到上面，不吻合的就果断推翻掉，一定要了解用户最真实的需求，了解用户目标，了解用户的使用场景，了解用户的使用习惯，这些资料就为我们要设计的产品定位提供了一半的依据。

今天给大家简单的介绍了用户需求的内容，和一些比较使用的用户需求分析方法，了解工作项目中了解用户的需求是非常重要的，当然这个用户可能是直接使用你产品的人，也可能是你的老板。只有了解他们内心的真实想法才能让你的事情做的更漂亮，得到认可。当然如果你是创业者，需要自己去面对各种个样的客户那么今天所讲内容，对你更有意义。

2. 产品设计中怎样针对用户需求做定量研究

定量研究(Quantitative Research)

能帮助获取用户认知、意见、行为发生的频率以及消费者对某一产品或服务的设计概念感兴趣的程度，从而确定最感兴趣的目标用户群。采用精确严格的实验程序控制经验事实的情景，从而获得对事物因果关系的了解。

优点：

1.标准化：主试者的操作流程、指导语均保持一致；被试者按照固定要求回答所有问题或完成指定任务；定量研究中问卷选项或者测试任务保持一致。

2.易于管理：流程固定，便于统一操作；采集数据格式一致，便于分析、处理；被试者可自行完成问卷、任务。

3.结果分析全面：事件发生顺序、因果关系、5W2H

4.适用数据分析:大样本、计算机数据处理、交叉列表、统计分析

5.差异敏感：可分成不同组成部分，研究不同状况，不同变量差异可以统计处理

互联网产品设计中做用户定量研究的方法？

一问卷调查（Questionnaire Survey）

运用一系列问题及其他提示从受访者处收集所需信息的方法。

适用范围：可用于收集目标用户群对现有产品的使用行为与体验信息，测试产品/服务设计概念，评估消费者的接受程度。

问卷种类：形式多样，可依据实际选择面对面提问、电话问卷、互联网问卷、纸质问卷等。

常用问卷法：结构性问卷；量表式问卷，包括类别、顺序、等距、等比

使用方法与技巧：

1.调查结果取决于研究目的。依据研究的问题提出问卷调查的话题，问卷是否涵盖所有问题，问题是否必须。

2.选择每个问题的回答方式，如封闭式、开放式、分类式。有时使用样本量少却包含需深入回答的开放性问题比使用大量样本效果更佳

3.斟酌问卷结构，合理清晰决定先后顺序并归类，测试并改进问卷，结合视觉材料，为问卷提供更多生动有趣的可能

4.依据不同话题邀请合适的调查对象，随机取样或有目的选择

5.运用统计数据展示调查结果，以及测试问题与变量之间的关系

二市场研究（Market Research）

根据数据预测产品对消费者的吸引力，有效预测潜在消费者和整个市场对产品的需求。

使用方法与技巧：

1.市场划分方法：消费心理学，行为变量，价值态度和生活方式（VALS细分体系），地理人口统计法（PRIZM市场细分法）等，市场细分利于定量研究从多角度审视，从多维分析。

2.划分标准：

地理（地区地理位置，城市规模、级别，气候变化，交通状况，人口密集度）；

目标人群（性别，年龄、职业、收入情况、受教育程度、家庭人口、家庭生命周期）；

心理因素（对商品采购的主要敏感元素，购买动机，生活方式，消费态度）；

行为因素（购买时间、数量、频率、渠道，品牌偏好忠诚度，价格承受范围、敏感度，传播渠道的覆盖力，售后服务重视度）

3.研究流程：市场研究与分析（定量）――目标导向设计研究（定性）――驱动行为/人物模型――市场规模研究（定量）

感谢阅读，希望对你有帮助！

3. 开办教育培训机构怎样开发新客户

经营一家教育培训机构最重要的就是做好客户开发工作，这是教育培训行业最核心的难题。想必关于教育培训机构如何快速高效的开发客户也是很多想要投资该行业的创业者最关心，也是最喜欢问的问题，中国连锁网小编在这里向大家介绍一下相关的方法和技巧。 教育培训机构可以根据客户类别去定期不定期地拜访客户，及时了解分析客户需求，收集新的信息，及时设计产品来满足他。办一份简单的信息简报，定期邮寄给客户，内容包括培训公司信息动态、优秀培训文摘、表明公司观点的文章等，显得培训公司很专业，让客户及时了解培训公司的活动状况，进行有效沟通和互动。三是建立客户俱乐部或HR沙龙，定期针对企业培训主管、HR经理开展讲座、说明会、联谊活动等，和客户建立良好的关系和固定联系，增进了解，联络友谊，实行共赢局面，建立长久的战略性伙伴关系，来共同进步，共同成长。 教育培训机构作为一个知识密集、人才密集、技术密集的智业，更应该身体力行，走在别的行业的前面，吸收先进的、新的理念，形成好的培训课程产品，传播给更高的企业和员工，使大家收益，更得会用心经营，科学运作，精耕细作。春天播下种子，才会有金秋的收获，“种豆得豆，种瓜得瓜”，百尺竿头更进一步，相信培训公司的明天会更美好。 教育培训机构的经营者可以在结合以上介绍的几大开发客户要点的基础上，通过结合自身的实际经营情况，将自身有利优势不断的整合，最大程度上发挥开发客户方面的优势，在经营过程中体现出您的教育培训机构品牌特色。在熟练的掌握了这些方法之后，您的教育培训机构一定能够经营好。希望通过上面几点介绍能对投资者成功经营带来帮助。

4. 请问教育培训机构怎样开发客户

教育培训机构开发客户的三点注意：
一是根据客户类别去定期不定期地拜访客户，及时了解分析客户需求，收集新的信息，及时设计产品来满足他。
二是办一份简单的信息简报，定期邮寄给客户，内容包括培训公司信息动态、优秀培训文摘、表明公司观点的文章等，显得培训公司很专业，让客户及时了解培训公司的活动状况，进行有效沟通和互动。三是建立客户俱乐部或HR沙龙，定期针对企业培训主管、HR经理开展讲座、说明会、联谊活动等，和客户建立良好的关系和固定联系，增进了解，联络友谊，实行共赢局面，建立长久的战略性伙伴关系，来共同进步，共同成长。
教育培训机构作为一个知识密集、人才密集、技术密集的智业，更应该身体力行，走在别的行业的前面，吸收先进的、新的理念，形成好的培训课程产品，传播给更高的企业和员工，使大家收益，更得会用心经营，科学运作，精耕细作。

5. 如何进行需求收集

收集用户需求（你也可以将它称作启发用户需求，如果你更喜欢这个花哨的名称）一般比较困难，现在让我们考虑一下为什么这个过程如此艰难，当你面对这个问题时你会采取什么办法处理。我想，此时，有两个问题你必须先考虑：即何为用户的隐含需求（即未明确表达出来的需要），何为明确需求，如何在它们之间进行转化，以及这种转化的意义？任何曾经从头开始开发过应用程序的开发者都知道：在用户陈述需求或主题专家描述代码应解决的问题时，我们很难完全理解他们的目的。大家都知道，需求收集是一种挑战；但是，为何难以收集到合适的需求、该采取什么办法，这些问题就更难以理解了。其实，用户的隐含需求与明确需求的概念，类似于我们日常所说的默会知识与明确知识的概念，因此弄清楚默会知识与明确知识的涵义以及它们之间的转化关系，对我们研究用户的隐含需求与明确需求很有意义。现在，我们先来了解一下默会知识与明确知识的概念以及相互的转化过程。默会知识默会知识指基于经验和观察的知识。不存在一些由以前传承下来的法则或程序。它只是做事的方式而已。由于它的相关性，它具有非常强大的力量，能够直接应用于将来需要解决的问题上。默会知识的一个例子来自我的一个靠做零工为生的朋友。由于我们很谈得来，所以他和我喜欢一起做事情。最近，我们正在我的车库里为教堂做鼓架，他不断表现出各种小知识。我们先做好框架，然后再把它与平板连起来；而不是一次一块木块在平板上做框架。为什么这样做呢？答案是那样更加方便简单。他怎么知道这样做呢？他做过许多这类活（做橱柜和讲台），足以知道这些知识。他知道各种各样的知识，例如，确信木板的顶部，所有木材正常的轻微弯曲部分全部向上。为什么呢？因为当它载重时，它会产生变形，由弯变平，回到中间位置。另一个例子是我几年前在大学里学到的东西。它与循环结构有关。我的导师建议我使用一个在循环开始之前就执行初始阅读的循环结构。当时我使用的结构在循环开始后才进行阅读，所以循环中包含一个巨大的IF块。当时她建议我使用一个将阅读语句放在循环前的新结构，我问为什么。她回答道：“因为这是更好的方法。”凭经验，她知道在循环开始之前（和循环结束之后）执行阅读会更好。
在学徒期，主要学习的是默会知识。从一个比你经验更加丰富的人那里，你学会处理事情的方式。通过这种方式，我们学会制造优良产品或加快工作速度的细小而微妙的方法，这些知识是你在正式的教科书中无法学到的。一些人就是知道凭经验来做事情。你可能很难让他们向别人解释这些知识，或将它们写下来，但他们确实知道这些建立在经验之上的知识。明确知识相对于默会知识，明确知识是指可以被量化的知识。你可以将它们书写下来，在人们之间传达。它是实实在在的，不是获得的经验。它是那种已形成规则的知识。例如，一个人看到苹果从树上掉下来，并知道摇苹果树来得到苹果——默会知识——并且他可能还知道重力作用使所有物体集合在一起。最初通过观察获得的默会知识，最终转化成一种定律，明确知识。明确知识是通过文章、书籍、研讨会和视频演示传达的知识。明确知识我们总可以在书本商找到，因此没有必要直接经历某事来获得与其相关的明确知识。这是刚毕业的学生受到的批评的原因之一：他们拥有许多“书本知识”（明确知识）但缺乏实际经验（默会知识）。我们很清楚地知道，不管明确知识有多么重要，它总是无法代替默会知识。另一方面，由于印刷机的出现，明确知识以更为快捷的速度在传播。由于我能够将默会知识转化成一组你能够应用的规则，所以你正在阅读这些文字，并学会各种不同的知识。

6. 需求收集方法

产品经理如果要着手设计一个有用的互联网产品，收集用户需求算是整个产品的开端，而且是非常重要且是不可忽略的一个步骤，一些大型的互联网公司设置有专门的岗位进行市场需求的调研，而且收集需求的这一阶段属于产品功能设计的加法阶段，在产品需求收集的初期应该尽可能多的收集用户的需求，之后再进行筛选，做减法，精选出有用的功能，这是整体的做产品思路。

一、调查问卷。如果没有明确的用户群体，或者说用户群体比较模糊以及大众化，这个时候一般都会采用问卷调查的形式来收集用户的需求，调查问卷可以采用网上调查问卷，这样受众较大且成本较低，也可以采用线下的形式进行问卷调查，不过问卷的回收情况有时却并不理想，两者各有利弊。

二、用户访谈。如果有忠实的粉丝或者受众比较狭窄，可以考虑使用用户访谈的形式来进行，用户访谈可以采用一对一的形式，也可以通过召开用户大会来进行需求的收集，但是如果是用户大会的话，从前期的准备到后期的收集整理，也会有比较长的周期，但是这样获得的需求一般来说质量相对来说还是比较高的。

三、电话访谈。使用移动电话、座机、微信语音等语音工具来进行需求收集的一种形式，其形式与用户访谈有些类似，但是相对于面对面的这种形式来讲，可能获得需求的质量并没有用户访谈以及用户需求大会的质量要好，但也不失为一种非常好的形式。

四、实地调研以及做可用性测试。针对设计出来的产品的部分功能进行可用性测试，其实更多的是在做减法，根据用户的使用习惯来进行功能需求的优化，其实很多时候，用户的使用习惯与自己的表述会有很大的差距，只有真正让用户体验了，才能够收集到用户真正的使用需求。

五、借力第三方大数据公司。目前国内有很多第三方大数据公司都拥有数据咨询的服务，针对前期某部分的需求，可以通过咨询第三方大数据公司来获得，当然，咨询大数据信息是要付出一定酬劳的

六、其他方法，比如领导者或者产品经理做产品时候的经验不过这种方法属于定性研究，有很大的不确定性，因为并不是每一个人都是苹果手机的设计者。或者通过一些指数分析工具来预测某一个功能未来的发展趋势，这种方法类似于通过分析大数据来进行对未来的预判，当然这种方法也存在着一定的风险。

7. 需求收集、分析、管理的方法

这个专栏将定期发布产品部关于产品设计方面的思考。主要有以下四个方面：1）产品规划 2）用户需求探讨 3）产品设计过程思考 4）竞品分析。

开设这个专栏的目的很简单，主要有两个，一是让公司各位同事能随时了解并参与到我们产品设计的环节中，同时能通过这样的平台给我们多提意（tu）见（cao）。二是通过这样的专栏也能倒逼我们更多地思考，提高自身的产品设计能力，从而设计出更好的产品服务大家。。

这是我们产品部的第一篇关于产品设计思路的文章，想了很久要怎么写，从什么角度开始。最后我觉得任何产品的起源都来自需求，这期就主要聊聊我们是如何收集、分析和管理需求的办法。如考虑不周的也请各位多多指正。

首先是我们如何进行需求收集的。主要有三个方面：

毕竟老板对行业和业务比我们熟悉太多，前期需要吴校和各位大佬多给我们提意见和想法，帮助我们产品方向不会跑偏。

目前我们的用户反馈包括两个环节，一是开发前我们将产品需求转化为原型DEMO，同时我们会选取对此产品最熟悉的用户并把我们的原型一一和他们进行确认，如果还有问题则继续调整原型，如无问题则可进入开发阶段。如极运营在最初的产品设计时我们与财务同事确定需求不下10次，同时也到各校区找到相应负责人进行了多轮的沟通和确认工作，收集了大量宝贵的意见。（这里要特别感谢申琴，在前期我们产品对极运营的需求一无所知时，是她在反复耐心地给我们讲解需求）

二是开发完成上线后我们通过面聊或通过《需求反馈表》给我们反馈的需求。我们目前使用的需求反馈表还用的是比较传统的excel表格，后期会考虑做成简单的系统，这样采集反馈问题更及时，反馈人也能更方便了解自己反馈需求的状态。

当然，在整个用户反馈环节，我们也有需要反思的。比如需求调研覆盖的面还不够广，覆盖的层次还不够多，包括各大区不同岗位层级的用户还没来得及全部沟通到位，后续我们也会在此投入更多精力。

从进公司到现在，产品部已经完成两版的竞品分析报告，也分析了大量教育类产品，从中收获非常多。无论是对整个行业软件水平的了解，还是学习借鉴优秀产品，都帮助我们对行业内产品有了更深的了解，后期有机会我们会把这些分析报告整理后发出，希望引发大家更多的思考。不过关于竞品分析，有一点需要我们注意的： 竞品毕竟是竞品，它的业务场景可能和我们不一样，不能直接，需要辩证的分析它存在场景的价值和意义。

就在前段时间有老师给我们提出，学而思和新东方都在课堂上使用答题器收集学员课堂学情数据。于是我们在网上也做了相应竞品调研，看了很多课堂使用答题器的视频，发现确实通过答题器收集学员学情数据很方便，既能调动课堂氛围还能产生学情数据。但随着调研深入，同时我们也到学而思和新东方线下课堂去体验，发现他们线下面授课无一例外都没用到答题器，只有双师模式才在运用。对这一现象，我们认为，基于现有的线下小班授课的课堂答题器数据采集的迫切性不高，学员只要通过举手或老师挨个查看学员作业就能很快收集到班级学情数据。而双师模式需要一个老师覆盖几个班，上百人，同时还是远程教学，实时掌握学员学情数据就必须通过答题器这种模式实现。从另一方面答题器的成本也相对较高，不仅是软硬件投入成本，还包括课堂、课后管理成本都会带来较大麻烦。我想这也是答题器虽然已经很成熟但仍在传统课堂中使用不高的主要原因吧。

当然除以上几种需求收集方式外，我们目前还缺少通过数据反馈中收集需求，比如通过在产品中对功能进行数据埋点，获取各功能使用情况的数据，从中了解用户的使用频率及习惯来获取需求。这个部分我们会在后续开发中逐步加入，毕竟人可能会说谎，但数据不会。

需求收集完，自然是需要对需求进行分析、过滤、筛选，从中去伪存真和优先级排序。首先我们需要区分收集上来的需求是真需求还是伪需求。有时真的很难区分，很多需求看起来都无比真实，但还原到实际场景却是个伪需求。

举个我自己提伪需求的例子，当时我刚到极客，希望快速提升产品逼格，于是联系到一家自动批改数学主观题作业的公司。那家公司在做主观题数学作业批改上确实很牛，在2016年通过它们的高考机器人参加北京数学卷考试得了105分。我当时希望能通过引进它们的自动批改作业功能，帮助咱们的老师减轻工作量。但后来我把这个产品推荐给老师时，存在两种截然相反的态度，一种是认为有这个功能太好了，能帮助老师减轻工作量，甚至可以完全可以不要助教了。另一种认为其实老师批改作业的时间也占用不到太多，必要性不强。后来我们产品也经过多次内部沟通、讨论，到实际上课和作业批改场景里实地调研，发现确实有问题。一来是我们很多老师本来就有助教，这些批改作业工作会交给助教完成。即使没有助教，我们的班级都是小班教学，一个班也就十几二十个学生，每次作业也就不到半小时能搞定，而且老师在实际批改作业时还能快速了解孩子学情状况。这个自动批改作业的需求虽然从表面粗略一想完全合乎需求，但还原到真实场景里却就不是那么回事。

从这件事里也让我总结出如何识别伪需求的两个心法： 1）任何需求必须还原到具体应用场景去思考和分析 2）不要看用户怎么说，关键看用户怎么做。

需求去伪存真后，还需对真实需求进行优先级排序，分清需求的轻重缓急和节奏对产品设计也非常重要。现在我们的做法是把收集上来的每一个需求都录入到禅道（软件项目管理平台）的需求池里，每次规划下一个版本时我们会从需求池里根据轻重缓急把需求重新梳理和设计，并把需求移到下一个版本中进行排期开发。

这里需要重点讲讲我们关于需求优先级排序的方法。很多人讲把需求优先级通过紧急、重要两个维度生成四个象限， 重要紧急〉重要不紧急〉紧急不重要〉不重要不紧急 。当然，这个处理需求的原则没有问题，但没有定义什么需求重要什么需求紧急。其实紧急这个维度很好判断，取决于 交付时限、任务依赖 。交付时限是指需求最终截止期限，如果过期上线将对业务有较大影响。任务依赖是指该需求是某个流程中的一环，如果缺失这一环将对整体流程造成影响。但重要这个维度就很难的定义，我认为重要维度有两个因素： 影响范围、商业价值 。影响范围很简单，是指能满足多少用户的需求。商业价值是指该需求能对用户带来多大价值或给公司带来多大的竞争优势。

分清了重要和紧急的定义，我们就可以以量化的方式对优先级进行排序。量化的方法就是把重要和紧急两个维度满分设置为5分，分别定义需求两个维度的分值然后两项相乘就得出该需求的总分，最后根据总分再进行排序。

当然，以上需求管理办法主要适用已经上线的产品功能迭代，新项目开发需求还不适用。因为新项目开发会利用大量研发资源，也存在一定风险，而现在来自各个部门越来越多的新项目需求，这样的需求开发与否以及优先级排序就不能只在产品部内部进行决策，需要上升到公司级层面共同决策。因此后期我想可以通过在公司内部成立<产品评审委员会>的形式，召集公司产品智囊团在更大范围内对产品方向、规划进行探讨和决策。

以上是本期产品部关于需求收集、分析及管理办法的分享，过程中肯定有不完善的地方，也希望大家多多批评指正，帮助我们及我们设计的产品共同成长！

再次感谢大家利用宝贵时间看完此文，我们下期见！

8. 云南北大青鸟设计培训告诉你如何进行用户需求分类

关于需求分析的文章相信大家都看过不少了，而且对于如何获取用户需求的方式方法也很多，最常用的就是报告了。今天，大理IT培训http://www.kmbdqn.cn/主要就来简单讲解一下，当我们获得这些用户需求之后，如何根据不同的商业目的进行需求分类整理呢？

我们在进行需求分类的时候，一般有两种方式同时进行。

一、横向分类

首先来说，为什么我们拿到需求后，要把需求进行分类?因为产品在不同时期，对于不同类别的需求，会有不同的权重。我们常说，产品有起步期、发展期、稳定期。而需求根据每个公司或者产品经理的定义，可能将需求分类为：功能类、bug修复类、体验类、运营类、数据类等。

(1)产品的起步期

在产品的起步期，我们会将核心功能的需求放在权重高一些的位置，把产品的地基打好，骨架搭好，快速上线来验产品模式。别连房子还没盖好，就在纠结地砖的颜色。此时的产品经理一定要控制好自己完美偏执狂的内心冲动，对于增加新功能和体验上的需求要做好排序，此时开发核心功能，快速投入市场试错才是我们的目标。

(2)产品的发展期

到了发展期会让产品尽快做完善，或根据市场反馈对产品方向进行一定的调整，此时bug修复类、运营类的需求就放在首位了。产品投入市场后，可以收集各渠道的用户反馈，有没有切实解决目标用户的问题?产品的方向是不是正确的?在产品发展期，完善产品的过程中，对于需求更是要有把控力，做需求分析最后输出的结果就是做需求决策，学习乔帮主做简约主义者，决定不做什么比决定做什么更加重要，往往鸡肋需求，开发出来上线容易，但是要去掉，就没那么容易了。

(3)产品的稳定期

再到了产品的稳定期，产品趋于成熟，用户数也多起来了，产品不断迭代，此时提升用户体验和数据类的需求就变得很重要了。比如A/Btest，在用户量小的时候，得到的数据会有较大的出入，是不可取的。在产品的稳定期，有比较大的用户量时，可以用数据来驱动产品的迭代。

9. 需求收集的常见方法有哪些

需求收集的常见方法有：

1、用户访谈：找寻目标用户并近距离接触，最好是以会面的形式，也可以采取电话沟通等途径增进了解，目的是通过交谈了解用户真实感受。

2、调查问卷：通过线上问卷的形式（有实体的也可以线下收集，但会增加统计工作量），设置一些有关产品功能、使用方面的问题。最终通过统计收集来的问卷信息，获取用户需求分布并直观解读各项数据情况。

3、可用性测试：制作高保真demo或可操作原型提供给目标用户试用，观察用户操作使用过程，并诱导用户说出操作原因。

4、数据分析：对前端、后端设置埋点，统计并记录用户与产品相关联的数据信息，如按钮点击、UV、PV等。

(9)教育产品怎么做用户需求收集扩展阅读：

需求收集阶段完成后，你就会惊喜的发现，需求铺天盖地而来，但面对五花八门的需求该如何取舍，这可就是一门学问了。

在需求分析阶段，我们要做的是对需求初步挖掘，目的是找出用户的实际心理需求。在此过程中，实现对需求从标到本的剖析，探究表象背后的真实目的。虽然看上去很高深，其实，最终的分析结果只决定该需求是否有被记录下来的必要。

就像用户需要一匹马（需求），在对用户进行全方位的了解之后，发现他其实是想更快的前往某地（目标）。而我们的工作，正是服务于那些有出行要求的人。我们有能力满足他们的需求，在此基础之上，让用户能通过我们提供的方式更好的出行。那么，这个需求就有必要被记录下来。

10. 如何进行用户需求分析

1.概念
需求的定义包括从用户角度(系统的外部行为),以及从开发者角度(一些内部特性)来阐述需求.
关键的问题是一定要编写需求文档.我曾经目睹过一个项目中途更换了所有的开发者,客户被迫与新的需求分析者坐到一起.系统的分析人员说:"我们想与你谈谈你的需求."客户的第一反应便是:"我已经将我的要求都告诉你们前任了,现在我要的就是给我编一个系统".
百事通
而实际上,UGGs,需求并未编写成文档,因此新的分析人员不得不从头做起.所以如果只有一堆邮件、会谈记录或一些零碎的未整理的对话,你就确信你已明白用户的需求,那完全是自欺欺人.
需求的另外一种定义认为需求是"用户所需要的并能触发一个程序或系统开发工作的说明".有些需求分析专家拓展了这个概念:"从系统外部能发现系统所具有的满足于用户的特点、功能及属性等".这些定义强调的是产品是什么样的,而并非产品是怎样设计、构造的.而下面的定义则从用户需要进一步转移到了系统特性:
需求是指明必须实现什么的规格说明.它描述了系统的行为、特性或属性,是在开发过程中对系统的约束.
从上面这些不同形式的定义不难发现:并没有一个清晰、毫无二义性的"需求"术语存在,真正的"需求"实际上在人们的脑海中,这个人们主要是指客户,但一般情况下,用户并不能描述自己的需要,只就需要系统分析人员根据用户的自己语言的描述整理出相关的需要再进一步和客户核对.系统分析员和客户需要确保所有项目风险承担者在描述需求的那些名词的理解上务必达成共识.
任何文档形式的需求(例如如下将要描述的需求规格说明书)仅是一个模型,一种描述.
2.需求分析的任务
开发软件系统最为困难的部分就是准确说明开发什么.最为困难的概念性工作便是编写出详细技术需求,这包括所有面向用户、面向机器和其它软件系统的接口.同时这也是一旦做错,将最终会给系统带来极大损害的部分,并且以后再对它进行修改也极为困难.
目前,国内产品的庞杂,一家企业可能有几个系统并立运行,它们之间接口是系统开发人员最头痛的问题.
对于商业最终用户应用程序,企业信息系统和软件作为一个大系统的一部分的产品是显而易见的.但是对于我们开发人员来说,并没有编写出客户认可的需求文档,我们如何知道项目于何时结束?而如果我们不知道什么对客户来说是重要的,那我们又如何能使客户感到满意呢?
然而,即便并非出于商业目的的软件需求也是必须的.例如库、组件和工具这些供开发小组内部使用的软件.当然你可能偶尔勿需文档说明就能与其他人意见较为一致,但更常见的是出现重复返工这种不可避免的后果,而重新编制代码的代价远远超过重写一份需求文档的代价,这些血的教训正在国内的软件开发者身上发生.
近来,我遇到一个开发小组开发包括代码编辑器在内的一套内部使用的计算机辅助软件.不幸的是,当他们开发完这个工具后,发现这个工具不能打印出源代码文件,使用者当然希望有这个功能.结果这个小组只好手工抄写源代码文档以供代码检查.这说明那怕需求明确无误并构思准确,如果我们没有编写文档,软件达不到期望目标也只能是咎由自取了.
相反的情况,我曾见一个要集成到"错误跟踪系统"中的简单界面写了一页需求说明.而操作系统系统管理员在为处理脚本时发现简单的一张需求清单竟是如此有用.他们依据需求对系统进行测试时,此系统不仅非常清晰地实现了所有必需功能,而且未发现任何错误.
事实上,需求文档在开发过程中一直起指导作用.
3.需求分析过程
可把整个软件需求工程研究领域划分为需求开发和需求管理两部分更合适,如图4-1所示:
图4-1 需求工程域的层次分解示意图
需求开发可进一步分为:问题获取、分析、编写规格说明和验证四个阶段.这些子项包括软件类产品中需求收集、评价、编写文档等所有活动.需求开发活动包括以下几个方面:
确定产品所期望的用户类别.
获取每个用户类的需求.
了解实际用户任务和目标以及这些任务所支持的业务需求.
分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议解决方法和附加信息.
将系统级的需求分为几个子系统,并将需求中的一部份分配给软件组件.
了解相关质量属性的重要性.
商讨实施优先级的划分.
将所收集的用户需求编写成文档和模型.
评审需求规格说明,确保对用户需求达到共同的理解与认识,并在整个开发小组接受说明之前将问题都弄清楚.
需求管理需要"建立并维护在软件工程中同客户达成的合同" .这种合同都包含在编写的需求文档与模型中.客户的接受仅是需求成功的一半,开发人员也必须能够接受他们,并真正把需求应用到产品中.通常的需求管理活动包括:
定义需求基线(迅速制定需求文档的主体).
评审提出的需求变更、评估每项变更的可能影响从而决定是否实施它.
以一种可控制的方式将需求变更融入到项目中.
使当前的项目计划与需求一致.
估计变更需求所产生影响并在此基础上协商新的承诺,这种承诺具体体现在项目解决方案上.
让每项需求都能与其对应的设计、源代码和测试用例联系起来以实现跟踪.
在整个项目过程中跟踪需求状态及其变更情况.
以上几点说明是我总结了成功实施项目后系统分析人员的经验,同时也根据国内外的其他系统实施的相关成功经验,进行了总结.
4.需求的类型
下面这些定义是需求工程领域中常见术语的定义.
软件需求包括三个不同的层次:业务需求、用户需求和功能需求(也包括非功能需求).
1.业务需求(business requirement)反映了组织机构或客户对系统、产品高层次的目标要求,它们在项目视图与范围文档中予以说明.
2.用户需求(user requirement) 文档描述了用户使用产品必须要完成的任务,这在使用实例(use case)文档或方案脚本说明中予以说明.
3.功能需求(functional requirement)定义了开发人员必须实现的软件功能,使得用户能完成他们的任务,从而满足了业务需求.
在软件需求规格说明书 (SRS)中说明的功能需求充分描述了软件系统所应具有的外部行为.软件需求规格说明在开发、测试、质量保证、项目管理以及相关项目功能中都起了重要的作用.对一个大型系统来说,软件功能需求也许只是系统需求的一个子集,因为另外一些可能属于子系统(或软件部件).
作为功能需求的补充,软件需求规格说明还应包括非功能需求,它描述了系统展现给用户的行为和执行的操作等.它包括产品必须遵从的标准、规范和合约;外部界面的具体细节;性能要求;设计或实现的约束条件及质量属性.所谓约束是指对开发人员在软件产品设计和构造上的限制.质量属性是通过多种角度对产品的特点进行描述,从而反映产品功能.多角度描述产品对用户和开发人员都极为重要.
下面以一个字处理程序为例来说明需求的不同种类.业务需求可能是:"用户能有效地纠正文档中的拼写错误",该产品的包装盒封面上可能会标明这是个满足业务需求的拼写检查器.而对应的用户需求可能是"找出文档中的拼写错误并通过一个提供的替换项列表来供选择替换拼错的词".同时,该拼写检查器还有许多功能需求,如找到并高亮度提示错词的操作;显示提供替换词的对话框以及实现整个文档范围的替换.
从以上定义可以发现,需求并未包括设计细节、实现细节、项目计划信息或测试信息.需求与这些没有关系,它关注的是充分说明你究竟想开发什么.项目也有其它方面的需求,如开发环境需求或发布产品及移植到支撑环境的需求.尽管这些需求对项目成功也至关重要,但它们并非本书所要讨论的.
5.需求分析的原则
不重视需求过程的项目队伍将自食其果.需求工程中的缺陷将给项目成功带来极大风险,这里的"成功"是指推出的产品能以合理的价格、及时地在功能、质量上完全满足用户的期望.下面将讨论一些需求风险.
不适当的需求过程所引起的一些风险:
1. 无足够用户参与
客户经常不明白为什么收集需求和确保需求质量需花费那么多功夫,开发人员可能也不重视用户的参与.究其原因:一是因为开发人员感觉与用户合作不如编写代码有意思;二是因为开发人员觉得已经明白用户的需求了.在某些情况下,与实际使用产品的用户直接接触很困难,而客户也不太明白自己的真正需求.但还是应让具有代表性的用户在项目早期直接参与到开发队伍中,并一同经历整个开发过程.
系统人员在实践过程中,也有些感觉,在实施一家公司的项目时,若无足够的用户参与,系统人员获得的需求是片面的,不完整的,这样系统在需求之初就埋下风险.
2. 用户需求的不断增加
在开发中若不断地补充需求,项目就越变越庞大以致超过其计划及预算范围.计划并不总是与项目需求规模与复杂性、风险、开发生产率及需求变更实际情况相一致,这使得问题更难解决.实际上,问题根源在于用户需求的改变和开发者对新需求所作的修改.
要想把需求变更范围控制到最小,必须一开始就对项目视图、范围、目标、约束限制和成功标准给予明确说明,并将此说明作为评价需求变更和新特性的参照框架.说明中包括了对每种变更进行变更影响因素分析的变更控制过程,有助于所有风险承担者明白业务决策的合理性,即为何进行某些变更,相应消耗的时间、资源或特性上的折中.
产品开发中不断延续的变更会使其整体结构日渐紊乱,补丁代码也使得整个程序难以理解和维护.插入补丁代码使模块违背强内聚、松耦合的设计原则,特别是如果项目配置管理工作不完善的话,收回变更和删除特性会带来问题.如果你尽早地区别这些可能带来变更的特性,你就能开发一个更为健壮的结构,并能更好地适应它.这样设计阶段需求变更不会直接导致补丁代码,同时也有利于减少因变更导致质量的下降.
3. 模棱两可的需求
模棱两可是需求规格说明中最为可怕的问题.它的一层含义是指诸多读者对需求说明产生了不同的理解;另一层含义是指单个读者能用不止一个方式来解释某个需求说明.
模棱两可的需求会使不同的风险承担者产生不同的期望,它会使开发人员为错误问题而浪费时间,并且使测试者与开发者所期望的不一致.一位系统测试人员曾告诉我,她所在的测试组经常对需求理解有误,以致不得不重写许多测试用例并重做许多测试.
处理模棱两可需求的一种方法是组织好负责从不同角度审查需求的队伍.仅仅简单浏览一下需求文档是不能解决模棱两可问题的.如果不同的评审者从不同的角度对需求说明给予解释,但每个评审人员都真正了解需求文档,这样二义性就不会直到项目后期才被发现,那时再发现的话会使得更正代价很大.
4. 不必要的特性
"画蛇添足"是指开发人员力图增加一些"用户欣赏"但需求规格说明中并未涉及的新功能.经常发生的情况是用户并不认为这些功能性很有用,以致在其上耗费的努力"白搭"了.开发人员应当为客户构思方案并为他们提供一些具有创新意识的思路,具体提供哪些功能要在客户所需与开发人员在允许时限内的技术可行性之间求得平衡,开发人员应努力使功能简单易用,而不要未经客户同意,擅自脱离客户要求,自作主张.
同样,客户有时也可能要求一些看上去很"酷",但缺乏实用价值的功能,而实现这些功能只能徒耗时间和成本.为了将"画蛇添足"的危害尽量减小,应确信:你明白为什么要包括这些功能,以及这些功能的"来龙去脉",这样使得需求分析过程始终是注重那些能使用户完成他们业务任务的核心功能.
5. 过于精简的规格说明
有时,客户并不明白需求分析有如此重要,于是只作一份简略之至的规格说明,仅涉及了产品概念上的内容,然后让开发人员在项目进展中去完善,结果很可能出现的是开发人员先建立产品的结构之后再完成需求说明.这种方法可能适合于尖端研究性的产品或需求本身就十分灵活的情况.但在大多数情况下,这会给开发人员带来挫折(使他们在不正确的假设前提和极其有限的指导下工作),也会给客户带来烦恼(他们无法得到他们所设想的产品).
6. 忽略了用户分类
大多数产品是由不同的人使用其不同的特性,使用频繁程度也有所差异,使用者受教育程度和经验水平也不尽相同.如果你不能在项目早期就针对所有这些主要用户进行分类的话,必然导致有的用户对产品感到失望.例如,菜单驱动操作对高级用户太低效了,但含义不清的命令和快捷键又会使不熟练的用户感到困难.
7. 不准确的计划
据统计,导致需求过程中软件成本估计极不准确的原因主要有以下五点:频繁的需求变更、遗漏的需求、与用户交流不够、质量低下的需求规格说明和不完善的需求分析.
对不准确的要求所提问题的正确响应是"等我真正明白你的需求时,我就会来告诉你".基于不充分信息和未经深思的对需求不成熟的估计很容易为一些因素左右.要作出估计时,最好还是给出一个范围.未经准备的估计通常是作为一种猜测给出的,听者却认为是一种承诺.因此我们要尽力给出可达到的目标并坚持完成它.
6.需求分析人员和用户的合作关系
优秀的软件产品是建立在优秀的需求基础之上的.而高质量的需求来源于客户与开发人员之间有效的交流与合作.通常,开发人员与客户或客户代理人,如市场人员间的关系反而会成为一种对立关系.双方的管理者都只想自己的利益而搁置用户提供的需求从而产生摩擦,在这种情况下,不会给双方带来一点益处.
只有当双方参与者都明白要成功自己需要什么,同时也应知道要成功合作方需要什么时,才能建立起一种合作关系.由于项目压力与日渐增,所有风险承担者有着一个共同的目标这一点容易被遗忘.其实大家都想开发出一个既能实现商业价值,又能满足用户需要,还能使开发者感到满足的优秀软件产品.
软件客户需求权利书列出了十条关于客户在项目需求工程实施中与分析人员、开发人员交流时的合法要求.每一项权利都对应着软件开发人员、分析人员的义务.而软件客户需求义务书也列出了十条关于客户在需求过程中应承担的义务.如果愿意,可以将其作为开发人员的权利书.
客户有如下权利:
1:要求分析人员使用符合客户语言习惯的表达
需求讨论应集中于业务需要和任务,故要使用业务术语,你应将其教给分析人员,而你 不一定要懂得计算机的行业术语.
2:要求分析人员了解客户的业务及目标
通过与用户交流来获取用户需求、分析人员才能更好地了解你的业务任务和怎样才能使产品更好地满足你的需要.这将有助于开发人员设计出真正满足你的需要并达到你期望的优秀软件.为帮助开发人员和分析人员,可以考虑邀请他们观察你或你的同事是怎样工作的.如果新开发系统是用来替代已有的系统,那么开发人员应使用一下目前的系统,这将有利于他们明白目前系统是怎样工作的,其工作流程的情况,以及可供改进之处.
3:要求分析人员编写软件需求规格说明
分析人员要把从你和其他客户那里获得的所有信息进行整理,以区分开业务需求及规范、功能需求、质量目标、解决方法和其它信息.通过这些分析就能得到一份软件需求规格说明.而这份软件需求规格说明便在开发人员和客户之间针对要开发的产品内容达成了协议.软件需求规格说明书可以用一种你认为易于翻阅和理解的方式组织编写.要评审编写出的规格说明以确保它们准确而完整地表达了你的需求.一份高质量的软件需求规格说明能有助于开发人员开发出真正需要的产品.
4:要求得到需求工作结果的解释说明
分析人员可能采用了多种图表作为文字性软件需求规格说明的补充.因为如工作流程图那样的图表能很清楚地描述出系统行为的某些方面.所以需求说明中的各种图表有着极高的价值.虽然它们不太难于理解,但是你很可能对此并不熟悉.因此可以要求分析人员解释说明每张图表的作用或其它的需求开发工作结果和符号的意义,及怎样检查图表有无错误及不一致等.
5:要求开发人员尊重你的意见
如果用户与开发人员之间不能相互理解,那关于需求的讨论将会有障碍,共同合作能使大家"兼听则明".参与需求开发过程的客户有权要求开发人员尊重他们并珍惜他们为项目成功所付出的时间.同样,客户也应对开发人员为项目成功这一共同目标所作出的努力表示尊重与感激.
6:要求开发人员对需求及产品实施提供建议,拿出主意
通常,客户所说的"需求"已是一种实际可能的实施解决方案,分析人员将尽力从这些解决方法中了解真正的业务及其需求,同时还应找出已有系统不适合当前业务之处,以确保产品不会无效或低效.在彻底弄清业务领域内的事情后,分析人员有时就能提出相当好的改进方法.有经验且富有创造力的分析人员还能提出增加一些用户并未发现的很有价值的系统特性.
7:描述产品易使用的特性
你可以要求分析人员在实现功能需求的同时还要注重软件的易用性.因为这些易用特性或质量属性能使你更准确、高效地完成任务.例如,客户有时要求产品要"用户友好"或"健壮"或"高效率",但这对于开发人员来说,太主观了并无实用价值.正确的应是:分析人员通过询问和调查了解客户所要的友好、健壮、高效所包含的具体特性.
8:调整需求,允许重用已有的软件组件
需求通常要有一定的灵活性.分析人员可能发现已有的某个软件组件与你描述的需求很相符.在这种情况下,分析人员应提供一些修改需求的选择以便开发人员能够在新系统开发中重用一些已有的软件.如果有可重用的机会出现,同时你又能调整你的需求说明,那就能降低成本和节省时间,而不必严格按原有的需求说明开发.所以说,如果想在产品中使用一些已有的商业常用组件,而它们并不完全适合你所需的特性,这时一定程度上的需求灵活性就显得极为重要了.
9:获得满足客户功能和质量要求的系统
每个人都希望项目获得成功.但这不仅要求你要清晰地告知开发人员关于系统"做什么"所需的所有信息,而且还要求开发人员能通过交流了解清楚取舍与限制.一定要明确说明你的假设和潜在的期望.否则,开发人员开发出的产品很可能无法让你满意.
客户有下列义务:
1:给分析人员讲解你的业务
分析人员要依靠你给他们讲解的业务概念及术语.但你不能指望分析人员会成为该领域的专家,而只能让他们真正明白你的问题和目标.不要期望分析人员能把握你们业务的细微与潜在之处,他们很可能并不知道那些对于你和你的同事来说理所当然的"常识".
2:抽出时间清楚地说明并完善需求
客户很忙,经常在最忙的时候还得参与需求开发.但无论如何,你有义务抽出时间参与"头脑风暴"会议的讨论,接受采访或其它获取需求的活动.有时分析人员可能先以为明白了你的观点,而过后发现还需要你的讲解.这时,请耐心一些对待需求和需求的精化工作过程中的反复,因为它是人们交流中的很自然的现象,何况这对软件产品的成功极为重要.
3:准确而详细地说明需求
编写一份清晰、准确的需求文档是很困难的.由于处理细节问题不但烦人而且又耗时,故很容易留下模糊不清的需求.但是,在开发过程中,必须得解决这种模糊性和不准确性.而你恰是为解决这些问题作出决定的最佳人选.不然的话,你就只好靠开发人员去正确猜测了.在需求规格说明中暂时加上待定(to be determined, TBD也可采用汉语拼音略写"DQD:待确定")的标志是个不错的办法.用该标志可指明了哪些需要进一步探讨、分析或增加信息的地方.不过,有时也可能因为某个特殊需求难以解决或没有人愿意处理它而注上TBD标志.尽量将每项需求的内容都阐述清楚,以便分析人员能准确的将其写进软件需求规格说明中.如果你一时不能准确表述,那就得允许获取必要的准确信息这样一个过程.通常使用所谓的原型技术.通过开发的原型,你可以同开发人员一起反复修改,不断完善需求定义.
4:及时地作出决定
正如一位建筑师为你修建房屋,分析人员将要求你做出一些选择和决定.这些决定包括来自多个用户提出的处理方法或在质量特性冲突和信息准确度中选择折衷方案等.有权做出决定的客户必须积极地对待这一切,尽快做处理、做决定.因为开发人员通常只有等你做出了决定才能行动,而这种等待会延误项目的进展.
5:尊重开发人员的需求可行性及成本评估
所有的软件功能都有其成本价格,开发人员最适合预算这些成本(尽管许多开发人员并不擅长评估预测).你所希望的某些产品特性可能在技术上行不通,或者实现它要付出极为高昂的代价.而某些需求试图在操作环境中要求不可能达到的性能或试图得到一些根本得不到的数据,开发人员会对此作出负面的评价意见,你应该尊重他们的意见.有时,你可以重新给出一个在技术上可行、实现上便宜的需求,例如,要求某个行为在"瞬间"发生是不可行的,但换种更具体的时间需求说法("在50ms以内",但若没有准确的技术分析不能轻易下结论),这就可以实现了.
6: 划分需求优先级别
大多数项目没有足够的时间或资源来实现功能性的每个细节.决定哪些特性是必要的,哪些是重要的,哪些是好的,是需求开发的主要部分.只能由你来负责设定需求优先级,因为开发者并不可能按你的观点决定需求优先级.开发者将为你确定优先级提供有关每个需求的花费和风险的信息.当你设定优先级时,你帮助开发者确保在适当的时间内用最小的开支取得最好的效果.在时间和资源限制下,关于所需特性能否完成或完成多少应该尊重开发人员的意见.尽管没有人愿意看到自己所希望的需求在项目中未被实现,但毕竟是要面对这种现实的.业务决策有时不得不依据优先级来缩小项目范围或延长工期,或增加资源,或在质量上寻找折衷.
7:评审需求文档和原型
正如我们将在第1 4章讨论的,无论是正式的还是非正式的方式,对需求文档进行评审都会对软件质量提高有所帮助.让客户参与评审才能真正鉴别需求文档是否的确完整、正确说明了期望的必要特性.评审也给客户代表提供一个机会,给需求分析人员带来反馈信息以改进他们的工作.如果你认为编写的需求文档不够准确,就有义务尽早告诉分析人员并为改进提供建议.通过阅读需求规格说明,很难想象实际的软件是什么样子的.更好的方法是先为产品开发一个原型.这样你就能提供更有价值的反馈信息给开发人员,帮助他们更好地理解你的需求.必须认识到:原型并非是一个实际产品,但开发人员能将其转变、扩充成功能齐全的系统.
8:需求出现变更要马上联系
不断的需求变更会给在预定计划内完成高质量产品带来严重的负面影响.变更是不可避免的,但在开发周期中变更越在晚期出现,其影响越大.变更不仅会导致代价极高的返工,而且工期也会被迫延误,特别是在大体结构已完成后又需要增加新特性时.所以一旦你发现需要变更需求时,请一定立即通知分析人员.
9:应遵照开发组织处理需求变更的过程
为了将变更带来的负面影响减少到最低限度,所有的参与者必须遵照项目的变更控制过程.这要求不放弃所有提出的变更,对每项要求的变更进行分析、综合考虑,最后作出合适的决策以确定将某些变更引入项目中.
10:尊重开发人员采用的需求工程过程
软件开发中最具挑战性的莫过于收集需求并确定其正确性.分析人员采用的方法有其合理性.也许你认为需求过程不太划算,但请相信花在需求开发上的时间是"很有价值"的.如果你理解并支持分析人员为收集、编写需求文档和确保其质量所采用的技术,那么整个过程将会更为顺利.尽管去询问分析人员为什么他们要收集某些信息,或参与与需求有关的活动.
系统分析人员在开发过程中可能会遇到以下问题,一些很忙的客户可能不愿意积极参与需求过程,而缺少客户参与将很可能导致不理想的产品.故一定要确保需求开发中的主要参与者都了解并接受他们的义务.如果遇到分歧,通过协商以达成对各自义务的相互理解,这样能减少今后的摩擦.
7.需求文档
需求开发的最终成果是:客户和开发小组对将要开发的产品达成一致协议.协议综合了业务需求、用户需求和软件功能需求.就像我们早先所看到的,项目视图和范围文档包含了业务需求,而使用实例文档则包含了用户需求.你必须编写从使用实例派生出的功能需求文档,还要编写产品的非功能需求文档,包括质量属性和外部接口需求.只有以结构化和可读性方式编写这些文档,并由项目的风险承担者评审通过后,各方面人员才能确信他们所赞同的需求是可靠的.
你可以使用以下三种方法编写软件需求规格说明:
用好的结构化和自然语言编写文本型文档.
建立图形化模型,这些模型可以描绘转换过程、系统状态和它们之间的变化、数据关系、逻辑流或对象类和它们的关系.
编写形式化规格说明,这可以通过使用数学上精确的形式化逻辑语言来定义需求.
由于形式化规格说明具有很强的严密性和精确度,因此,所使用的形式化语言只有极少数软件开发人员才熟悉,更不用说客户了.虽然结构化的自然语言具有许多缺点,但在大多数软件工程中,它仍是编写需求文档最现实的方法.包含了功能和非功能需求的基于文本的软件需求规格说明已经为大多数项目所接受.图形化分析模型通过提供另一种需求视图,增强了软件需求规格说明.