需求开发和管理
白云庄主
这个作者很懒,什么都没留下…
展开
-
需求开发中常见问题汇总
需求开发中常见问题汇总:1.研发从早忙到晚,产品开发的不少,但市场成功的产品屈指可数,开发的越多,死得越快2.产品开发闭门造车,关注技术,不关注客户;产品开发出来才找客户、找卖点3.了解市场的不懂技术,懂技术的不了解市场,不知道需求应该谁负责4.需求准确把握决定产品成败,但没有人关注需求,即使有时想关注也不知道如何关注5.需求的表达不够结构化,充斥着“故事会”格式的需求,直接影响了不同团队对需转载 2009-08-10 17:01:00 · 1174 阅读 · 0 评论 -
需求的概念和层次
什么是需求?需求就是以一种清晰、简洁、一致且无二义性的方式,对待开发的各个有意义方面的陈述的集合。需求必须包含足够的信息,足以使开发设计人员能产生一个让用户接受的产品。 为做好需求的开发与管理工作,保证软件产品质量,需要明确需求的层次。从应用角度看软件需求,可以分为业务需求、用户需求和功能需求三个层次。 (1)业务需求(Business Requiremen原创 2010-04-09 15:23:00 · 1078 阅读 · 0 评论 -
频繁需求变更的原因分析和解决之道
需求变更的原因多种多样,经常发生的主要有一下几种:1、因竞争、成本等因素,工期已经确定且极不合理;2、用户在需求开发期间技术不足,提出不合理需求或用户需求不明确;3、项目组对业务不熟悉,或者没有与用户密切配合,需求分析工作不细致;4、项目组没有很好地实施需求管理;解决手段:1、通常情况下,开发方的负责人需要有一些社交技巧来减缓矛盾。例如,首先承认客户提出的需求变更请求是合理的,再阐述己方的难处,最原创 2010-04-09 16:57:00 · 8065 阅读 · 0 评论 -
SERU模型威力初现!
<br />SERU模型威力初现!编写需求规格说明书越来越顺手!希望能再依此方法锻炼两三个项目,必定效果大好。原创 2010-12-15 15:02:00 · 955 阅读 · 0 评论 -
需求捕获要务
需求捕获是“剥洋葱”而不是“切洋葱”:捕获时切忌“一刀切到底”,一次访谈就从业务到活动,又从活动到界面、字段细节;二是应该从宏观到微观,先找到头绪(主题域、业务事件),然后理清框架和脉络(即结构框架的领域模型、行为脉络的用例模型),然后再填充细节。原创 2010-12-23 15:37:00 · 589 阅读 · 0 评论 -
需求基线管理
<br />需求基线定义:团队成员已经承诺将在某一特定产品版本中实现的功能性和非功能性需求的一组集合。<br />软件开发的中后期开发效率会产生大幅度的下降,其实开发团队经常处于“非计划”状态是个比较重要的原因之一,而救火队式的工作必将导致无法计划。<br />分阶段开发与迭代开发的区别:<br />分阶段开发中的每个阶段的结束时间不是固定的,必须将相应的内容开发完成后才结束;另外每个阶段内通常是相应变更的;<br />迭代开发中的每次迭代的结束时间是固定的,没有完成的任务将会放到下次迭代,每次迭代内通常是原创 2010-12-23 11:11:00 · 6973 阅读 · 0 评论 -
SERU戒语
需求规格说明书应该采用业务导向的树型层次结构来组织。对于需求分析员而言,真正的专业主义是基于业务利益(解决问题、创造机会、提高管控力)的沟通。缓解沟通失真最有效的方法是及时复述。需求分析的本质在于业务分析,而非技术分析。业务场景是需求之魂。需求分析人员对于技术方法论的评价重在适用性。对预设计的需求是评判敏捷方法论是否适用的关键。流程分析(业务事件)是OLTP系统的关键线索和主要视图。报表分析是MIS系统的关键线索和主要视图。决策场景是DSS系统的关键线索和主要视图。工作场景是专家系统的关键线索和主要视图。高转载 2010-12-28 10:35:00 · 920 阅读 · 0 评论 -
《人月神话》笔记
<br />“表面上看起来好像没有任何一个单独的问题会导致困难,每个问题都能被解决,但是当他们相互纠缠和积累在一起的时候,团队的行动就会变得越来越慢。”翻译 2010-11-04 09:58:00 · 475 阅读 · 0 评论