怎么办？需求啊需求

什么是软件需求，什么是功能需求？

我们的软件产品或者项目，其需求都有三个层级和三个方面。一软件需求包括3个不同的层次――业务需求、用户需求和功能需求。业务需求（Businessrequirement）表示组织或客户高层次的目标。业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业 务需求描述了组织为什么要开发一个系统，即组织希望达到的目标。使用前景和范围（visionandscope）文档来记录业务需求，这份文档有时也被称作项目轮廓图或市场需求（project cha

从哪采集需求？这十方面就够了

人们常常把产品经理的工作重点落在需求分析上，透过现象看人性看本质，而忽略了需求采集的工作。以至于在很多小型创业公司，需求往往仅出自几个公司成员拍脑袋。所谓巧妇难为无米之炊，如果需求采集没有针对性，采集目标不够典型，数量过少，采集方法不科学，没有整理跟进，光靠几人拍脑袋，拍出几个自以为的用户需求，我想，再牛的产品经理也分析不出你所谓的痛点在哪，除了你拍疼的脑袋。用户访谈适用于产品规划阶段，通常是一对一聊天的形式。围绕特点的话题，我们问，用户说，从中了解用户的观点。从用户的角度出发，确定产品的研究方向。焦点小组是我们与用户进行一对多聊天的沟通形式。相比用户访谈，它能在较短时间内从用户身上获取较多的

产品需求沟通出问题怎么办？

产品制作的流程中，发现需求并定义需求是首要环节，假如产品需求沟通出现问题了怎么办?你需要解决三个问题，避免含糊性，定义需求和功能，明确功能和属性。含混性，指的是不清晰的程度。在项目开发过程中，含混性会一直贯穿整个过程。从需求出现到把需求变成产品，含混性始终影响着整个项目。因为含混性的存在，产品经理必须注重沟通和理解，尽可能准确地探索需求和传达需求，而工程师们则需要尽可能理解需求，在产品诞生之后，产品经理还需要关注用户需求是否发生了变化。简单地说，含混性越大，项目风险也会越大。著名思想家温伯格提到一个计算含混性的公式：含混性=实现需求的最大花费/实现需求的最小花费。这个公式在项目评估的时候非常有

需求评审之前，需求挖掘和需求管理怎么做？

很多刚入门的产品经理都会将大量的时间放在产品原型上面，以为画好原型就能够胜任产品经理的职位了。而我们也经常能够在一些产品经理的招聘中任职要求中写着：“熟悉使用Axure、Mindmanager、Viso，能够单独画产品原型”。于是很多人都是从学习使用Axure画原型开始走上产品之路的。然而，如果从做产品的流程来看，需求才是做产品的第一步。而且一个好的需求也是做出优秀产品成就优秀产品经理的前提。圈内人经常会说到“需求”、“痛点”这样的词语，那么究竟什么是“需求”呢?我先来举个栗子：1、我想吃饭，但是我不想自己煮饭，也不想出去吃，怎样才能做到不用煮饭、不用出去也能吃到好吃的饭菜?

需求如何转变为系统测试用例?

需求如何转变为系统测试用例?  软件测试　　年前对一个新项目的需求做了一个分析，将分析结果整理好了。今天是上班的第一天，开始将需求内容转变为测试用例。　　目前需求测试点是64个，预计拆分完后要达到2倍。又有一个新的问题难住了我。　　这么多的用例，如何来进行评审?如何让执行用例的人能够很快的理解这些用例内容?　　我想了想，计划将每个需求点与测试用例相对应，争取做到一对多的关系。然后再利用总体的系统流程图来把整个测试过程贯穿起来。这个需求与系统测试用例的文档正在编写中，好了就穿上来，希望大家讨论，更盼望有更好的办法，能够写出逻辑关系清晰，描述简捷明了的测试用例。原文转自：http://www.lt