隐含需求不确定性【规避软件需求隐含的风险】

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