规避软件需求隐含风险.docVIP

规避软件需求隐含风险 　　在招标文件编写过程中，需求分析是非常关键的一步，特别是软件项目，前期需求的精确设定将直接影响到项目的后续实施，因此一定要避免一些可预见的风险。 　　在项目立项初期，需求分析占据了关键地位，它的准确与否直接关系到项目的成败。风险因素存在于需求获取、分析、验证和管理这一整个过程当中，要降低风险发生的可能性或减轻风险发生给项目带来的影响，必须在以下几个阶段着手采取措施规避风险。 　　 　　需求获取阶段 　　 　　●绘制产品视图与范围。 　　如果团队成员没有对他们要做的产品功能达成一个清晰的共识，则很可能导致项目范围的逐渐扩大。因此最好在项目早期写一份项目视图与范围，将业务需求涵盖在内，并将其作为新的需求或修改需求的指导。 　　●别挤压需求分析的时间。 　　紧张的工程进度安排给管理者造成很大的压力，使他们觉得不赶紧开始实施将无法按时完成项目，因而对需求一带而过。但项目因其规模和应用种类不同（如企业信息门户系统、邮件系统、网络管理系统）而有着很大的区别。粗略的统计表明: 需求开发工作应占全部工作量的15%。 　　●保证需求规格说明的完整性和正确性。 　　编制需求的往往是信息部门员工，而软件使用者来自业务部门，所以双方的沟通非常重要。设计者要以用户的任务为中心，根据不同的使用情景编写需求测试用例、建立原型，使需求更加直观，同时获取使用者的反馈信息，最后请专家对需求规格说明和分析模型进行正式的评审。 　　●明确非功能需求和未加说明的需求。 　　由于使用者一般只强调产品的功能性要求，非常容易忽略产品的非功能性的需求。应该查明产品使用性、完整性、可靠性等质量特性，还有人性化的展示方式、查询方式，以此编写非功能需求文档和验收标准，作为可接受的标准。 　　另外，软件使用者可能会有一些隐含的期望要求，但并未说明，设计者要尽量识别并记录这些假设。提出大量的问题来引导使用者充分表达他们的想法和应关注的一切问题。如果不同的使用者对产品有不同的意见，那最后结果必将让有些使用者不满意。确定出主要的使用者，并采用产品代表的方法来确保使用者代表的积极参与，保证在需求决定权上有正确的人选。 　　 　　●别把已有的产品作为需求基线。 　　在升级或重做的项目中，需求开发可能显得并不重要。开发人员有时被迫把已有的产品作为需求说明的来源，认为“只是修改一些错误和增加一些新特性”，这时的开发人员不得不通过现有产品的逆向工程(reverseengineering)来获取需求。可是，逆向工程对收集需求是一种既不充分也不完整的方法，因此新系统很可能会有一些与现有系统同样的缺陷。应当将在逆向工程中收集的需求编写成文档，并让专家评审以确保其正确性。 　　需求分析阶段 　　●划分需求优先级。 　　设计者应划分出每项需求、特性或使用实例的优先级，并安排在特定的产品版本或实现步骤中。评估每项新需求的优先级并与已有余下的工作主体相对比以做出适宜的决策。 　　●找到带来技术困难的特性。 　　设计者应分析每项需求的可行性以确定是否能按计划实现。成功好像总是悬于一线的，因此应运用项目状态跟踪的办法管理那些落后于计划安排的需求，并尽早采取纠正措施。 　　●关注不熟悉的技术、方法、语言、工具或硬件平台。 　　设计者不要低估了学习曲线中表明的满足某项需求的新技术发展速度，明确那些高风险的需求并允许使用者有一段充裕时间用来从错误开始学习、实验及进行原型测试。 　　 　　需求规格说明阶段 　　 　　●准确理解需求。 　　开发人员和使用者对需求的不同理解会带来彼此间的期望差异，将导致最终产品无法满足使用者的要求。对需求文档进行正式评审的团队应包括开发人员，测试人员和使用者。训练有素且颇有经验的需求分析人员能通过询问使用者一些合适的问题，写出更好的规格说明。模型和原型能从不同角度说明需求，这样可解决一些模糊的需求。 　　●减少时间压力对未确定问题的影响。 　　将软件需求规格说明中需要将来进一步解决的需求注上TBD（“待确定”）记号，但如果这些TBD并未解决，则将给结构设计与项目继续进行带来很大风险。因此应记录解决每项TBD的负责人的名字、问题是如何解决的以及解决的截止日期。 　　● 避免具有二义性的术语。 　　建立一本术语和数据字典，用于定义所有的业务和技术词汇，以防止它被不同的读者理解为不同的意思。特别是要清楚说明那些既有普通含义又有专用领域含义的词语。 　　● 不要在需求说明中包括设计。 　　包含在需求说明中的设计方法将对开发人员造成多余的限制，并妨碍他们进行最佳设计的创造性。仔细评审需求说明以确保它是在强调解决业务问题需要做什么，而不是在说怎么做。 　　需求验证阶段 　　●未经验证的需求。 　　审查相当篇