1.专注理解业务问题，提供解决方案。（活动、服务、消费品）
2.确定拥有者看中的价值，交付一个解决方案（更快，更便宜，更方便）
3. 需求分析者理解拥有者的业务工作，决定将来如何进行。
让开发理解产品打算为用户完成什么。
需求分析者与拥有者沟通，探讨怎样的产品能为工作带来最大的改进。
需求分析者得到需求，描述需求（产品功能-要做什么、产品属性-做到什么程度）
4.构建一个软件不等于解决一个业务问题
频繁让用户审核开发模块，不通就返工迭代的问题是永远不知道用户批准前一次的交付是因为满意还被过程搞得筋疲力竭。
很难让单个用户理解软件在更大范围内的全局影响。他们不知道更大业务的足够信息，不能确定具体应用是否会对业务的其他部分带来问题。
软件是要解决一个业务问题，开发工作必须从问题开始，而不是从解决方案开始。
5.需求不一定要写下来，但构建者必须知道它们。即使写下来也要积极主动沟通确保大家知道的是一致的。（口头沟通更有效）
编写需求的意义:
有助于业务分析师和利益相关者彻底理解需求。
记录了团队的决定。
为测试者和开发者提供了清晰的指示。
明确需求重要性，评估工作量。
维护者明确需求成因会降低维护成本。
6.客户不一定总能给你正确答案。
需求探索的局限性
介于业务的复杂性和规模个人很难理解全部。
描述人问题本身理解不透彻。
关于产品解决问题的展望的描述过程困难。
需求沟通过程
记录客户的要求，包括“增量改进”性的叙述。翻译成产品需求。（缺点是排除了重大创新，导致产品平庸不能满足期望）
有时候必须说服客户，他们要求的并不是他们想要的。
有时候必须从客户的解决方案中导出需求。
有时候必须提出没有人提到的创新，得到更好的解决方案。
网友评论