需求是变动的;
需求是需要和相关人员沟通的,往往在线的沟通和讨论是最好的;
需求是需要版本维护的;
需求是大家都能时时了解到的;
大家对此类问题如何处理维护的
我可能没有表达好的意思:
我的意思,是需求具有上述特征,如何有效管理使得管理有条不紊,达到上诉要求
你们用敏捷开发吗?
从一个最小的原型开始一步一步迭代,二到三周为一个周期,周期内收集需求,开发,测试,验收。
文档尽量少。把需求做成一个一个功能点,写出来跟业务人员确认清楚。
要有个产品经理,一切需求他说了算。
永远的痛啊。要么耗费大量时间,要么需求更新不及时。
拿到需求之后,将文档按照模块拆分,将团队分为几个小组,各自负责一块,小组内部维护需求和完成功能。弊端:没有全局观,小组间需求耦合的话,沟通成本高。
我觉得变动是在升级维护以后的事,老在某阶段需求变动修改,那是没真正理解需求
需求方必须要有一个拥有决定权的人,开发方要讨论的是把他想的东西变成真正你想的东西,别两方一群人在互相讨论
一阶段需求一版本,跨度不要太大,最好能模拟需求场景
您好,我可能没有表达好的意思:
我的意思,是需求具有上述特征,如何有效管理使得管理有条不紊,达到上诉要求
@Moon.Orm塑造Orm经典:
1. 把需求分若干阶段
2. 按阶段向需求方展示,确定是否偏离需求
3. 一阶段的需求变动滚入下一阶段
4. 根据一阶段的需求变动,判断之前需求理解是否有问题和修改进度
http://kb.cnblogs.com/page/107318/
http://kb.cnblogs.com/page/61314/
http://kb.cnblogs.com/page/60803/
http://kb.cnblogs.com/page/62118/ 这几篇博客希望可以给你提供一些帮助。
https://office.live.com/start/word.aspx
这个能帮到你
确定需求的范围及步骤
对每一步里程碑
确保步骤小且快
需求修改问题 在 文件头 加上 版本修改列表 显示历史的修改记录
需求及时让大家知道 需要在公共的位置放一个唯一的永远为最新的需求文档 当每次更细的时候群发通知 已经更新