软件需求第2章

软件需求第2章内容摘要：

求开发中的主要参与者都了解并接受他们的义务。 如果遇到分歧，通过协商以达成对各自义务的相互理解，这样能减少今后的摩擦（如一方要求而另一方不愿意或不能满足要求）。 软件客户需求权利书 权利 1：要求分析人员使用符合客户语言习惯的表达 需求讨论应集中于业务需要和任务，故要使用业务术语，你应将其教给分析人员，而你不一定要懂得计算机的行业术语。 权利 2：要求分析人员了解客户的业务及目标 通过与用户交流来获取用户需求、分析人员才能更好地了解你的业务任务和怎样才能使964e4b2d8b5c2e6e2afaf616361fccba 18 产品更好地满足你的需要。 这将有助于开发人员设计出真正满足你的需要并达到你期望的优秀软件。 为帮助开发人员和分析人员，可以考虑邀请他们观察你或你的同事是怎样工作的。 如果新开发系统是用来替代已有的系统，那么开发人员应使用一下目前的系统，这将有利于他们明白目前系统是怎样工作的，其工作流程的情况，以及可供改进之处。 权利 3：要求分析人员编写软件需求规格说明 分析人员要把从你和其他客户那里获得的所有 信息进行整理，以区分开业务需求及规范、功能需求、质量目标、解决方法和其它信息。 通过这些分析就能得到一份软件需求规格说明。 而这份软件需求规格说明便在开发人员和客户之间针对要开发的产品内容达成了协议。 SRS可以用一种你认为易于翻阅和理解的方式组织编写。 要评审编写出的规格说明以确保它们准确而完整地表达了你的需求。 一份高质量的软件需求规格说明能有助于开发人员开发出真正需要的产品。 权利 4：要求得到需求工作结果的解释说明 分析人员可能采用了多种图表作为文字性软件需求规格说明的补充。 因为如工作流程图那样的图表能很清楚 地描述出系统行为的某些方面。 所以需求说明中的各种图表有着极高的价值。 虽然它们不太难于理解，但是你很可能对此并不熟悉。 因此可以要求分析人员解释说明每张图表的作用或其它的需求开发工作结果和符号的意义，及怎样检查图表有无错误及不一致等。 权利 5: 要求开发人员尊重你的意见 如果用户与开发人员之间不能相互理解，那关于需求的讨论将会有障碍，共同合作能使大家“兼听则明”。 参与需求开发过程的客户有权要求开发人员尊重他们并珍惜他们为项目成功所付出的时间。 同样，客户也应对开发人员为项目成功这一共同目标所作出的努力表示尊重与 感激。 权利 6：要求开发人员对需求及产品实施提供建议，拿出主意 通常，客户所说的“需求”已是一种实际可能的实施解决方案，分析人员将尽力从这些解决方法中了解真正的业务及其需求，同时还应找出已有系统不适合当前业务之处，以确保产品不会无效或低效。 在彻底弄清业务领域内的事情后，分析人员有时就能提出相当好的改进方法。 有经验且富有创造力的分析人员还能提出增加一些用户并未发现的很有价值的系统特性。 权利 7：描述产品易使用的特性 你可以要求分析人员在实现功能需求之上还要注重软件的易用性。 因为这些易用特性或质量属性能使你 更准确、高效地完成任务。 例如，客户有时要求产品要“用户友好”或“健壮”或“高效率”，但这对于开发人员来说，太主观了并无实用价值。 正确的应是：分析人员通过询问和调查了解客户所要 的友好、健壮、高效所包含的 具体特性（第 11 章将详细讨论它）。 权利 8 调整需求，允许重用已有的软件组件 需求通常要有一定的灵活性。 分析人员可能发现已有的某个软件组件与你描述的需求很相符。 在这种情况下，分析人员应提供一些修改需求的选择以便开发人员能够在新系统开发中重用一些已有的软件。 如果有可重用的机会出现，同时你又能调整你的需求说明，那 就能降低成本和节省时间，而不必严格按原有的需求说明开发。 所以说，如果想在产品中使用一964e4b2d8b5c2e6e2afaf616361fccba 19 些已有的商业常用组件，而它们并不完全适合你所需的特性，这时一定程度上的需求灵活性就显得极为重要了。 权利 9：要求对变更的代价提供真实可信的评估 有时人们面临更好、也更昂贵的方案时，会做出不同的选择。 而这时，对需求变更的影响进行评估从而对业务。