时间过得真快,经过一系列需求研讨、需求分析和整理确认,我们整理出了需求列表,编写出了需求规格说明书,一切似乎该到结束需求分析阶段的时候了。但是,敏捷大师的一句话让我们彻底心凉到了骨头里。敏捷大师说了,我们不可能在需求分析阶段完成所有的需求分析工作,它将延续到设计、开发,甚至测试阶段。
一直以来,我对这句话非常困惑。既然需求分析阶段不能完成所有的需求分析工作,那么完成多少才算结束呢?80%?60%?或者更少?大师没有给出一个标准。大师就是大师,生活在太空里的,我们慢慢理解吧。经过多年的实践,我慢慢理解了。我们说这种需求分析工作不可能完全完成,或者说日后用户的需求会变,其实并不是毫无规律可循的。通常,用户对需求的变更只发生在某些固定的范围内,弄清楚了这些范围,我们的问题就迎刃而解了。
1. 整体需求不变,具体细节变化。我们说需求是分层次的,整体框架、功能模块、每个操作的细节。如果用户变更到了将整个框架都推翻了,这个项目就别做了。所以整体框架是必须在需求分析阶段完成的,是日后不可能改变的。功能模块可能要变,但通常是某个部分在变,而更多的是那些具体操作的细节在变。
2. 界面风格与操作易用性是最容易发生变更的。我们说用户看到软件以后不满意,其实主要是对界面风格与操作性不满意,而不是软件功能。界面不够美观,操作不方便,不符合用户的操作习惯,都是造成用户不满意的地方。
3. 增加其它功能。软件是对现实的模拟,而现实也是复杂多变的。我们与用户在进行业务流程分析时,也许一些流程没有考虑到,或者还有特殊情况需要处理。这些是客户要求增加功能的主要动因。
经过以上分析,需求分析阶段要做到什么程度就可以清楚了:整体框架与功能模块必须确定下来,至于各个功能模块下的具体操作,尽量做,能到什么程度先到什么程度。至于界面风格与操作性,我们可以在日后迭代开发的每个迭代期,拿出样品以后再与用户确认。
OK,万事俱备只欠东风,当所有工作都完备以后,我们的需求分析工作开始进入最后收尾的阶段。我们说,需求分析阶段的产出物是需求列表与需求规格说明书,而最终结束的里程碑无疑就是需求评审会了,或者说与用户的签字确认会。
需求评审会的主要目的就是确认需求,以便以此开始我们的设计开发工作。从理论上说,需求评审会应当由用户代表,与项目经理、需求分析员、系统架构师、设计人员、测试人员、QA经理,还有公司相关领导参加。但实际上,让如此多不同角色的人聚集在一起开会是不现实的。因此,我们可以将需求评审会分为内部评审会与外部评审会两部分来开比较现实。
处理外部问题,必先要从内部统一思想。先召开一个内部评审会,听听系统架构师、设计人员、测试人员、QA经理对需求分析工作的意见,然后由领导讲讲话,布置一下后面的工作,是十分有必要的。按照我的经验,系统架构师这时的作用相当重要,他应当仔细阅读需求,仔细思考技术是否可行,以及预测该系统是否能够达到用户方领导对该项目制订的目标。如果答案是否定,立即进行调整。
最后就是与用户的外部需求评审会了。外部需求评审会,也可称为签字确认会议,就是与用户就需求规格说明书进行评审,最后签字确认。用户签过字的东西,不可能完全抑制住用户的变更,但至少从很大程度上抑制住了用户的大改。然而,在召开外部需求评审会之前,我们建议大家就需求规格说明书,先与各个单位或部门的用户代表讨论并确定下来,避免在最终的签字确认会上出现分歧,影响工作进度。毕竟大家都不容易,工作一大堆,聚在一起不容易。
经过数月的分析讨论,最终在一片和谐的气氛中,双方领导在需求规格说明书上签字,项目开始进入一个新的轮回。在这个轮回中,是焦头烂额、不胜其苦,还是如履薄冰、最终顺利交付,是与许多因素有关的。但我想说,一份高质量的需求分析必定起到决定性的作用,必定为日后的软件开发扫清了许多许多的地雷。
我们应当怎样做需求分析
我们应当怎样做需求调研:初识
我们应当怎样做需求调研:拜访
我们应当怎样做需求调研:研讨会
我们应当怎样做需求调研:需求研讨
我们应当怎样做需求调研:迭代
我们应当怎样做需求调研:需求捕获(上)
我们应当怎样做需求调研:需求捕获(下)
我们应当怎样做需求分析:功能角色分析与用例图
我们应当怎样做需求分析:业务流程分析(上)
我们应当怎样做需求分析:业务流程分析(下)
我们应当怎样做需求分析:用例说明
我们应当怎样做需求分析:查询报表分析
我们应当怎样做需求分析:子用例与扩展用例
我们应当怎样做需求分析:行动图和状态图
我们应当怎样做需求分析:业务领域分析
我们应当怎样做需求分析:原文分析法
我们应当怎样做需求分析:领域驱动设计
我们应当怎样做需求分析:非功能需求
我们应当怎样做需求确认:需求列表
我们应当怎样做需求确认:一个需求列表的实例
我们应当怎样做需求确认:快速原型法
我们应当怎样做需求确认:需求规格说明书
我们应当怎样做需求确认:评审与签字确认会
(全文终)
分享到:
相关推荐
我们应当怎样做需求分析 我们应当怎样做需求调研:初识 3 我们应当怎样做需求调研:拜访 5 我们应当怎样做需求调研:研讨会 6 我们应当怎样做需求调研:需求研讨 8 ...我们应当怎样做需求确认:评审与签字确认会 53
评审需求文档和原型 客户评审需求文档,是给分析人员带来反馈信息的一个机会。如果客户认为编写的“需求分析报告”不够准确,就有必要尽早告知分析人员并为改进提供建议。更好的办法是先为产品开发一个原型。这样...
1、业务开展的目的(方便产品经理对整个项目的把控)...2、业务方案描述(如方案内容较多,可附于需求单后); 3、业务开展预计要达到的业绩目标(便于优先级排序和后续业务跟进); 4.功能的使用/操作人员,权限分配;
数据安全合规实践(一)安全需求评审:业务研发团队提交信息.docx数据安全合规实践(一)安全需求评审:业务研发团队提交信息.docx数据安全合规实践(一)安全需求评审:业务研发团队提交信息.docx数据安全合规实践(一)...
需求与设计评审,需求与设计评审 需求与设计评审
软件需求评审表单项目名称评审对象版本号提交日期编制人评审日期评审方式评审准则完整性:软件需求规格说明书中没有遗漏必要需求可行性:软件需求规格说明书中每一个需求都
介绍软件测试中需求的评审与需求如何测试的.很适合在需求方面还不清楚的测试人员,也适合初学者.
word版需求评审意见表,网上搜了一下百度文库、豆丁、道客巴巴都要收费,特此自己简单做了一个,自己动手丰衣足
需求分析评审记录表.doc
软件需求分析评审记录表.docx
软件需求规格说明书评审 很好的介绍,大家可以参照着看看。。
软件需求评审报告模板.doc
软件开发需求评审表,含组织架构管理系统、权限管理系统、界面自定义系统、以及评审意见。文档编号:ITQMS-SEP-P01
评审问题单基本信息评审时间2020/3/27评审地点腾讯会议评审对象需求规格说明书评审方式线上审查评审员任健(任课老师)、全体选课同学评审意见序号评审人问题回答
非常好的需求分析及评审模板,我找了很久才找到得
2.1.3、 本期项目与前项目的关系 8 2.2、 业务流程分析 9 2.3、 建设单位信息化现状 9 第三章、 需求分析 9 3.1、 政务目标分析 9 3.2、 服务对象、业务流程和业务量分析 9 3.2.1、 服务对象分析 9 3.2.2、 业务数据...
产品需求设计评审会议纪要文档 资源较为优质,可供产品新人、产品经理参考
评审问题单基本信息评审时间2020/4/12评审地点腾讯会议评审对象需求分析评审评审方式线上审查评审员任健(任课老师)、全体选课同学评审意见序号评审人问题回答处
乘驾互联网驾校系统1.0测试设计,案例系统——需求评审报告
从网上找的需求评审相关资料