管理信息系统 需求分析

需求捕获的各方职责

用户、顾客和客户：有责任向需求分析师提供他们的 工作知识 需求分析师：理解用户所说的关于工作的事情，并将 其解释成产品的需求规格说明 > 观察和学习该项工作，从用户角度来理解它 > 用户对某项工作的描述必须作为事实来对待，要发 现工作的本质，而非表象 > 发明完成该工作更好的方法 > 以需求规格说明书和分析模型的方式记录
需求获取技术
• • • • • • • •
阅读背景资料 头脑风暴
讨论分析
文档考古 面谈（用户访谈） 联合应用设计 用户调查 需求剥离
• • •
现场观摩
任务观察 用例和场景
需求获取的误区

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

质量属性

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



也称为限制条件、补充规约，这通常是对解决 方案的一些约束说明。 例如：必须采用国有自主知识版权的数据库系 统… 再如：必须运行在UNIX操作系统之下
请求信 用报告
帐户管理 系统
托收代理
数据仓库
征信机构
确定加在解决方案上的约束



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


问题分析：理解真实世界中的问题和用户的需求并提 出满足这些多方面要的解决方案的过程 ①在问题定义上达成共识 ②理解根本原因—问题背后的问题 ③定义解决方案系统的界限 ④确定加在解决方案上的约束
在问题定义上达成共识
Biblioteka Baidu
把问题写下来，看每个人是否都同意 采用标准化格式： > 问题：描述问题 > 影响：确定受问题影响的风险承担人 > 结果：确定问题对风险承担人和商业活动的影响 > 优点：指出解决方案并列出主要优点
业务需求就是定义系统目标




目标在哪里？业务需求是构建在“项目发起人”的脑 子里的，也就是谁提出项目，谁就拥有对“业务需求” 的最清晰的理解。 引出宏观的目标：思考企业运作中存在什么问题？这 些问题主要是体现在哪些方面？这些问题对企业造成 了什么影响？认为可以怎么解决？希望达到什么样的 效果？ 将大任务分解成为小目标，并且引导客户良好地定义， 这也是我们形成“项目子目标描述”的关键基础。 衡量这些目标的合理性与可行性。
确定加在解决方案上的约束



操作性：销售订单数据必须在数据库中备份一年，因 为数据丢失风险太大，需并行运行至少一年的数据 系统及操作系统：应用在服务器上占用不超过200M， 因为服务器上存储空间有限 设备预算：必须在已有服务器和主 机上开发 人员预算：固定的人力资源，没有外部资源 技术要求：应用新的面向对象的方法
业务目标示例
某船厂商业管理系统目标： A1.取代过时的系统 A2.集成订单文档及数据库 A3.使用经验数据进行报价 A4.支持系统化的销售 A5.快速捕获成本数据 A6.加快发票的制作
某医院管理系统目标： B1.降低IT成本 人事部门： B2.实现一些任务的自动化 B3.消除出错源 B4.遵守最后期限 B5.减少繁琐工作 医院部门： B6.减少加班及工作量不足的情况 B7.更快速的勤务规划 B8.改进勤务表质量
确定涉众和用户



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


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



完整性：完整描述即将交付使用的功能，发现缺少某 项信息正确性：经过用户或用户信任的代理人审阅 可行性：在已知能力和约束条件中实现 必要性：每项需求记录的功能都应是用户真正需要的 有优先次序：提供了实现优先级 无歧义：对所有读者只有一种一致的解释 可验证性：可以设计测试方法来检查
信息系统立项可行性分析

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



目标：含混不清，过为宏观 Solution: 基于业务需求思考 解决方案：思路过于受限 Solutions: > 只想What，别想How > 了解、理解IT技术 期望值：脱离现实 发起人、用户、使用者想法不一致
业务需求就是定义系统目标

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


用户需求是指描述用户使用产品必须要完成什么任务， 怎么完成的需求，通常是在问题定义的基础上进用户 访谈、调查，对用户使用的场景进行整理，从而建立 从用户角度的需求。 用户有不同类型： > 管理型、事务型 > 信息系统、人 > 决策层、使用层 > 常用者、偶用者
需求是什么？
业务需求 项目视 图/范围 文档 用户需求 质量属性 非功能需求 其它非功能 需求 设计约束 功能需求 SRS
用例文 档
系统需求
业务需求



业务需求是指反映组织机构或客户对系统、产品高层 次的目标要求，通常问题定义本身就是业务需求 。 背景描述：XX保险公司希望充分利用日益完善的移 动通信技术，在原有的办公系统的基础上进行扩展， 使得在外的业务人员能够及时地获得客户、业务相关 的动态信息，与此同时，实现企业内部的即时通信。 业务需求/目标 ：通过该系统的实施，将人 工保费续缴、投保手续办理两项业务运转 周期缩短10％以上，使企业内部沟通效率 大幅改善，以帮助企业运转效率得以提高。
其他系统
贷款经理
确立贷 款期限 根据贷 款统计 报告
贷款委员 会委员
评估临 界的贷 款请求 提交贷款 贷款申请者 申请表 接收贷款帐单， 偿付贷款
信贷员
评估贷款
客户
贷款办事员
登记、结束 贷款
贷款处理系统
提供客户 贷款信息 转发还款 历史记录
贷款助理
输入贷款请 求信息 转发过 期货款
根据偿付情况更 新帐户并报告帐 户状况
我们在哪里重重摔了一跤



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



根据Standish Group对23000个项目进行的研究结果 表明，28%的项目彻底失败，46%的项目超出经费预 算或者超出工期，只有约26%的项目获得成功。 而在于这些高达74%的不成功项目中，有约60%的失 败是源于需求问题。 也就是说，有近45%的项目最终因为需求的问题最终 导致失败。
检查表示例
需求错误的代价
需求：1 设计：5 编码：10 测试：20-50 运行与维护：200
信息系统立项前的分析方法


G（目标）：要确定需要开发某个信息系统之前，应 该分析其应该达到的目标：业务性、可度量 P（问题）：要达到该目标所需解决的问题！ O（选项）：针对这些问题可选的解决方案 A（答案）：针对各种Option进行分析、评估，最终 确定答案。
优秀的团队遇到糟糕的需求


用户参与不足 用户需求扩展 有歧义的需求 过于抽象的需求 忽略某种用户 不准确的计划 ……
我们应该怎么办？


对“需求”建立正确的认识； 客户和供应商—一根绳子上的两个蚂蚱； 和客户一起建立起“共同的目标”； 寻找并使用正确的、有效的需求捕获、描述 （建模）、管理方法； 动态、持续地适应需求的变化；
需求捕获的主要障碍



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

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


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



形成一个不超过50字的项目目标，并且列出5-9个主 要子目标，并且将其制作成一页文档，作为“项目的 行动纲领”，还应该得到“项目发起人”的认可。 在此基础上，可以编写“项目的目标和范围文 档”(或称项目综述，即POS，内容包括问题/机会、 项目目标、项目目的、成功标准、假设/风险/障碍)， 对于产品而言，我们还可以构建一个从市场角度分析 的“愿景”文档。 该部分工作是处于“需求过程”的金字塔尖，多花费 一些时间和精力是值得的，也是必要的。
理解根本原因—问题背后的问题
不 准 确 的 订 单 运 输 损 耗 用 户 退 货 制 成 员 折 旧 制 造 缺 陷 其 他
退
货
他
户
其
用
耗
陷
损
缺
输
造
运
制
单
旧
订
折
的
的
确
品
准
成
不
制
太多废品
10 0
20
30
40
50
60
理解原因后对问题的陈述


问题：不准确的订单 影响：订单操作者、客户、生产者、销售者及客服 结果：增加废品、额外处理成本、客户不满及收益降 低 成功的解决方法： > 增加输入点订单的准确性 > 增加销售数据的报告以便进行管理
问题的根源是什么？



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


解释一：系统需求是相关联的硬件、软件系统对待开 发系统的相关需求。 解释二：从系统实现的角度描述的需求。 开发人员（设计及分析人员）在业务需求、用户需求 的基础上生成的。
功能需求

功能需求是需求的主体，是需求的本质 功能需求定义了：系统必须完成的那些事，即为了向 它的用户提供有用的功能，产品必须执行的动作 零散（需求项）整理（特性、用例） 敏捷方法：用户故事