第二章需求工程过程.pptVIP

* * 风险躲在需求的迷雾之后 　经理：“我们要建立一套完整的商业管理软件系统，包括商品的进、销、调、存管理，是总部-门店的连锁经营模式。通过通信手段门店自动订货，供应商自动结算，卖场通过扫条码实现销售，管理人员能够随时查询门店商品销售和库存情况。另外，我们也得为政府部门提供关于商品营运的报告。”?　　分析员：“我已经明白这个项目的大体结构框架，这非常重要，但在制定计划之前，我们必须收集一些需求。”?　　经理觉得奇怪：“我不是刚告诉你我的需求了吗？”?　　分析员：“实际上，您只说明了整个项目的概念和目标。这些高层次的业务需求不足以提供开发的内容和时间。我需要与实际将要使用系统的业务人员进行讨论，然后才能真正明白达到业务目标所需功能和用户要求，了解清楚后，才可以发现哪些是现有组件即可实现的，哪些是需要开发的，这样可节省很多时间。”?　　经理：“业务人员都在招商。他们非常忙，没有时间与你们详细讨论各种细节。你能不能说明一下你们现有的系统？”?　　分析员尽量解释从用户处收集需求的合理性：“如果我们只是凭空猜想用户的要求，结果不会令人满意。我们只是软件开发人员，而不是采购专家、营运专家或是财务专家，我们并不真正明白您这个企业内部运营需要做些什么。我曾经尝试过，未真正明白这些问题就开始编码，结果没有人对产品满意。”?　　经理坚持道：“行了，行了，我们没有那么多的时间。让我来告诉您我们的需求。实际上我也很忙。请马上开始开发，并随时将你们的进展情况告诉我。” 第一页，共二十九页。 优秀的团队遇到糟糕 的需求 需求问题导致的主要后果是返工——重复做您认为早已做好的事情。 返工的成本占了总开发成本的30%～50，而对于返工的情况，70%～80%是因需求错误引起的。 从图可以看出，在项目末期才发现缺陷，对其进行改正的成本要比在缺陷刚产生不久时修改的成本高得多。 第二页，共二十九页。 镀金问题 开发人员为产品添加了一项需求说明中没有提到的功能，他认为“用户肯定会喜欢的”。这就是所谓的“镀金问题(gold plating)”。 开发人员和需求分析员不应擅自添加特性，应该把创意和备选方案提交给客户，让他们做决定。 要避免镀金问题，就应该追溯每项功能的来源，弄清楚为什么添加该功能。 第三页，共二十九页。 过于抽象的需求 营销人员或经理经常喜欢只给出一个粗略的说明，他们希望开发人员在开发过程中充实它。 这种方式对研究性项目或需求特别灵活的项目或许管用，但是需要紧密合作的团队，而且仅限于开发小型系统。 大多数情况下，这种做法的结果是使开发人员受挫，让客户失望。 第四页，共二十九页。 忽略了某类用户 用户所使用的产品特性、产品的使用频率以及用户自身的经验水平不尽相同。 因此，多数产品都拥有不同的用户群。如果一开始没能找出产品的所有重要用户群，就会有某些用户需求得不到满足。确定所有用户群后，还要保证获得各类用户的需求 。 第五页，共二十九页。 第二部分 需求工程过程 需求工程: 对问题域及需求做调查研究和描述,设计将满足那些需求的解系统的特性并用文档说明. 需求获取 需求分析 规格说明 人机接口 需求验证 需求获取、分析、编写需求规格说明和验证并不遵循线性的顺序，这些活动是相互隔开、增量和反复。 第六页，共二十九页。 需求开发过程 需求开发是一个迭代的过程 第七页，共二十九页。 需求工程的推荐方法 列出了近50种方法，分别属于7个类型，它们可以帮助大部分项目开发团队更好地完成他们的需求工作。 第八页，共二十九页。 知 识 需求管理 项目管理 培训需求分析员 对用户代表和管理者进行需求培训 对开发者进行应用领域相关的培训 创建术语表 定义需求变更控制进程 成立变更控制委员会 分析需求变更的影响 控制需求版本并为其建立基线 维护需求变更的历史记录 跟踪每项需求的状态 衡量需求稳定性 使用需求管理工具 创建需求跟踪矩阵 选择合适的开发周期 根据需求制订项目计划 重新协商权利或义务 管理需求风险 跟踪需求耗费的人力物力 回顾以往的教训 需求获取 需求分析 编写规格说明 需求验证 定义需求开发过程 定义项目前景和范围 确定用户群 选择用户代言人 建立核心队伍 确定用例 确定系统事件和响应 举行进一步需求获取的讨论 观察用户如何工作 检查问题报告 重用需求 绘制关联图 创建原型 分析可行性 确定需求优先级 为需求建模 创建数据字典 将需求分配至各子系统 应用质量功能调度 采用SRS模板 确定需求来源 惟一标识每项需求 记录业务规范 定义质量属性 审查需求文档 测试需求 确定合格标准 第九页，共二十九页。 知 识 技 能 开发者也应该了解产品