确定涉众和用户



系统的用户是谁？ 还有哪些人会受系统输出的影响？ 系统完成并投入使用后，有谁会对它进行评估？ 还有没有其他系统内部或外部用户，他们的需要有没 有必要被考虑到？ 系统将来由谁维护？ 还有其他人吗？
定义解决方案系统的界限


谁会对系统提供信息？谁会在系统中使用信息？谁会 从系统中删除信息？ 输入 系统 输出 谁将操作该系统？ 谁是系统的维护者？ 系统 系统将会在哪儿被使用？ 界限 系统从哪儿得到信息？ 哪些外部系统要 我们的解决方案 和系统进行交互？
需求开发与管理
需求开发活动
需求获取


应收集什么信息： > 问题的描述 > 要求解决的问题列表（需求） > 用户对解系统的行为或结构施加的任何约束 信息来源： > 客户（实际的和潜在的） > 任何原有解系统（已有系统）及其文档 > 原有系统用户 / 新系统的潜在用户 > 应用（问题）领域专家 > 定义了任何接口系统的特片和行为的文档 > 相关的技术标准和法规
需求捕获的各方职责

用户、顾客和客户：有责任向需求分析师提供他们的 工作知识 需求分析师：理解用户所说的关于工作的事情，并将 其解释成产品的需求规格说明 > 观察和学习该项工作，从用户角度来理解它 > 用户对某项工作的描述必须作为事实来对待，要发 现工作的本质，而非表象 > 发明完成该工作更好的方法 > 以需求规格说明书和分析模型的方式记录
业务需求就是定义系统目标

有了清晰的目标之 后，还应该对系统 划定范围：
用户需求


用户需求是指描述用户使用产品必须要完成什么任务， 怎么完成的需求，通常是在问题定义的基础上进用户 访谈、调查，对用户使用的场景进行整理，从而建立 从用户角度的需求。 用户有不同类型： > 管理型、事务型 > 信息系统、人 > 决策层、使用层 > 常用者、偶用者

质量属性

产品必须具备的属性或品质 可靠性：成熟性、容错性、易恢复性 易使用性：易理解性、易学习性、易操作性 效率：时间特性、资源特性 可维护性：易分析性、易更改性、稳定性、易测试性 可移植性：适应性、易安装性、一致性、易替换性
设计约束



也称为限制条件、补充规约，这通常是对解决 方案的一些约束说明。 例如：必须采用国有自主知识版权的数据库系 统… 再如：必须运行在UNIX操作系统之下
业务需求就是定义系统目标



形成一个不超过50字的项目目标，并且列出5-9个主 要子目标，并且将其制作成一页文档，作为“项目的 行动纲领”，还应该得到“项目发起人”的认可。 在此基础上，可以编写“项目的目标和范围文 档”(或称项目综述，即POS，内容包括问题/机会、 项目目标、项目目的、成功标准、假设/风险/障碍)， 对于产品而言，我们还可以构建一个从市场角度分析 的“愿景”文档。 该部分工作是处于“需求过程”的金字塔尖，多花费 一些时间和精力是值得的，也是必要的。
信息系统立项可行性分析

确定目标：信息系统实现前，信息系统实现后 提出解决方案：分析P，给出O，得出A 可行性分析： > 效益分析：经济可行性，投资回报 > 社会可行性 > 技术可行性
信息系统立项时的常见误区



目标：含混不清，过为宏观 Solution: 基于业务需求思考 解决方案：思路过于受限 Solutions: > 只想What，别想How > 了解、理解IT技术 期望值：脱离现实 发起人、用户、使用者想法不一致
需求获取技术
• • • • • • • •
阅读背景资料 头脑风暴
讨论分析
文档考古 面谈（用户访谈） 联合应用设计 用户调查 需求剥离
• • •
现场观摩
任务观察 用例和场景
需求获取的误区

缺乏计划性：随意、走过场，预先没计划 缺乏科学性：未从本质入手 捕获对象不明确，甚至造成岐义 过于迷信现有文档 过于迷信“听”到的东西
项目成功的因素

用户的参与：15.9% 管理层支持：13.9% 清晰的需求描述(13.0%)； 合适的规划(9.6%)； 现实的客户期望(8.2%)； 较小的里程碑(7.7%)； 有才能的员工(7.2%)
软件需求曾经让我们如此狼狈
参与各方都以自已角度讲述问题
财务计算 管理报表 工作流 自动库存控制 库存报警 业务线索管理 业务经线索跟踪 销售月报生成 交易流数据 分布式 WebServices 三层 对话框 菜单条 DCOM B/S 数据交换……
问题分析的四个步骤


问题分析：理解真实世界中的问题和用户的需求并提 出满足这些多方面要的解决方案的过程 ①在问题定义上达成共识 ②理解根本原因—问题背后的问题 ③定义解决方案系统的界限 ④确定加在解决方案上的约束
在问题定义上达成共识

把问题写下来，看每个人是否都同意 采用标准化格式： > 问题：描述问题 > 影响：确定受问题影响的风险承担人 > 结果：确定问题对风险承担人和商业活动的影响 > 优点：指出解决方案并列出主要优点
需求分析
需求—导致项目失败的罪魁祸首



根据Standish Group对23000个项目进行的研究结果 表明，28%的项目彻底失败，46%的项目超出经费预 算或者超出工期，只有约26%的项目获得成功。 而在于这些高达74%的不成功项目中，有约60%的失 败是源于需求问题。 也就是说，有近45%的项目最终因为需求的问题最终 导致失败。
优秀的需求



完整性：完整描述即将交付使用的功能，发现缺少某 项信息正确性：经过用户或用户信任的代理人审阅 可行性：在已知能力和约束条件中实现 必要性：每项需求记录的功能都应是用户真正需要的 有优先次序：提供了实现优先级 无歧义：对所有读者只有一种一致的解释 可验证性：可以设计测试方法来检查
其他系统
贷款经理
确立贷 款期限 根据贷 款统计 报告
贷款委员 会委员
评估临 界的贷 款请求 提交贷款 贷款申请者 申请表 接收贷款帐单， 偿付贷款
信贷员
评估贷款
客户
贷款办事员
登记、结束 贷款
贷款处理系统
提供客户 贷款信息 转发还款 历史记录
贷款助理
输入贷款请 求信息 转发过 期货款
根据偿付情况更 新帐户并报告帐 户状况
理解根本原因—问题背后的问题
不 准 确 的 订 单 运 输 损 耗 用 户 退 货 制 成 员 折 旧 制 造 缺 陷 其 他
退
货
他
户
其
用
耗
陷
损
缺
输
造
运
制
单
旧
订
折
的
的
确
品
准
成
不
制
太多废品
10 0
20
30
40
50
60
理解原因后对问题的陈述


问题：不准确的订单 影响：订单操作者、客户、生产者、销售者及客服 结果：增加废品、额外处理成本、客户不满及收益降 低 成功的解决方法： > 增加输入点订单的准确性 > 增加销售数据的报告以便进行管理
请求信 用报告
帐户管理 系统
托收代理
数据仓库
征信机构
确定加在解决方案上的约束



经济约束：预算？ 行政约束：存在许可问题？潜在内外部政问题？部门 间问题？ 技术约束：技术选择有何限制？限制在已有平台或技 术上？禁止使用新技术？需要购买软件包？ 系统约束：建立在现有系统上？需要维护与原系统的 兼容性？必须支付什么操作系统？ 环境约束：合法吗？安全性要求？其他标准限制？ 进度及资源：进度要求？已有资源？外部劳动力可用 否？有无扩展资源？
确定加在解决方案上的约束



操作性：销售订单数据必须在数据库中备份一年，因 为数据丢失风险太大，需并行运行至少一年的数据 系统及操作系统：应用在服务器上占用不超过200M， 因为服务器上存储空间有限 设备预算：必须在已有服务器和主 机上开发 人员预算：固定的人力资源，没有外部资源 技术要求：应用新的面向对象的方法
我们在哪里重重摔了一跤



在Standish Group的报告中总结了导致项目失 败的最重要的8大原因中，有5个与需求相关： 不完整的需求(13.1%)； 缺乏用户的介入(12.4%)； 不实际的客户期望(9.9%)； 需求和规范的变更(8.7%)； 提供了不再需要的(7.5%)
缺乏资源(10.6%),没有执行层支持(9.3%),缺少规划(8.1%)
问题的根源是什么？



用户说的不是他想的：客户提供（陈述的需求） 的需求并不是真实的需求，还需要作进一步的 分析，以确定客户的真正需求和期望，接下来 需要澄清并重新描述。可以这么说客户在理解 基础业务过程和描述自己的需求方面有很大的 差异。 需求分析方法有问题：系统开发人员 使用低效的需求分析和项目管理方法。 共同责任强调不足：对客户和提供商 在项目成功的共同责任方面强调不够。
需求捕获的主要障碍



大多数情况下，系统相关的人员无法陈述自己的需要 许多用户难以解释所执行的任务，更难解释为什么执 行这些任务 相关人员经常指定解决方案而不是需求 相关人员也难以构想出新的工作方法，或者想像出使 用提供的方法执行熟悉的任务所能够得到的结果 不同的相关人员可能持有相互矛盾的观点 相关人员经常出于抵制变更而拒绝新系统 需求可能过多—过度的需求 需求随着时间而变化