系统需求分析文档需要考虑的问题
最近作了几次需求分析,有了一些经验,特共享出来.
欢迎指正.
我认为在系统需求分析中,有三个问题需要注意,
即
系统涵盖范围
用户对上线时间的要求
系统上线对目前系统整体的影响
系统覆盖的范围
很多用户都想的是,这次一定要把所有遇到的问题解决完. 也就说,客户潜在的心理是对系统较高的期望值.
这个时候,我们需要来确定系统涵盖的范围来界定我们的工作内容,同时也减少客户不合理的要求.
如果我们在需求文档里面不确定范围,系统就会越来越大,结果造成,系统本身过于庞大,而无法完成.
用户对上线的要求
确定这个是保证我们对今后工作计划作良好的准备工作.
记得有个专家说,我们最终完成系统所用的时间是我们计划的2-3倍,这里我就不涉及关于如何合理安排计划来确保进度.
这篇文章很不错,推荐一下,呵呵
在一个软件开发项目中进行实际日程安排的十二点提示(转)
系统上线对目前IT系统造成的影响
这一点来说,很多文档都不会记录.
前一阵跟agile的实施工程师接触,结果发现他们一个很严重的问题,他们不是很关心上线agile系统后对目前公司现有IT系统的影响.
我觉得这种态度是对上线公司的不负责,因为上线只是一个时间点,而上线后后遗症怎么处理?
所以,我把这一条加入到需求文档中去.
可以考虑一下跟交互的其他系统以什么接口来沟通.
这一步最好提前作,系统分析人员一定要明确出来给开发人员.
还一条我觉得可以列出项目分析文档中去
数据流程
欢迎指正.
我认为在系统需求分析中,有三个问题需要注意,
即
系统涵盖范围
用户对上线时间的要求
系统上线对目前系统整体的影响
系统覆盖的范围
很多用户都想的是,这次一定要把所有遇到的问题解决完. 也就说,客户潜在的心理是对系统较高的期望值.
这个时候,我们需要来确定系统涵盖的范围来界定我们的工作内容,同时也减少客户不合理的要求.
如果我们在需求文档里面不确定范围,系统就会越来越大,结果造成,系统本身过于庞大,而无法完成.
用户对上线的要求
确定这个是保证我们对今后工作计划作良好的准备工作.
记得有个专家说,我们最终完成系统所用的时间是我们计划的2-3倍,这里我就不涉及关于如何合理安排计划来确保进度.
这篇文章很不错,推荐一下,呵呵
在一个软件开发项目中进行实际日程安排的十二点提示(转)
系统上线对目前IT系统造成的影响
这一点来说,很多文档都不会记录.
前一阵跟agile的实施工程师接触,结果发现他们一个很严重的问题,他们不是很关心上线agile系统后对目前公司现有IT系统的影响.
我觉得这种态度是对上线公司的不负责,因为上线只是一个时间点,而上线后后遗症怎么处理?
所以,我把这一条加入到需求文档中去.
可以考虑一下跟交互的其他系统以什么接口来沟通.
这一步最好提前作,系统分析人员一定要明确出来给开发人员.
还一条我觉得可以列出项目分析文档中去
数据流程