软件体系结构2-第2章 软件需求.pptVIP

什么是好的需求规格说明书 一致 “一致”（Consistent）是指《软件需求规格说明书》中各个需求之间不会发生矛盾。矛盾常常潜伏在需求文档的上下文中。 什么是好的需求规格说明书 必要 《软件需求规格说明书》中的各项需求对用户而言应当都是必要的。 可以把“必要”比喻为“雪中送炭”。“必要”往前一步，要么是“画蛇添足”要么是“锦上添花”。 “画蛇添足”显然是坏事，会导致开发人员多干一些吃力不讨好的工作。所以要尽量剔除需求规格说明书中“画蛇添足”的那些需求。 “锦上添花”是好事，可能会让用户获得比期望更多的喜悦，但是眼前用户不会为此多付钱。开发者应当集中精力先完成必要的需求，如果条件允许则再做“锦上添花”的需求。为了避免主次颠倒，应当在《软件需求规格说明书》中将那些“锦上添花”的需求设置为较低的优先级。 什么是好的需求规格说明书 完备 “完备”（Complete）是指《软件需求规格说明书》中没有遗漏一些必要的需求。 人们往往倾向于关注系统的特色功能，而忽视了其它一些不起眼的但却是必需的功能。 不完备的《软件需求规格说明书》将导致产生功能不完整的软件，用户在使用该软件时可能无法完成预期的任务。 什么是好的需求规格说明书 可实现 《软件需求规格说明书》中的各项需求对开发方而言应当都是可实现的（Attainable）。 “可实现”意味着在技术上是可行的，并且满足时间、费用、质量等约束。营销人员和用户谈生意时，为了能拿到“单子”，他们往往对用户提出的需求“来者不拒”。吹牛皮虽然不犯法，但是《软件需求规格说明书》可是白纸黑字啊。经过双方确认的《软件需求规格说明书》相当于商业合同，如果开发方不能够实现《软件需求规格说明书》中的内容，那就是违约，可能会被罚款的。 对于合同项目，如果开发方不能确信某些需求是否可实现，则应事先与用户协商，达成一致的处理意见，避免将来发生商业纠纷。 什么是好的需求规格说明书 可验证 《软件需求规格说明书》中的各项需求对用户方而言应当都是可验证的（Verifiable）。如果需求是不可验证的，那么用户就无法验收软件，可能会发生商业纠纷。 例如，摩天大楼的一项需求是“抗十二级台风”，这个需求看起来堂而皇之，但是如何验证呢？当摩天大楼完工后验收时，用户又不是巫师，他怎能造个十二级台风来试验？如果双方都认可“采用计算机模拟十二级台风”等效于实际测试，那么这项需求就是“可验证”的。 什么是好的需求规格说明书 确定优先级 为什么要确定需求的“优先级”？ 理论上讲，软件的所有需求都应当被实现。但是在现实之中，项目存在“进度、费用、人力资源”等限制。在项目刚开始的时候，开发方和客户比较乐观，什么都要做，可是做着做着，人们常常会面临“进度延误、费用超支、人员不足”等问题，这时就乱套了。 人们想出了“取舍”办法：先做优先级高的需求，后做（甚至放弃）优先级低的需求，这样可以将风险降到最低。 需求的优先级其实就是需求“轻重缓急”的分级表述，例如划分为“高、中、低”三级。一般地，由用户和开发方共同确定需求的优先级。 什么是好的需求规格说明书 阐述“做什么”而不是“怎么做” 《软件需求规格说明书》的重点是阐述“做什么”，而不是阐述“怎么做”。“怎么做”是系统设计和实现阶段的事情。 国内的很多软件公司里，开发人员常常身兼数职，可能把需求开发、系统设计、编程等工作从头做到尾。所以他们在调查、分析、定义需求时，自然会想到“怎么做”，这并没有什么过错。如果在调查、定义需求时想好了“怎么做”，当然应该写下来，否则岂不浪费！关键是不要将“怎么做”写到需求规格说明书里面，记录在其它文档里就行了。 什么是好的需求规格说明书 什么是好的需求规格说明书 软件需求规格说明书实例 01-中国电信经营分析系统需求说明书-中国电信 02-湖南移动24小时自助营业厅银行卡交费软件需求规格说明书 03-长沙县委办局（部门、乡镇）协同办公系统需求规格说明书 04-长沙移动项目管理系统软件需求规格说明书 05-福建中烟企业门户及协同办公平台项目需求说明书 需求管理 需求确认（评审和承诺） 需求确认是指开发方和客户方共同对《软件需求规格说明书》进行评审，双方对需求达成共识后作出承诺。需求确认包含两个重要工作：“需求评审”和“需求承诺”。 需求管理 需求评审面临的困难 需求评审的一个通病是“虎头蛇尾”。需求评审的确乏味，也比较费脑子。刚开始评审时，大家都比较认真，越到后头越马虎。 需求评审涉及的人员可能比较多，有些时候让这么多人聚在一起花费比较长的时间开会并不容易（例如有些人可能出差在外，有些人可能事务缠身）。没有必要把所有事情挤在一块做，需求开发是循序渐进的过程，需求评审也可以分段进行。这样每次评审的时间比较短，参加评审的人员也