管理信息系统 需求分析
如何进行管理信息系统需求调研分析
如何进行管理信息系统需求调研分析目录1. 管理信息系统需求调研分析概述 (2)1.1 背景与意义 (3)1.2 目的与任务 (5)1.3 研究方法与技术路线 (6)2. 相关概念与理论知识 (7)2.1 管理信息系统概述 (9)2.2 需求调研分析方法 (10)2.3 需求获取与分析工具 (11)3. 调研对象与范围定义 (12)3.1 调研对象的选择与确定 (13)3.2 调研范围的划分与管理 (14)4. 调研计划制定与实施 (16)4.1 调研计划的内容与步骤 (17)4.2 调研实施的方法与技巧 (18)5. 调研数据的收集与整理 (19)5.1 数据收集的方法与途径 (21)5.2 数据整理的原则与方法 (22)6. 需求分析与结果呈现 (23)6.1 需要识别与分类 (25)6.2 主要功能需求分析 (26)6.3 结果呈现与评价 (27)7. 建议报告撰写与提交 (28)7.1 建议报告的结构与内容 (30)7.2 建议报告的撰写技巧与注意事项 (30)8. 其他问题及后续工作安排 (31)1. 管理信息系统需求调研分析概述管理信息系统（Management Information System, MIS）需求调研分析是设计、开发和管理信息系统的关键步骤，它确保系统能够满足特定组织或部门的需求。
这个过程涉及系统地了解现有环境和条件，识别业务流程上的需求，并转化为系统需求的详细描述。
本段落旨在概述这一过程的重要性、一般框架以及后续步骤的目标。
进行需求调研分析是对管理信息系统成功实施的投资基础的奠定。
精确的需求识别有助于确保所开发的系统能够运作高效、满足用户期望，同时兼容组织内现有的基础设施。
启动阶段：这是调研过程的起始阶段，涉及到组建调研团队、制定调研计划以及明确调研目标和范围。
现状调研：此阶段调研团队通过问卷调查、访谈、观察和数据分析等方法，评估现有管理信息系统的状态及其在业务流程中的效用。
装备管理信息系统需求分析
装备管理系统需求分析需求分析是管理信息系统开发的关键环节，是系统设计与开发的依据。
要求在系统调查的基础上，对系统的功能进行细致的分析，并建立起相应的模型。
在系统分析的过程中，我们采用面向对象的分析，应用可视化的面向对象的建模语言UML建立系统的模型。
3．1业务建模业务建模是面向对象的分析与设计的的组成部分。
是对业务领域问题进行结构化的描述。
这个描述将会直接指导最终生成的软件，要进行合理的业务建模，首先要了解和熟悉系统的相关业务。
本“装备管理信息系统”是满足基层部队装备管理日常工作的需求，功能齐全，操作简便、实用的装备管理软件。
通过调研，了解到装备部门的日常工作的相关业务，得到如下装备管理的业务流程图：3．2系统需求分析需求分析是成功实施一个管理系统的基础，只有弄清楚客户的需求，才能开发出满足客户需要的信息系统，也才能够真正让整个系统发挥其相应的作用。
需求分析工作也是一个不断认识和逐步细化的过程，需求分析所要做的工作是深入描述系统的功能和性能，确定系统设计的限制和系统同其他系统元素的接口描述，定义系统的其他有效性需求。
3．2．1系统性能需求分析设计本系统不仅是要完成日常的装备业务功能，还应该能够为单位领导层提供相应的决策支持功能，最终提高装备管理水平和自动化程度。
因此要满足实际工作的需要，此系统必须具备良好的性能。
装备管理信息系统的具体性能目标如下：1．良好的人机界面。
本系统用户的是基层部队官兵，达不到专业的计算机技术水平，所以要提供清楚、友好的系统界面，提高系统的可操作性和人机交互功能。
使系统用户经过简单培训后，就能熟练地使用系统进行业务管理。
2．可扩展性。
一个良好的系统不仅要能很好地满足现在需求，还要能适应将来一段时间内单位业务不断扩大或某些规则的调整引起的变化。
因此，系统的设计应面向未来的发展，提供各种必要的标准接口，以便用户可以根据需要随时添加必要的设备和系统，扩大系统功能。
3．可维护性。
管理信息系统需求分析报告
管理信息系统需求分析报告1. 引言本报告旨在对管理信息系统的需求进行分析。
管理信息系统是指在组织中为管理人员提供决策支持和信息处理的系统。
通过对需求的深入分析，我们将能够确定系统所需的功能和特性，为系统的设计和开发提供指导。
2. 需求分析方法在进行需求分析之前，我们首先需要选择合适的需求分析方法。
常见的需求分析方法包括用户访谈、问卷调查和文档分析等。
我们可以根据具体情况选择适合的方法，或者结合多种方法进行综合分析。
3. 需求获取需求获取是需求分析的第一步，通过与相关人员的沟通和交流，我们可以获取到系统的需求信息。
以下是一些常见的需求获取方法：3.1 用户访谈用户访谈是一种直接与系统使用者进行交流的方法。
通过与用户的访谈，我们可以了解到用户对系统的期望和需求，以及他们对现有系统的不满意之处。
3.2 问卷调查问卷调查是一种收集大量用户意见和建议的方法。
通过设计合适的问卷，我们可以向广大用户群体收集需求信息，并通过数据分析找出需求的共性和差异。
3.3 文档分析文档分析是一种通过分析相关文档来获取需求信息的方法。
我们可以分析组织的现有流程、制度和规范等文档，从中获取到对管理信息系统的需求和要求。
4. 需求分析过程在获取到需求信息之后，我们需要对需求进行分析和整理，以便进一步明确系统的功能和特性。
以下是需求分析的一般步骤：4.1 需求分类根据需求的性质和层次，我们可以将需求进行分类。
常见的需求分类包括功能需求、非功能需求和约束需求等。
通过对需求的分类，我们可以更好地组织和管理这些需求信息。
4.2 需求分解需求分解是将高层次的需求细化为更具体和可操作的需求的过程。
通过需求分解，我们可以将复杂的需求分解为更小的子需求，以便于系统的设计和实施。
4.3 需求优先级排序在需求分析过程中，我们需要对需求进行优先级排序。
通过与用户的沟通和讨论，我们可以确定哪些需求是用户最需要的，哪些是最重要的。
根据优先级排序，我们可以合理安排系统的开发和实施计划。
管理信息系统 需求分析
管理信息系统需求分析在当今数字化的时代，管理信息系统（MIS）已经成为企业和组织运营中不可或缺的一部分。
一个有效的管理信息系统能够帮助企业提高效率、优化决策、增强竞争力。
而要开发出这样一个成功的系统，需求分析是至关重要的第一步。
需求分析的目的是清晰地理解用户的需求，明确系统需要实现的功能和性能，为后续的系统设计、开发和实施提供坚实的基础。
它就像是建筑施工前的蓝图，决定了最终建筑的结构和功能是否符合使用者的期望。
在进行需求分析时，首先要确定系统的用户群体。
这些用户可能包括企业的管理层、员工、客户，甚至是合作伙伴。
不同的用户群体对系统有着不同的需求和期望。
例如，管理层可能更关注系统提供的决策支持数据和报表，而员工可能更需要系统能够简化日常工作流程、提高工作效率。
接下来，需要深入了解用户的业务流程。
这包括收集和分析现有业务流程的相关信息，找出其中的痛点和问题，以及确定哪些流程可以通过信息化手段进行优化和改进。
比如，在销售业务中，可能存在订单处理不及时、客户信息管理混乱等问题，通过管理信息系统，可以实现订单的自动化处理和客户信息的集中管理，从而提高销售效率和客户满意度。
与用户进行有效的沟通是需求分析的关键环节。
可以通过面谈、问卷调查、观察等方法获取用户的需求。
面谈可以让需求分析师更深入地了解用户的想法和需求，及时解答用户的疑问；问卷调查则可以覆盖更广泛的用户群体，获取大量的反馈；观察用户的实际工作场景能够更直观地发现问题和需求。
在沟通的过程中，要注意倾听用户的意见，避免过早地给出解决方案，以免限制用户的思维和需求表达。
需求分析还需要考虑系统的安全性和可靠性。
随着信息安全问题日益突出，保护企业的敏感信息和数据至关重要。
系统需要具备用户认证、授权、数据加密等安全机制，以防止数据泄露和非法访问。
同时，系统要具备高可靠性，能够在各种情况下稳定运行，避免因系统故障导致业务中断。
此外，系统的可扩展性也是需求分析中需要考虑的一个重要因素。
学生信息管理系统需求分析
学生信息管理系统需求分析随着教育事业的不断发展和信息技术的快速进步，学生信息管理系统逐渐成为学校管理的重要工具。
这种系统旨在有效地管理和维护学生的个人信息、学业成绩以及其他相关数据。
通过对学生信息管理系统的需求分析，可以更好地设计和开发符合学校需求的信息管理系统。
一、系统概述学生信息管理系统是为了方便学校对学生信息进行统一、规范和高效的管理而设计的。
该系统主要包括学生基本信息管理、成绩管理、处分管理、奖励管理、考勤管理等模块，以满足学校对学生信息管理的各项需求。
二、学生基本信息管理1. 学生注册系统应提供学生注册功能，包括学生个人信息录入、身份验证和系统账号的创建。
录入的个人信息应包括学生的姓名、性别、出生日期、籍贯、联系方式等。
2. 学生档案管理系统应提供学生档案管理功能，包括学生个人照片上传、学生档案浏览和编辑、学生档案查询等功能。
三、成绩管理1. 成绩录入系统应提供成绩录入功能，包括教师录入学生考试成绩、平时成绩等。
录入的成绩应包括科目、考试日期、考试成绩等信息。
2. 成绩查询系统应提供成绩查询功能，包括学生和家长通过系统查询学生的各科成绩，同时教师和管理人员也可通过系统对学生成绩进行查询和分析。
四、处分管理1. 处分录入系统应提供处分录入功能，包括教师或学校管理员录入学生的处分情况，如违纪、作弊行为等。
录入的处分信息应包括类型、日期、原因等。
2. 处分查询系统应提供处分查询功能，学生、家长、教师和管理人员均可通过系统查询学生的处分情况。
五、奖励管理1. 奖励录入系统应提供奖励录入功能，包括教师或学校管理员录入学生的奖励情况，如优秀班干部、优秀学生等。
录入的奖励信息应包括类型、日期、原因等。
2. 奖励查询系统应提供奖励查询功能，学生、家长、教师和管理人员均可通过系统查询学生的奖励情况。
六、考勤管理1. 考勤录入系统应提供考勤录入功能，包括教师或学校管理员录入学生的考勤情况，如请假、旷课等。
学生信息管理系统需求分析报告
学生信息管理系统需求分析报告一、引言学生信息管理系统是一种用于管理学校学生信息的软件系统。
随着教育信息化的推进，学生信息管理系统已经成为学校信息化建设的重要组成部分。
本报告将对学生信息管理系统的需求进行分析，并提出相应的解决方案，以帮助学校更好地管理和利用学生信息。
二、背景概述现代教育环境中，学校面临着大量的学生信息管理任务。
这些任务包括学生的基本信息录入、档案管理、学籍管理、成绩管理等。
传统的纸质档案管理方式效率低下且易于丢失，无法满足学校对学生信息的及时、准确和安全管理的需求。
因此，学生信息管理系统的开发势在必行。
三、需求分析1. 学生基本信息管理：系统应能够录入和管理学生的基本信息，包括姓名、性别、出生日期、籍贯、家庭地址等。
管理员能够根据需要查询和修改学生信息。
2. 学籍管理：系统应能够管理学生的学籍信息，包括所属班级、年级、学号等。
系统应支持学籍异动，如转班、转学等。
管理员也能够根据需要对学生学籍进行查询和修改。
3. 成绩管理：系统应能够录入和管理学生的成绩信息，包括考试成绩、平时成绩等。
管理员能够根据班级和科目进行成绩查询和统计，以便进行分析和汇总。
4. 档案管理：系统应能够管理学生的档案信息，包括照片、家庭情况、奖惩记录等。
管理员能够根据需要查询和修改学生档案信息。
5. 教师管理：系统应支持对教师信息的录入和管理，包括姓名、性别、职称等。
管理员能够根据需要查询和修改教师信息。
6. 系统安全性：系统应具有较高的安全性，只有经过授权的用户才能够访问和修改学生信息。
系统还应提供日志功能，记录管理员的操作，以便追踪与审计。
7. 报表输出：系统应能够生成各种管理报表，如学生人数统计、班级成绩排名等，以便提供决策参考。
四、解决方案针对以上需求分析，我们建议采用以下技术和方法来实现学生信息管理系统：1. 数据库技术：使用关系型数据库存储学生信息、教师信息和成绩等数据，以便进行高效的数据管理和查询。
管理信息系统 需求分析
问题分析的四个步骤
问题分析：理解真实世界中的问题和用户的需求并提 出满足这些多方面要的解决方案的过程 ①在问题定义上达成共识 ②理解根本原因—问题背后的问题 ③定义解决方案系统的界限 ④确定加在解决方案上的约束
在问题定义上达成共识
把问题写下来，看每个人是否都同意 采用标准化格式： > 问题：描述问题 > 影响：确定受问题影响的风险承担人 > 结果：确定问题对风险承担人和商业活动的影响 > 优点：指出解决方案并列出主要优点
理解根本原因—问题背后的问题
不 准 确 的 订 单 运 输 损 耗 用 户 退 货 制 成 员 折 旧 制 造 缺 陷 其 他
退
货
他
户
其
用
耗
陷
损
缺
输
造
运
制
单
旧
订
折
的
的
确
品
准
成
不
制
太多废品
10 0
20
30
40
50
60
理解原因后对问题的陈述
问题：不准确的订单 影响：订单操作者、客户、生产者、销售者及客服 结果：增加废品、额外处理成本、客户不满及收益降 低 成功的解决方法： > 增加输入点订单的准确性 > 增加销售数据的报告以便进行管理
我们在哪里重重摔了一跤
在Standish Group的报告中总结了导致项目失 败的最重要的8大原因中，有5个与需求相关： 不完整的需求(13.1%)； 缺乏用户的介入(12.4%)； 不实际的客户期望(9.9%)； 需求和规范的变更(8.7%)； 提供了不再需要的(7.5%)
酒店管理信息系统分析与设计
酒店管理信息系统分析与设计在当今竞争激烈的酒店行业中，高效的管理和优质的服务是酒店取得成功的关键。
而酒店管理信息系统（HMIS）作为提升酒店运营效率和服务质量的重要工具，其合理的分析与设计至关重要。
一、酒店管理信息系统的需求分析（一）客户需求客户是酒店服务的核心对象，他们期望在预订、入住、住宿和退房等各个环节都能享受到便捷、高效和个性化的服务。
例如，客户希望能够通过多种渠道（如网站、手机应用、电话等）轻松预订房间，并且能够实时了解房间的可用性和价格。
在入住时，能够快速办理手续，同时能够根据自己的喜好选择房间的位置、朝向和设施等。
在住宿期间，能够方便地提出各种服务需求（如送餐、清洁、维修等），并且能够及时得到反馈和处理。
在退房时，能够快速结算费用，并且能够清晰地了解消费明细。
（二）酒店员工需求酒店员工需要一个易于操作、功能强大的管理信息系统来提高工作效率和服务质量。
前台员工需要能够快速查询和处理客户的预订、入住和退房信息，能够及时更新客户的资料和消费记录。
客房服务人员需要能够实时了解客房的状态（如是否需要清洁、是否有维修需求等），并且能够及时记录客房的服务情况。
餐饮服务人员需要能够快速下单、结账和处理客户的特殊需求。
管理人员需要能够通过系统获取各种报表和数据分析，以便做出科学的决策。
（三）酒店管理层需求管理层需要通过管理信息系统全面掌握酒店的运营情况，包括客房入住率、客户满意度、收入和成本等。
他们需要能够根据系统提供的数据进行分析和预测，制定合理的营销策略和经营计划。
同时，管理层还需要通过系统对员工的工作进行监督和评估，确保酒店的服务质量和运营效率。
二、酒店管理信息系统的功能模块设计（一）预订管理模块该模块应支持多种预订渠道，能够实时更新房间的可用性和价格。
客户可以通过输入预订日期、房间类型、人数等信息进行预订，系统会自动生成预订订单，并发送确认信息给客户。
同时，该模块还应具备预订取消、修改和查询功能，方便客户和酒店员工进行操作。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
确定涉众和用户
系统的用户是谁？ 还有哪些人会受系统输出的影响？ 系统完成并投入使用后，有谁会对它进行评估？ 还有没有其他系统内部或外部用户，他们的需要有没 有必要被考虑到？ 系统将来由谁维护？ 还有其他人吗？
定义解决方案系统的界限
谁会对系统提供信息？谁会在系统中使用信息？谁会 从系统中删除信息？ 输入 系统 输出 谁将操作该系统？ 谁是系统的维护者？ 系统 系统将会在哪儿被使用？ 界限 系统从哪儿得到信息？ 哪些外部系统要 我们的解决方案 和系统进行交互？
需求开发与管理
需求开发活动
需求获取
应收集什么信息： > 问题的描述 > 要求解决的问题列表（需求） > 用户对解系统的行为或结构施加的任何约束 信息来源： > 客户（实际的和潜在的） > 任何原有解系统（已有系统）及其文档 > 原有系统用户 / 新系统的潜在用户 > 应用（问题）领域专家 > 定义了任何接口系统的特片和行为的文档 > 相关的技术标准和法规
需求捕获的各方职责
用户、顾客和客户：有责任向需求分析师提供他们的 工作知识 需求分析师：理解用户所说的关于工作的事情，并将 其解释成产品的需求规格说明 > 观察和学习该项工作，从用户角度来理解它 > 用户对某项工作的描述必须作为事实来对待，要发 现工作的本质，而非表象 > 发明完成该工作更好的方法 > 以需求规格说明书和分析模型的方式记录
业务需求就是定义系统目标
有了清晰的目标之 后，还应该对系统 划定范围：
用户需求
用户需求是指描述用户使用产品必须要完成什么任务， 怎么完成的需求，通常是在问题定义的基础上进用户 访谈、调查，对用户使用的场景进行整理，从而建立 从用户角度的需求。 用户有不同类型： > 管理型、事务型 > 信息系统、人 > 决策层、使用层 > 常用者、偶用者
质量属性
产品必须具备的属性或品质 可靠性：成熟性、容错性、易恢复性 易使用性：易理解性、易学习性、易操作性 效率：时间特性、资源特性 可维护性：易分析性、易更改性、稳定性、易测试性 可移植性：适应性、易安装性、一致性、易替换性
设计约束
也称为限制条件、补充规约，这通常是对解决 方案的一些约束说明。 例如：必须采用国有自主知识版权的数据库系 统… 再如：必须运行在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%)
问题的根源是什么？
用户说的不是他想的：客户提供（陈述的需求） 的需求并不是真实的需求，还需要作进一步的 分析，以确定客户的真正需求和期望，接下来 需要澄清并重新描述。可以这么说客户在理解 基础业务过程和描述自己的需求方面有很大的 差异。 需求分析方法有问题：系统开发人员 使用低效的需求分析和项目管理方法。 共同责任强调不足：对客户和提供商 在项目成功的共同责任方面强调不够。
需求捕获的主要障碍
大多数情况下，系统相关的人员无法陈述自己的需要 许多用户难以解释所执行的任务，更难解释为什么执 行这些任务 相关人员经常指定解决方案而不是需求 相关人员也难以构想出新的工作方法，或者想像出使 用提供的方法执行熟悉的任务所能够得到的结果 不同的相关人员可能持有相互矛盾的观点 相关人员经常出于抵制变更而拒绝新系统 需求可能过多—过度的需求 需求随着时间而变化