关于需求岗

需求  idea 从生活中来

管理系统 -- 提升效率(业务需要) 正确反馈(数据分析) 便于管理（打标志） 
系统设计 -- 可行性分析(设计需要) 概要设计(数据库设计,需求文档，设计文档) 详细设计(开发，测试)  交付（部署文档，代码包，用户手册） 运营
定义需求落实书面 出《需求分析说明书》

 

需求评审

需求评审 出 《需求规格说明书》
需求状态：  open  close
过程：

• 一类是正式技术评审，也称同行评审，另一类是非正式技术评审。
• 对于任何重要的工作产品，都应该至少执行一次正式技术评审。
• 沟通，头脑风暴，达成共识。

通病：

• 刚开始评审时，大家都比较认真，越到后头越马虎。当需求文档很长时，几乎没人能够坚持到最后。
• 做好会议切分  这样每次评审的时间比较短，参加评审的人员也少一些，组织会议就比较容易。
• 开评审会议时经常会"跑题"，导致评审效率很低。
• 当争议变为争吵时就坏事了。争吵不仅对评审工作没有好处，而且会无意中伤害同事们的感情。
• 应当养成良好的习惯:不要一棍子打死异己的观点，尝试着让自己站在他人的立场思考问题，这样你会找到比较满意的答案。
• 项目名称_评审报告_需求

文档筛选

文档状态，如初始状态，草稿状态，评审状态等。

需求承诺

XX项目需求文档_《XXX需求说明书》，版本号:X.X.X,是建立在XXX与XXX双方共同对需求理解的基础之上，同意后续的开发工作根据该工作产品开展。
如果需求发生变化，双方将共同遵循项目定义的"变更控制规程"执行。需求的变更将导致双方重新协商成本、资源和进度等。
甲方签字
乙方签字

需求跟踪

• 在整个开发过程中，进行需求跟踪的目的是为了建立和维护从用户需求开始到测试之间的一致性与完整性。
• 提出问题，准备方案对策，得到支持，或者解答。
• 被动沟通，白板，资料共享
• 主动沟通，当面，电话，微信，视频。

需求变更控制

• 需求变更通常会对项目的进度、人力资源产生很大的影响，这是开发商非常畏惧的问题。也是必须面临与需要处理的问题。
• 由于市场变化而导致需求发生变更，
• 正因为市场在变化，才会产生更多商机，聪明的开发商才会有活干，有钱赚。
• 总的而言，人们提出需求变更，本就是出于能够使产品更加符合市场或客户需求，出发点本身是好的。
• 对于开发小组而言，意味着前期的投入被浪费掉，故应该慎重，前期做好充分的调研和沟通。

-未完，待续-