掌握需求过程

驿轳 2016-12-21 0

真的非常详细，在具体实践里面可以继续详加练习。很多问题真的想得非常周到。

驿轳 2016-12-21 0

真的非常详细，在具体实践里面可以继续详加练习。很多问题真的想得非常周到。

西边的大石 2009-03-30 0赞

书看完了，2个月的时间。
IceBreaker项目贯穿始终；兔子、骏马、大象若隐若现。
很喜欢5.8找出工作的本质：“需求分析师必须能够分离问题的本质和所有建议的解决方案”。是的，在之前我做的需求分析中解决方案，总是规格说明书的重点。这样做的缺点是，扼杀了许多好的解决方案。找出工作本质的好处是：“如果关注真正的问题，解决方案就不必突然变化，而这个变化只是因为成功的用户用它来完成它本来就一直该完成的工作”。

需求突然有了新的要求：需求是测试过的，如果被接受，将成为规格说明书的一部分。需求要是可以验证的。你可以使用CRUD（Crete Reference Update Delete）方法验证。

比书还重要的是模版

黑枪王荣格 2008-10-11 0赞

本书出版的唯一目的，就是作者为了推销自己所创立的那个模版而已，其实大家模版都差不多，没什么任何特别的地方，还不如几年前温伯格的作品。

note

我是啄。 2011-05-08 1赞

需求以一种无关技术的方式表达出来，这样做是有意避免对解决方案的设计产生影响。

产品构建好的时候，它的需求不会冻结。

敏捷软件开发宣言：
通过实践以及帮助别人实践，我们正在发现软件开发更好的方式。通过这项工作我们认识到以下一些价值：（1）个人和他们之间的互动胜过过程和工具；（2）工作的软件胜过面面俱到的文档；（3）客户协作胜过合同谈判；（4）响应变化胜过遵循计划。

需求来自于人，所以与人互动得越好，越能更好地收集需求。

如果以敏捷原则作为指导，就不至于仅仅因为事情是预先描述的就去做，而是会寻找机会更快地提供有用的功能。

功能性需求是产品必须完成的那些事。非功能需求是产品必须具备的属性或品质。限制条件是一个全局问题，约束着所有的需求。

不论是要构造用户定制的系统，还是组件集成的系统，或者使用商业上架销售的软件包，或者对已有的系统进行改动，都需要发现、捕获、交流需求。

理解顾客及其组织机构需求的最快方式不是通过键盘，而是通过白板。

正因为产品自身有一个演进过程，可能会决定先构造一个包含功能较少的早期版本，然后通过所计划的一系列发行版本来增强它。

需求过程不仅仅是用于新产品。

“如果我们必须重做一次，哪些地方会做的不同？”

我们从各种不同项目中提炼出我们的经验，提供一组适用于所有项目的基本活动和提交产物。

进入和离开一部分工作的信息决定了这部分工作做什么。

设定工作的范围意味着确定打算研究哪些工作、哪些工作与之有关，哪些信息流构成了工作之间的联系。

当设定范围时，是在确定哪些工作将研究、哪些工作不会去研究。

工作上下文的范围显示了工作的职责和相邻系统的职责起止之处。

可以将“目的、好处、度量标准”（Purpose， Advantage，Measurement，PAM）作为助记符，帮助发现并分析目标。

项目的目标不仅仅要解决问题，还要提供业务上的好处。

不论用哪种技术实现，本质总是存在。

网罗需求：业务事件（根据外部请求来划分工作），当前情况建模（检查遗留系统找到可复用的请求），做学徒（花时间与专家一起工作），观察结构和模式（确定可复用的需求），风险承担者访谈（能够关注细节问题），找出工作的本质（找到真正的问题），业务用例研讨会（让相关的风险承担者关注与业务事件的最佳反应），创造性研讨会（让团队一起来发现创造性需求），头脑风暴（促进创造性和创新），用户代表（利用一个复合的虚拟人物来代表客户/顾客），思维图（一种有效的计划/记录技巧），墙纸，录像和照相，wiki、blog和论坛（让所有风险承担者贡献想法），文档考古学（使用来自原有文档和文件的证据）。。。

第7章

素素 2015-02-17 2赞

理解真正的问题
1.需求是有生命的，wbs，需求是可以被验证的
2.我知道这是我提出的，但这不是我想要的
3.在一天结束时，如果软件不能满足用户的需要，无论他的创建方法如何，他都是糟糕的软件
4.物理事实是公司出租dvd，但如果据此抽象，你会看到netfilx是出租电影的公司
5.如果我有一小时来拯救世界，我会花五十九分钟清理问题
6.从所有提出的解决方案中分离出问题本质
7.无论技术如何实现，本质总是存在的
8.如果气象站传送读取失败，产品应该发出鸣叫声，并在屏幕上发出闪烁的信息
  本质：如果气象站传送读取失败，产品应该提醒维修人员
9.乘客将在触摸屏的路线上选择目的地
   本质：产品将确定乘客的目的地
10.敏捷技术的目标是尽可能的高效的得到解决方案
11.如果你关注真正的问题，你的解决方案就不必废弃与修改，它本该一直一直在完成用户的工作，以后的用户不必修改
抽象：
12.业务过程是组活动，不论你如何实现
13.对于任何的技术（无论现在多么流行，多么有吸引力）你都必须从技术中抽象出来，看到他背后，本质的目的
   “不要问技术能做什么，而要问技术在做什么”

去除泳道
14.部门存在意义：这是因为我们雇人来完成这项工作，很少有人具有全部的能力，能完成组织结构里面的所有任务
15.废除泳道，查看端到端的业务。我们强烈建议你废弃泳道，放眼整个泳池
16.客户常常要求对他们的系统进行增量式改进：“我想要现在拥有的东西，但还要加一些信息，还要再快点”，如果只提供这些能力，你就错过创新的跳跃，项目不会得到出色的结果。他们只提供了客户要求的东西，结果破产了

如何创新
  三样东西是人们想要的：他们愿意为之付出可任意支配的金钱：快乐，面子，和方便
人们愿意为方便付钱。
你必须通过客户的眼睛来看产品，基本的规则是忽略自己的想法，而考虑客户的想法。
通过客户的眼睛来看建议的产品：你能让它更方便吗？

系统思考
18.看那些部门，但是要看那些部分的聚合，
19.你作为业务分析师的职责就引导探求未来的工作
20.我们必须理解工作是如何进行的
21.视野太狭隘，只看建议的产品，会妨碍系统思考。
22.任何系统都是一组相互连接的功能，一项功能的输出可能影响另一项功能。就像一组齿轮，当一项功能在运作，它导致其他功能做出反应
23.不要只看解决方案，后退一步，看看你想改进的整个工作
24.系统思考是考虑整个业务，它的组成是如何交互，最重要的是他们之间如何“影响”
25.业务中的一些活动相互影响，这种影响用灰色箭头表示。系统思考就是系统整体的输出，并理解每个活动的结果

价值
你必须确定这个组织结构重视什么价值
价值可以认为有三个因素组成：回报，处罚和成本

第7章

素素 2015-02-17 2

理解真正的问题
1.需求是有生命的，wbs，需求是可以被验证的
2.我知道这是我提出的，但这不是我想要的
3.在一天结束时，如果软件不能满足用户的需要，无论他的创建方法如何，他都是糟糕的软件
4.物理事实是公司出租dvd，但如果据此抽象，你会看到netfilx是出租电影的公司
5.如果我有一小时来拯救世界，我会花五十九分钟清理问题
6.从所有提出的解决方案中分离出问题本质
7.无论技术如何实现，本质总是存在的
8.如果气象站传送读取失败，产品应该发出鸣叫声，并在屏幕上发出闪烁的信息
  本质：如果气象站传送读取失败，产品应该提醒维修人员
9.乘客将在触摸屏的路线上选择目的地
   本质：产品将确定乘客的目的地
10.敏捷技术的目标是尽可能的高效的得到解决方案
11.如果你关注真正的问题，你的解决方案就不必废弃与修改，它本该一直一直在完成用户的工作，以后的用户不必修改
抽象：
12.业务过程是组活动，不论你如何实现
13.对于任何的技术（无论现在多么流行，多么有吸引力）你都必须从技术中抽象出来，看到他背后，本质的目的
   “不要问技术能做什么，而要问技术在做什么”

去除泳道
14.部门存在意义：这是因为我们雇人来完成这项工作，很少有人具有全部的能力，能完成组织结构里面的所有任务
15.废除泳道，查看端到端的业务。我们强烈建议你废弃泳道，放眼整个泳池
16.客户常常要求对他们的系统进行增量式改进：“我想要现在拥有的东西，但还要加一些信息，还要再快点”，如果只提供这些能力，你就错过创新的跳跃，项目不会得到出色的结果。他们只提供了客户要求的东西，结果破产了

如何创新
  三样东西是人们想要的：他们愿意为之付出可任意支配的金钱：快乐，面子，和方便
人们愿意为方便付钱。
你必须通过客户的眼睛来看产品，基本的规则是忽略自己的想法，而考虑客户的想法。
通过客户的眼睛来看建议的产品：你能让它更方便吗？

系统思考
18.看那些部门，但是要看那些部分的聚合，
19.你作为业务分析师的职责就引导探求未来的工作
20.我们必须理解工作是如何进行的
21.视野太狭隘，只看建议的产品，会妨碍系统思考。
22.任何系统都是一组相互连接的功能，一项功能的输出可能影响另一项功能。就像一组齿轮，当一项功能在运作，它导致其他功能做出反应
23.不要只看解决方案，后退一步，看看你想改进的整个工作
24.系统思考是考虑整个业务，它的组成是如何交互，最重要的是他们之间如何“影响”
25.业务中的一些活动相互影响，这种影响用灰色箭头表示。系统思考就是系统整体的输出，并理解每个活动的结果

价值
你必须确定这个组织结构重视什么价值
价值可以认为有三个因素组成：回报，处罚和成本

note

我是啄。 2011-05-08 1

需求以一种无关技术的方式表达出来，这样做是有意避免对解决方案的设计产生影响。

产品构建好的时候，它的需求不会冻结。

敏捷软件开发宣言：
通过实践以及帮助别人实践，我们正在发现软件开发更好的方式。通过这项工作我们认识到以下一些价值：（1）个人和他们之间的互动胜过过程和工具；（2）工作的软件胜过面面俱到的文档；（3）客户协作胜过合同谈判；（4）响应变化胜过遵循计划。

需求来自于人，所以与人互动得越好，越能更好地收集需求。

如果以敏捷原则作为指导，就不至于仅仅因为事情是预先描述的就去做，而是会寻找机会更快地提供有用的功能。

功能性需求是产品必须完成的那些事。非功能需求是产品必须具备的属性或品质。限制条件是一个全局问题，约束着所有的需求。

不论是要构造用户定制的系统，还是组件集成的系统，或者使用商业上架销售的软件包，或者对已有的系统进行改动，都需要发现、捕获、交流需求。

理解顾客及其组织机构需求的最快方式不是通过键盘，而是通过白板。

正因为产品自身有一个演进过程，可能会决定先构造一个包含功能较少的早期版本，然后通过所计划的一系列发行版本来增强它。

需求过程不仅仅是用于新产品。

“如果我们必须重做一次，哪些地方会做的不同？”

我们从各种不同项目中提炼出我们的经验，提供一组适用于所有项目的基本活动和提交产物。

进入和离开一部分工作的信息决定了这部分工作做什么。

设定工作的范围意味着确定打算研究哪些工作、哪些工作与之有关，哪些信息流构成了工作之间的联系。

当设定范围时，是在确定哪些工作将研究、哪些工作不会去研究。

工作上下文的范围显示了工作的职责和相邻系统的职责起止之处。

可以将“目的、好处、度量标准”（Purpose， Advantage，Measurement，PAM）作为助记符，帮助发现并分析目标。

项目的目标不仅仅要解决问题，还要提供业务上的好处。

不论用哪种技术实现，本质总是存在。

网罗需求：业务事件（根据外部请求来划分工作），当前情况建模（检查遗留系统找到可复用的请求），做学徒（花时间与专家一起工作），观察结构和模式（确定可复用的需求），风险承担者访谈（能够关注细节问题），找出工作的本质（找到真正的问题），业务用例研讨会（让相关的风险承担者关注与业务事件的最佳反应），创造性研讨会（让团队一起来发现创造性需求），头脑风暴（促进创造性和创新），用户代表（利用一个复合的虚拟人物来代表客户/顾客），思维图（一种有效的计划/记录技巧），墙纸，录像和照相，wiki、blog和论坛（让所有风险承担者贡献想法），文档考古学（使用来自原有文档和文件的证据）。。。

需求的本质很重要

西边的大石 2009-03-30 0

书看完了，2个月的时间。
IceBreaker项目贯穿始终；兔子、骏马、大象若隐若现。
很喜欢5.8找出工作的本质：“需求分析师必须能够分离问题的本质和所有建议的解决方案”。是的，在之前我做的需求分析中解决方案，总是规格说明书的重点。这样做的缺点是，扼杀了许多好的解决方案。找出工作本质的好处是：“如果关注真正的问题，解决方案就不必突然变化，而这个变化只是因为成功的用户用它来完成它本来就一直该完成的工作”。

需求突然有了新的要求：需求是测试过的，如果被接受，将成为规格说明书的一部分。需求要是可以验证的。你可以使用CRUD（Crete Reference Update Delete）方法验证。

比书还重要的是模版

黑枪王荣格 2008-10-11 0

本书出版的唯一目的，就是作者为了推销自己所创立的那个模版而已，其实大家模版都差不多，没什么任何特别的地方，还不如几年前温伯格的作品。

我要写长评

想读在读读过

标签(多个标签以“，”分开):

保存

掌握需求过程

推荐文章

猜你喜欢

附近的人在看

推荐阅读

拓展阅读