note
2011-05-08
需求以一种无关技术的方式表达出来，这样做是有意避免对解决方案的设计产生影响。
产品构建好的时候，它的需求不会冻结。
敏捷软件开发宣言：
通过实践以及帮助别人实践，我们正在发现软件开发更好的方式。通过这项工作我们认识到以下一些价值：（1）个人和他们之间的互动胜过过程和工具；（2）工作的软件胜过面面俱到的文档；（3）客户协作胜过合同谈判；（4）响应变化胜过遵循计划。
需求来自于人，所以与人互动得越好，越能更好地收集需求。
如果以敏捷原则作为指导，就不至于仅仅因为事情是预先描述的就去做，而是会寻找机会更快地提供有用的功能。
功能性需求是产品必须完成的那些事。非功能需求是产品必须具备的属性或品质。限制条件是一个全局问题，约束着所有的需求。
不论是要构造用户定制的系统，还是组件集成的系统，或者使用商业上架销售的软件包，或者对已有的系统进行改动，都需要发现、捕获、交流需求。
理解顾客及其组织机构需求的最快方式不是通过键盘，而是通过白板。
正因为产品自身有一个演进过程，可能会决定先构造一个包含功能较少的早期版本，然后通过所计划的一系列发行版本来增强它。
需求过程不仅仅是用于新产品。
“如果我们必须重做一次，哪些地方会做的不同？”
我们从各种不同项目中提炼出我们的经验，提供一组适用于所有项目的基本活动和提交产物。
进入和离开一部分工作的信息决定了这部分工作做什么。
设定工作的范围意味着确定打算研究哪些工作、哪些工作与之有关，哪些信息流构成了工作之间的联系。
当设定范围时，是在确定哪些工作将研究、哪些工作不会去研究。
工作上下文的范围显示了工作的职责和相邻系统的职责起止之处。
可以将“目的、好处、度量标准”（Purpose， Advantage，Measurement，PAM）作为助记符，帮助发现并分析目标。
项目的目标不仅仅要解决问题，还要提供业务上的好处。
不论用哪种技术实现，本质总是存在。
网罗需求：业务事件（根据外部请求来划分工作），当前情况建模（检查遗留系统找到可复用的请求），做学徒（花时间与专家一起工作），观察结构和模式（确定可复用的需求），风险承担者访谈（能够关注细节问题），找出工作的本质（找到真正的问题），业务用例研讨会（让相关的风险承担者关注与业务事件的最佳反应），创造性研讨会（让团队一起来发现创造性需求），头脑风暴（促进创造性和创新），用户代表（利用一个复合的虚拟人物来代表客户/顾客），思维图（一种有效的计划/记录技巧），墙纸，录像和照相，wiki、blog和论坛（让所有风险承担者贡献想法），文档考古学（使用来自原有文档和文件的证据）。。。
查字典图书网
