用户需求报告编写指南

企业信息管理系统
[/b]用户需求报告编写指南
[/b]
[/b]
文档属性：
[/b]

文档编号 [/b]
文档版本 [/b]	V1.0
保密级别 [/b]
拟制 [/b]
审核 [/b]
批准 [/b]

[/b]修改记录：
[/b]

日期 [/b]	修改章节 [/b]	修改类型* [/b]	修改描述 [/b]	修改人 [/b]	版本 [/b]
03.8.10	All	A	创建	张昱	1.0

*修改类型分为 A[/b] - ADDED M[/b] - MODIFIED D[/b] – DELETED

指南
[/b]
[/b]目的：[/b]
[/b]《用户需求报告》是需求获取阶段的输出。《用户需求报告》的目的是对用户需求进行忠实的描述。它是需求规格定义和项目策划的基础，也是用户进行验收的依据。
本文档是《用户需求报告》的编写指南。
[/b]
[/b]内容：[/b]
[/b] [/b]文档回答三个问题：
用户的应用背景是什么？[/b]
[/b]用户的应用现状是什么？[/b]
[/b]用户需要什么样的应用？[/b]
[/b]
[/b]方法和要点：[/b]
[/b]1. 需求获取阶段的重要活动是需求调研，本文档的内容来源于需求调研的结果。
2. 针对产品类项目，本文档来源于对产品适应的用户群调研的结果。
3. 文档采用用户领域的语言描写，确保用户和分析人员都能看懂。

文档的组织[/b]
[/b] 文档第一部分是概述，着重描述用户的应用背景。用户使用系统的“目的与目标”是这部分的重点，它应该体现用户对系统的整体期望和愿景。“用户简介”部分则应该从多个维度刻画用户的应用背景。项目和用户之间应该建立一套统一的术语，以方便双方的沟通，业务术语表也可以是数据字典的雏形。文档中应该列出参考资料和相关文档，以及它们的来源，便于用户查阅。
文档的第二部分是业务描述，重点是用户的业务流程描述。在介绍业务流程之前，先向读者介绍用户的组织结构和岗位定义，组织结构和岗位定义是业务流程执行者，同时体现了企业的经营理念和管理思想，对理解业务起到很好的帮助作用。单据、账簿和报表是业务流程的载体，是分析阶段设计数据实体的重要依据。现有的业务流程和业务处理模式往往存在各种问题，这些问题有些能够在新系统中解决，有些则并不属于新系统解决的范围。文档还应该记录业务中可能发生的各种变化，以便做出富有弹性的设计。
文档的第三部分是业务需求，或者说功能需求，记录用户期望新系统能够解决哪些具体问题。它们既可能是对现有流程的优化，也有可能伴随新系统的使用而建立一些新的业务处理流程。无论怎样，应该忠实地记载用户对新系统的最直接的业务需求和最初始的动机。
文档的第四部分是非功能需求，从系统的外观、易用性、性能、安全、外部接口等多个维度给出用户对业务需求以外的其他需求。
文档的第五部分是假设与约束条件。

[/b]

1、概述

指南
[/b]
[/b]目的：[/b]
[/b]介绍系统的应用背景。

[/b]内容：[/b]
[/b]l 用户的基本情况。
l 用户对项目的总体要求和期望。
l 业务术语。
l 参考资料。
l 相关文档。

[/b]方法：[/b]
[/b]参考各节内容。

1.1 用户简介

指南
[/b]
[/b]目的[/b]
[/b]介绍用户的基本情况。

内容[/b]
[/b]1. 用户单位的性质，如国营、私营、外资、合资、股份制企业等。
2. 用户单位的行业，如制造、纺织、能源、交通、制药、金融、文教、卫生、政府等。
3. 用户单位的规模，包括员工数量、营业额等。
4. 用户单位的位置和布局，包括母公司和分子公司的地理分布。
5. 产品和服务种类，简要介绍用户产品和服务的种类、客户群及特点。
6. 用户单位的管理模式和管理思想。
7. 用户单位的核算方式。
8. 用户单位的计算机应用基础，如电脑台数、现有软件系统、计算机维护人员数量等。
……

[/b]方法和要点[/b]
[/b]1. 通过用户的宣传资料、媒体资料和中高层访谈，可以获得用户的基本情况。
2. 对用户基本情况的描述尽可能简练、准确，多用数字说明问题。
3. 避免公开用户保密信息，因此在成文前应该征求用户意见。
4. 针对不同类型的项目，对用户信息的描述应有侧重。比如对于财务核算系统，用户的行业和核算方式可能很重要，而对于一个制造系统，用户的产品特点和生产方式可能更重要。
5. 对于产品开发类项目，需要在此描述产品用户群的特点。

1.2 目的与目标

指南
[/b]
[/b]目的：[/b]
[/b]揭示用户投资开发本系统的真实意图，体现本系统对用户的真正价值所在。

[/b]内容：[/b]
[/b]项目目的概括了用户投资本系统的基本意图；项目目标则是对项目目的细化之后的具体的描述。
工程类项目的目标举例如下：
1. 通过…，从而提高生产能力XX%。
2. 通过…，从而提高服务客户的能力。
3. 通过…，完成人工难以解决的问题。
4. 通过…，控制XX业务中的薄弱环节，降低费用XX%。
5. 通过…，减少人工和设备的投入，降低成本XX%。
6. 通过…，提高XX业务的处理速度XX%。
7. 通过…，提高业务处理的透明度。
8. …...

[/b]方法：[/b]
[/b]项目目的和目标通常通过对高层——尤其是决策者的访谈获得。
项目目的概括了用户投资开发本系统的基本意图；项目目标则是把目的细化后的具体的描述。项目目的应该是明确和概括的；项目目标应该是明确、可度量和可以达到的。
项目的目标可以逐步细化，最终与系统的需求建立对应关系。建议对细化的目标进行编号，以便加以区分。建议建立需求和细化目标的对照关系表，以便检查系统功能是否覆盖了系统的目标。如果细化后的目标比较多，建议分类管理。
避免使用“开发一套让用户满意的系统”等字句，类似难以度量的目标往往是项目风险的主要来源。

1.3 业务术语

指南
[/b]
[/b]目的：[/b]
[/b]保证读者能够准确而一致地理解本文档中出现的概念、术语和缩写。

[/b]内容：[/b]
[/b]包括业务术语，比如安全库存、采购提前期、JIT、BOM等。
包括计算机术语，比如分布式、并发等。

[/b]方法和要点：[/b]
[/b]关注重要的、频繁出现的、不常见的、容易出现歧义的名词、术语和缩写。
如果术语较多，建议将术语分类。
对于名词、术语和缩写的解释尽量采用权威解释，尽量标明出处。
必要时添加图表辅助说明。

1.4 参考资料

指南
[/b]
[/b]目的：[/b]
[/b]说明本文档引用的参考资料，方便读者进一步查阅。

[/b]内容：[/b]
[/b]1. 商务合同。
2. 标书。
3. 用户需求调查表。
4. 用户领域的业务资料。
5. 国家标准和行业标准。
6. …...

[/b]方法和要点：[/b]
[/b]每一个文件、文献要有标题、索引号或文件号、发布或发表日期以及出版单位。

1.5 相关文档

指南
[/b]
[/b]目的：[/b]
[/b]记载本文档的辅助材料。

[/b]内容：[/b]
[/b]1. 用户帐簿表样。
2. 用户单据表样。
3. 用户报表表样。
4. …...

[/b]方法和要点：[/b]
[/b]说明用户需求报告的辅助材料，如果没有可以不填。

2. 用户业务描述

指南
[/b]
[/b]目的：[/b]
[/b]本章内容重点描述用户正在使用的业务处理方式和流程。

[/b]内容：[/b]
[/b]1. 用户的组织结构和职责。
2. 用户的岗位定义。
3. 用户的业务流程。
4. 用户的单据、帐簿和报表。
5. 用户业务过程中存在的问题。
6. 用户业务过程中可能发生的变化。

[/b]方法和要点：[/b]
[/b]描述用户现有的业务处理方式和流程，是为了帮助分析人员更好地把握需求，更好地了解用户的特点。这些业务流程和业务处理方法并不是未来系统的处理流程和方法，也代表未来系统的范围。未来业务系统将以实现用户总体目的和目标为前提，在现有业务处理方式的基础上，结合用户提出的业务需求，定义出一套结合了计算机应用技术的业务管理系统。

2．1 组织结构与职责

指南
[/b]目的：[/b]
[/b]描述用户的组织结构和职责。

[/b]内容：[/b]
[/b]1. 组织结构图。
2. 部门职责列表。

[/b]方法和要点：[/b]
[/b]组织结构和职责可以通过对人力资源部门的访谈得到。针对小规模企业，可以通过对主要经营者的访谈得到。
用户单位中的“组织”，作为业务流程中信息流动的节点，体现了用户的经营理念和管理思想。组织结构对分析人员理解业务流程、确定系统边界起到很好的帮助作用。弄清用户的组织结构和职责，是需求获取步骤中的基础工作之一。
建议以组织结构图和部门职责列表为主，描述用户的组织结构。建议用树形结构图描述组织结构，建议用列表描述部门职责。

[/b]

2．2 岗位定义

指南
[/b]目的：[/b]
[/b]描述系统涉及到的用户的岗位名称和职责。

[/b]内容：[/b]
[/b]1. 岗位定义列表。
2. 其他说明文字。

[/b]方法和要点：[/b]
[/b]和组织机构一样，岗位定义也是分析人员理解企业业务流程、划定需求边界的基础。岗位定义同样是需求获取的基础工作之一。
岗位定义可以从人力资源部门和业务部门的访谈中获得。
如果岗位定义内容比较少，建议直接采用表格的形式描述。如果岗位定义内容比较多，建议首先用列表作总体的、概要的描述，再用文字作具体说明。
用户的岗位定义中也包括计算机系统的系统管理人员。
用户的岗位定义应该和部门联系起来，岗位定义可以按照部门分类说明。

[/b]

2．3 总体业务流程

指南
[/b]目的：[/b]
[/b]从高层视角描述用户的业务处理过程。

[/b]内容：[/b]
[/b]1. 总体业务流程图。
2. 总体业务流程描述。

[/b]方法和要点：[/b]
[/b]总体业务流程来源于对具体业务流程的归纳和总结，总体业务流程需要和用户的反复探讨，不断修改形成。
总体业务流程是对调研活动中收集的各种业务流程进行总结和归纳后，得到的总体、概括的流程。很可能用户本身也没有这张图，只是头脑中有这个概念，我们一旦在用户的帮助下整理出这个流程，必然为今后准确深入地理解业务打下坚实的基础。
总体业务流程切忌太过具体、太过复杂，能够用直观、概括的图，配以简单、精确的文字说明最好。

2．4 具体业务流程

指南
[/b]目的：[/b]
[/b]描述用户具体的业务处理过程。

[/b]内容：[/b]
[/b]1. 业务流程列表。
2. 业务流程图。
3. 业务流程描述。

[/b]方法和要点：[/b]
[/b]具体业务流程来源于基层业务部门的访谈。
建议先用列表形式列出流程清单。
如果流程较多，建议对流程进行分类。
不能在流程图中描述出的内容，使用文字进行描述。
建议使用直式流程图描述业务流程。

2．5 单据、账簿、报表

指南
[/b]目的：[/b]
[/b]列举用户使用的单据、账簿和报表。

[/b]内容：[/b]
[/b]1. 单据、账簿、报表列表。
2. 单据、账簿、报表表样（可选）。

[/b]方法和要点：[/b]
[/b]1. 单据、账簿、报表是用户系统中信息的载体，是进行系统需求分析的基础。
2. 单据、账簿、报表的来源是基层业务部门。
3. 可以对单据、账簿和报表进行分类。
4. 建议将单据、账簿和报表进行编号，以便与管理。
5. 如果单据、账簿和报表比较多，建议将原始材料作为附件。
6. 针对单据、账簿和报表中的数据项，应该有详细的说明。这些说明包括：
来源
类型
长度
小数精度
计算关系
取舍规则（如四舍五入、取整等）
……

[/b]

2．6 现有系统存在的问题

指南
[/b]目的：[/b]
[/b]现有业务处理过程中存在的问题或瓶颈。

[/b]内容：[/b]
[/b]1. 业务量大，处理人员工作任务繁重。
2. 存在管理漏洞，给人以可乘之机。
3. 查找数据速度太慢。
4. 月底编制报告的工作量大。
5. 现有系统操作复杂。
6. ……

[/b]方法和要点：[/b]
[/b]现有业务系统的问题和瓶颈，来源于对用户各个组织和角色的访谈。由于信息来源于多个口径，因此可能很杂乱，并且可能有矛盾。需求人员应该广泛调查和分析，找出对用户商业目标真正有影响的问题，去除部门和角色从自身角度出发带来的误解和偏差。
需要注意的是，并不是这些问题都能够从未来系统中解决，有些可以借助引入计算机应用来解决，有些则必须从管理规范的角度解决。从调研的角度讲，应该如实记录上述所有的问题和瓶颈。

[/b]

2．7 未来可能的变化

指南
[/b]目的：[/b]
[/b]记录未来可能发生变化的业务。

[/b]内容：[/b]
[/b]容易发生撤并、新增的部门。
容易发生变化的流程。
容易发生变化的核算方式。
容易发生变化的单据和报表。
……

[/b]方法和要点：[/b]
[/b]企业的变化是永恒的，尤其是成长型的中小企业。调研人员在调研过程中一定要关注那些可能引起系统变化的问题，包括变化的可能性，变化的频度等。

[/b]
[/b]

3. 用户业务需求

指南
[/b]目的：[/b]
[/b]用文字描述用户希望解决的具体问题。是定义Use Case和需求建模的重要依据。

[/b]内容：[/b]
[/b] 用于直接记录来源于用户的需求。

[/b]方法和要点：[/b]
[/b]在这里应该忠实地记载用户对新系统的最直接的业务需求和最初始的动机。这些需求可能在未来的新系统中解决，也有可能不在新系统的功能范围内。新系统的功能范围将在需求规格中划定。这里只是如实地记录用户的需求。
用户的业务需求可以直接采用文字描述。（Program Statement）
业务需求的内容来源于对用户各个部门、岗位和角色的访谈。
对于复杂的系统，建议首先给出高层的业务需求，然后逐步细化，分解形成更为具体的业务需求。
为了便于管理，应该尽量缩小粒度。
建议对需求编号。
为了便于追溯，建议记录需求来源，包括需求提出的部门，涉及的岗位等。

[/b]样例：温布尔登网球赛赛事管理
[/b]
[/b]下面是来自[/b]Java[/b]架构设计师认证培训课程中的一个案例：[/b]
[/b]
本系统的目的是进行温布尔登网球公开赛的赛事管理。
比赛分为男单、女单、男双、女双和混双比赛。
计算机系统必须在赛前保存赛程，包括每场比赛的日期、时间、场地。在每场比赛之前加入选手和裁判的名单。在赛后加入比分和比赛时间。要确认双打选手来自同一只队伍。
计算机系统需要保存每位参赛选手的姓名、国籍和排名。
比赛官员向计算机系统录入基本信息和赛事情况。
记者能够通过计算机系统查询赛程和比分。记者被安排在专用的房间。

[/b]
[/b]

4. 非功能需求

4．1 外观需求

指南
[/b]目的：[/b]
[/b]描述用户所期望的产品外观。

[/b]内容：[/b]
[/b]1. 显示方式，如1024*768或640*480等。
2. 显示风格，如图形界面、控制台界面、Web界面等。
3. 外观倾向，如：外观上平易近人，外观上具有权威性，外观上与XX产品兼容，色彩丰富，对儿童有吸引力，产品将显得很昂贵，等等。
4. 外观意图，如：要求互动性强，要求令人兴奋，要求突出XX等。
5. ……

[/b]方法和要点：[/b]
[/b]用户对产品外观的要求往往是模糊的，因此往往需要分析人员拿出具体的样例征求用户的意见，从用户的反馈中弄清用户对外观的真实需求。

[/b]

4．2 易用性需求

指南
[/b]目的：[/b]
[/b]描述用户对易用性的具体要求和期待。

[/b]内容：[/b]
[/b]1. 是否支持多语种。
2. 是否支持残障人士。
3. 是否要求无计算机操作经验的人使用。
4. 产品对培训的依赖程度。
5. 理解产品是否需要一定的背景知识。
6. ……

[/b]方法和要点：[/b]
[/b]易用性，可以理解为三个具体内容：易理解、易操作、易学习。
用户的易用性需求可以通过对用户应用背景的分析得到。

[/b]

4．3 性能需求

指南
[/b]目的：[/b]
[/b]描述用户对性能的具体要求和期待。

[/b]内容：[/b]
[/b]1. 业务处理时间，比如：使用计算机管理后，要求在50秒内完成用户的一次交款业务。
2. 报表查询时间，比如：使用计算机管理后，要求交易报表查询时间不超过XX秒。
3. 处理的精度，比如：要求将数据处理精度提高到小数点后XX位。
4. 支持的并发访问数量。
5. ……

[/b]方法和要点：[/b]
[/b]尽量用具体、量化的指标说明问题。

[/b]

4．4 安全需求

指南
[/b]目的：[/b]
[/b]描述用户对系统安全的具体要求和期待。

[/b]内容：[/b]
[/b]1. 系统权限。
2. 数据传输的安全保证。
3. 数据库的访问控制。
4. ……

[/b]方法和要点：[/b]

4．5 外部接口

指南
[/b]目的：[/b]
[/b]描述与其他系统的接口。

[/b]内容：[/b]
[/b]1. 可能的外部系统比如：监控系统、控制系统、银行结算系统、防伪税控系统、政府网络系统等。
2. 与特殊外设的接口，如CT机、磁共振、柜员机（ATM）、IC卡、盘点机等。

[/b]方法和要点：[/b]
应在此列举出所有的外部接口、接口标准、规范。

4．6 其他

指南
[/b]目的：[/b]
[/b]描述用户除上述非功能需求外的其他非功能需求。

[/b]内容：[/b]
[/b]1. 交易的规模。
2. 正常情况和峰值情况下，要求处理的业务总数。
3. 输入、处理、传输、输出过程中的特殊精度要求。
4. 可移植性要求。
5. 可维护性要求。
6. 文化政策和法律方面的要求。
7. ……

[/b]方法和要点：[/b]

5. 假设与约束条件

指南
[/b]目的：[/b]
[/b]假设与约定条件是预计的对系统风险的描述。

[/b]内容：[/b]
[/b]1. 进度限制，包括对系统的阶段进度要求；
2. 资金限制，是否有投资额度限制；
3. 运行环境方面的限制，包括平台、体系结构、设备要求；
4. 培训需求，包括培训的规模、内容要求等；
5. 推广需求，包括推广的范围，推广过程中的特殊要求等；
6. 法律、法规和政策方面的限制；
7. 硬件、软件、运行环境和开发环境方面的条件和限制
8. 可利用的信息和资源；
9. ……

[/b]方法和要点：[/b]