一、背景知识介绍
1. 软件工程的基本思想
在计算机发展初期，软件规模小，文档资料通常也不存在，很少使用系统化的开发方法。随着软件规模逐渐增大，复杂程度越来越高，软件可靠性问题也越来越突出。原来的个人设计、个人使用的方式不再能满足要求，迫切需要改变软件生产方式，提高软件生产率。你不能用制造小木船的方法制造航空母舰。
软件工程学的基本思想就是将软件当作一种工程产品来处理，从时间角度对软件开发和维护的复杂问题进行分解，把软件生命的漫长周期依次划分为若干个相对独立的阶段，并给每个阶段赋予明确而有限的任务。
2. 需求分析决定项目成败
随着人们对软件危机的认识和研究，软件工程方法也取得了一些实用的发展和进步，但软件项目的开发成功率仍然不高，大多数项目依旧处于超进度、超成本状态。在这些失败的项目中，需求不明确、需求不完整和需求变化等方面的因素占到了60％。正是如此，国内也渐渐开始重视需求分析这一软件开发的基础工作。
Carl Zetie在2006年1月的研究报告中指出：“需求定义不良或理解不正确，是导致付出的努力白费、重复工作以及项目失败的最大因素”。业内分析人员通过调查也发现需求分
析不准确、杂乱无章以及不完整是软件项目失败的首要因素。根据Standish Group 的年度CHAOS 报告，导致项目失败的五大原因中与需求相关的高达三个。
软件的需求分析是软件生存周期的重要阶段，它是联系用户与软件开发者的纽带，它的好坏对软件下一步的开发工作将产生决定性的影响。因此，对需求分析工作应该给予足够的重视，否则将对软件项目的开发工作造成严重的后患。如果软件开发者在对用户的需求没有充分了解之前，就急于进行设计和编程工作，这样设计出来的软件是无法满足用户要求的。软件使用中发生软件危机的原因之一就是需求分析工作未做好，软件人员和用户之间未能全面地、精确地理解和表达这些需求。
上述软件开发行业的现状表明以下几个方面的问题：1) 软件需求分析以及需求说明质量的提高是软件开发项目成败的关键要素之一；2) 及早地发现缺陷，特别是在软件需求分析阶段检测出缺陷并进行修改能够有效的降低软件产品的开发成本，提高软件的开发质量。
3. 软件需求说明书（业务需求文档）定义
软件需求说明书是对一个待开发的系统的描述，是系统开发人员与用户就产生一个什么样的系统相互交流的产物，是系统各项后续开发的基础。
4. 业务需求文档的作用
开发公司根据包含在软件需求说明书中描述的系统来估计开发成本，制定规划并预测进度安排、工作量和资源；
开发人员依赖它来理解他们将要开发的系统，并据此进行编码工作；
测试人员根据文档中对系统行为的描述制定测试计划、测试用例，进行测试工作。 系统运维人员和技术支持根据文档了解系统的功能；
根据业务需求文档编写用户手册。
业务需求文档是我们系统建设过程树立的一个正确的航标。有了这样一个航标，就可以使我们最终能够到达一个正确的彼岸。
二、如何撰写高质量的业务需求文档
1. 业务需求文档的常见问题
（1）需求过于简单。有的只是一句话，如“需要补录数据功能”，可以说，只给了一个需求题目，没有内容描述，具体业务处理流程和要求没有任何说明。
（2）需求内容不完整。业务需求洋洋洒洒写了不少，但仔细一看，整个需求说明书内
容缺东少西，要么少了界面输入项目，要么少了业务处理过程及要输出的结果等。
（3）需求内容描述不清晰。想要什么，业务流程如何处理，定义不清，概念界定模糊，有很多疑问。如需求文档中对于统计报表只是画出一个大概表样，没有给出统计口径、数据来源等详尽资料。
（4）需求不具有可行性。分不清在技术上什么能做什么不能做，例如试图从技术上解决腐败问题。
（5）需求文档没有统一撰写格式，不管是研发新产品、对现有系统功能改进、还是提取数据和生产问题需求，都没有一个简单实用的需求格式，随意书写，或者提供的格式完全不符合业务人员要求，大家不愿意或根本无法使用。
2. 提高撰写质量的措施
（1）业务人员和技术人员要建立良好的交流与合作关系。一般来说，技术人员对计算机软硬件系统比较熟悉，但对业务不太熟悉，而业务人员恰恰相反，他们熟悉自身的业务却不了解计算机技术，即使了解一些往往也是不系统的，因此，业务人员很难编写出质量较高的软件需求说明书，提供的往往是笼统的不规范的需求。这就需要通过用户和软件人员之间的交流来相互沟通，让用户了解计算机能干什么，对软件系统提出要求；而软件人员则必须花一段时间去认真分析业务人员究竟要求系统“做什么”，并把用户和软件人员共同理解的用户需求用“业务需求文档”准确地表达出来。提倡的让业务人员、技术人员、开发人员组成一个团队，使用统一的语言，来表达大家都清楚明白的概念。
（2）技术人员应该转变观念，积极参与业务需求的编写，不要认为业务需求与技术人员无关。
（3）使用业务需求标准模板
1．引言
1.1 编写目的
如题，描述你编写这篇文档的目的和作用。但最关键的是，详细说明哪些人可以使用这篇文档，做什么。业务需求文档是用来做什么的？毫无疑问，首先供用户与开发公司确认软件开发的业务需求、功能范围。其次呢，当然就是指导设计与开发人员设计开发系统。当然，还包括测试人员设计测试，技术服务人员编写用户手册，以及其它相关人员熟悉系统。描述这些，可以帮助读者确定，阅读这篇文档是否可以从中获得帮助。
1.2 业务背景
描述业务背景，是为了读者了解与该文档相关的人与事。可以描写与项目相关的单位
现状、问题分析与解决思路，以及触发开发该项目的大背景、政策法规，等等。
1.3 项目目标（或任务概述）
就是项目能为用户带来什么利益，解决用户什么问题，或者说怎样才算项目成功。
1.4 参考资料
参考资料的名称、作者、版本、编写日期。
1.5 名词定义
文档中可能使用的各种术语或名词的定义与约定，可以根据需要删减。
2．整体概述
这部分可以对系统进行一个整体性框架性地描述。
还可以根据项目需要编写其它的内容，如部署方案、网络设备、功能结构、软件架构、关键点难点技术方案，等等。
3. 功能需求
一个一个的详细描述系统中的每个功能模块（或子系统），包括业务描述、功能描述、输入输出、表单样式、报表样式、数据来源等等。这部分是业务需求文档中最主要的部分。
3.1 功能描述
可以用自然语言描述模块的功能。对一些流程性的事务，用自然语言比较繁琐的，可以画流程图来辅助描述。
3.2 实现方式
从用户界面的角度，描述系统的功能。比如界面应该有哪些元素，怎样排列摆放，点击不同的元素产生怎样的效果等等。
4. 非功能性需求
主要关注系统的性能、安全性、可靠性、易用性等等。
写业务需求文档最容易忽略的就是非功能需求。非功能需求更加靠近的是技术，是设计，是实现，是需求人员最不擅长的方面，这也是非功能需求为什么常常被忽略的重要原因。
例：内网考勤要支持高并发操作（预计并发用户峰值：xxx ）。有了这些描述，设计和开发人员会着重注意该功能的性能问题，测试人员也可以着重进行该部分的性能测试。
例：数据导出功能，这看似一个非常普通的功能。但是如果一次性导出的数据量太大，可能达到数万条甚至数十万条，要将数十万数据一次性地导入到一个excel 文件中，这不论从运行效率、系统稳定性，还是技术可行性分析都是不可取的。可以约定一次最多导出2万条，同时提供了分页导出的功能，可以选择导出从第几页到第几页的数据。这样，如果
数据量大，用户可以经过多次将数据导出，数据导出的性能得以保证。
可支持性：在需求分析与设计阶段，可支持性实际上体现在，我们是否能有效识别系统可变的需求，并能够提供合理的方案。例如某个报表在查询条件、过滤条件、显示列等部分经常变，因此设计成一套可配置的报表系统，大大提高了系统可维护性。
对指标体系的变化，如果事先可以预见，则做成可配置可定制的。
3. 业务文档编写的一般原则
（1）完整性：对具体需求的描述应该完整清楚。可以让团队的技术人员的从开发人员的立场阅读文档，看看是否需要编写者的额外解释来理解需。如果是的话，说明需求还需要细化。
（2）一致性：对于同一业务描写，不能出现多义性的描述，应当是一致，相互之间没有矛盾。
（3）避免在多处叙述同一需求：因为一个需求需要更新时，所有对它的描述都必须更新，否则容易导致不一致性，给阅读人员带来困惑。
例：“执行任务时，系统应在不少于每60秒的正常周期内显示出状态信息”。
这个需求是不完整的，有几处含糊：状态信息是什么，如何显示给用户？状态信息间隔真的假定为不少于60秒？每小时甚至每十年显示一条新的状态信息也可以？也许它的意图是显示状态信息的间隔不应超过60秒，那么1毫秒是不是太短？
经过上述分析，重写需求的一种方法如下：1. 在用户界面的XX 位置显示状态信息，状态的刷新间隔为60秒；2. 如果后台进程处理正常，那么应该显示任务已完成的百分比；3. 任务完成时，应显示相关的信息；4. 任务出错时，应该显示XX 错误信息。
例：“如果可能的话，还应瞬间显示出所有下级分支机构的名称。”
该需求中的“如果可能的话”意味着什么，是不是该需求可有可无？还是该需求是否在技术上可行？还是能不能获取到下级分支机构的名称？
重写后如下：如果存在下级分支机构，应当在2秒内显示出所有下级分支机构的名称。
三、案例展示与分析
一、背景知识介绍
1. 软件工程的基本思想
在计算机发展初期，软件规模小，文档资料通常也不存在，很少使用系统化的开发方法。随着软件规模逐渐增大，复杂程度越来越高，软件可靠性问题也越来越突出。原来的个人设计、个人使用的方式不再能满足要求，迫切需要改变软件生产方式，提高软件生产率。你不能用制造小木船的方法制造航空母舰。
软件工程学的基本思想就是将软件当作一种工程产品来处理，从时间角度对软件开发和维护的复杂问题进行分解，把软件生命的漫长周期依次划分为若干个相对独立的阶段，并给每个阶段赋予明确而有限的任务。
2. 需求分析决定项目成败
随着人们对软件危机的认识和研究，软件工程方法也取得了一些实用的发展和进步，但软件项目的开发成功率仍然不高，大多数项目依旧处于超进度、超成本状态。在这些失败的项目中，需求不明确、需求不完整和需求变化等方面的因素占到了60％。正是如此，国内也渐渐开始重视需求分析这一软件开发的基础工作。
Carl Zetie在2006年1月的研究报告中指出：“需求定义不良或理解不正确，是导致付出的努力白费、重复工作以及项目失败的最大因素”。业内分析人员通过调查也发现需求分
析不准确、杂乱无章以及不完整是软件项目失败的首要因素。根据Standish Group 的年度CHAOS 报告，导致项目失败的五大原因中与需求相关的高达三个。
软件的需求分析是软件生存周期的重要阶段，它是联系用户与软件开发者的纽带，它的好坏对软件下一步的开发工作将产生决定性的影响。因此，对需求分析工作应该给予足够的重视，否则将对软件项目的开发工作造成严重的后患。如果软件开发者在对用户的需求没有充分了解之前，就急于进行设计和编程工作，这样设计出来的软件是无法满足用户要求的。软件使用中发生软件危机的原因之一就是需求分析工作未做好，软件人员和用户之间未能全面地、精确地理解和表达这些需求。
上述软件开发行业的现状表明以下几个方面的问题：1) 软件需求分析以及需求说明质量的提高是软件开发项目成败的关键要素之一；2) 及早地发现缺陷，特别是在软件需求分析阶段检测出缺陷并进行修改能够有效的降低软件产品的开发成本，提高软件的开发质量。
3. 软件需求说明书（业务需求文档）定义
软件需求说明书是对一个待开发的系统的描述，是系统开发人员与用户就产生一个什么样的系统相互交流的产物，是系统各项后续开发的基础。
4. 业务需求文档的作用
开发公司根据包含在软件需求说明书中描述的系统来估计开发成本，制定规划并预测进度安排、工作量和资源；
开发人员依赖它来理解他们将要开发的系统，并据此进行编码工作；
测试人员根据文档中对系统行为的描述制定测试计划、测试用例，进行测试工作。 系统运维人员和技术支持根据文档了解系统的功能；
根据业务需求文档编写用户手册。
业务需求文档是我们系统建设过程树立的一个正确的航标。有了这样一个航标，就可以使我们最终能够到达一个正确的彼岸。
二、如何撰写高质量的业务需求文档
1. 业务需求文档的常见问题
（1）需求过于简单。有的只是一句话，如“需要补录数据功能”，可以说，只给了一个需求题目，没有内容描述，具体业务处理流程和要求没有任何说明。
（2）需求内容不完整。业务需求洋洋洒洒写了不少，但仔细一看，整个需求说明书内
容缺东少西，要么少了界面输入项目，要么少了业务处理过程及要输出的结果等。
（3）需求内容描述不清晰。想要什么，业务流程如何处理，定义不清，概念界定模糊，有很多疑问。如需求文档中对于统计报表只是画出一个大概表样，没有给出统计口径、数据来源等详尽资料。
（4）需求不具有可行性。分不清在技术上什么能做什么不能做，例如试图从技术上解决腐败问题。
（5）需求文档没有统一撰写格式，不管是研发新产品、对现有系统功能改进、还是提取数据和生产问题需求，都没有一个简单实用的需求格式，随意书写，或者提供的格式完全不符合业务人员要求，大家不愿意或根本无法使用。
2. 提高撰写质量的措施
（1）业务人员和技术人员要建立良好的交流与合作关系。一般来说，技术人员对计算机软硬件系统比较熟悉，但对业务不太熟悉，而业务人员恰恰相反，他们熟悉自身的业务却不了解计算机技术，即使了解一些往往也是不系统的，因此，业务人员很难编写出质量较高的软件需求说明书，提供的往往是笼统的不规范的需求。这就需要通过用户和软件人员之间的交流来相互沟通，让用户了解计算机能干什么，对软件系统提出要求；而软件人员则必须花一段时间去认真分析业务人员究竟要求系统“做什么”，并把用户和软件人员共同理解的用户需求用“业务需求文档”准确地表达出来。提倡的让业务人员、技术人员、开发人员组成一个团队，使用统一的语言，来表达大家都清楚明白的概念。
（2）技术人员应该转变观念，积极参与业务需求的编写，不要认为业务需求与技术人员无关。
（3）使用业务需求标准模板
1．引言
1.1 编写目的
如题，描述你编写这篇文档的目的和作用。但最关键的是，详细说明哪些人可以使用这篇文档，做什么。业务需求文档是用来做什么的？毫无疑问，首先供用户与开发公司确认软件开发的业务需求、功能范围。其次呢，当然就是指导设计与开发人员设计开发系统。当然，还包括测试人员设计测试，技术服务人员编写用户手册，以及其它相关人员熟悉系统。描述这些，可以帮助读者确定，阅读这篇文档是否可以从中获得帮助。
1.2 业务背景
描述业务背景，是为了读者了解与该文档相关的人与事。可以描写与项目相关的单位
现状、问题分析与解决思路，以及触发开发该项目的大背景、政策法规，等等。
1.3 项目目标（或任务概述）
就是项目能为用户带来什么利益，解决用户什么问题，或者说怎样才算项目成功。
1.4 参考资料
参考资料的名称、作者、版本、编写日期。
1.5 名词定义
文档中可能使用的各种术语或名词的定义与约定，可以根据需要删减。
2．整体概述
这部分可以对系统进行一个整体性框架性地描述。
还可以根据项目需要编写其它的内容，如部署方案、网络设备、功能结构、软件架构、关键点难点技术方案，等等。
3. 功能需求
一个一个的详细描述系统中的每个功能模块（或子系统），包括业务描述、功能描述、输入输出、表单样式、报表样式、数据来源等等。这部分是业务需求文档中最主要的部分。
3.1 功能描述
可以用自然语言描述模块的功能。对一些流程性的事务，用自然语言比较繁琐的，可以画流程图来辅助描述。
3.2 实现方式
从用户界面的角度，描述系统的功能。比如界面应该有哪些元素，怎样排列摆放，点击不同的元素产生怎样的效果等等。
4. 非功能性需求
主要关注系统的性能、安全性、可靠性、易用性等等。
写业务需求文档最容易忽略的就是非功能需求。非功能需求更加靠近的是技术，是设计，是实现，是需求人员最不擅长的方面，这也是非功能需求为什么常常被忽略的重要原因。
例：内网考勤要支持高并发操作（预计并发用户峰值：xxx ）。有了这些描述，设计和开发人员会着重注意该功能的性能问题，测试人员也可以着重进行该部分的性能测试。
例：数据导出功能，这看似一个非常普通的功能。但是如果一次性导出的数据量太大，可能达到数万条甚至数十万条，要将数十万数据一次性地导入到一个excel 文件中，这不论从运行效率、系统稳定性，还是技术可行性分析都是不可取的。可以约定一次最多导出2万条，同时提供了分页导出的功能，可以选择导出从第几页到第几页的数据。这样，如果
数据量大，用户可以经过多次将数据导出，数据导出的性能得以保证。
可支持性：在需求分析与设计阶段，可支持性实际上体现在，我们是否能有效识别系统可变的需求，并能够提供合理的方案。例如某个报表在查询条件、过滤条件、显示列等部分经常变，因此设计成一套可配置的报表系统，大大提高了系统可维护性。
对指标体系的变化，如果事先可以预见，则做成可配置可定制的。
3. 业务文档编写的一般原则
（1）完整性：对具体需求的描述应该完整清楚。可以让团队的技术人员的从开发人员的立场阅读文档，看看是否需要编写者的额外解释来理解需。如果是的话，说明需求还需要细化。
（2）一致性：对于同一业务描写，不能出现多义性的描述，应当是一致，相互之间没有矛盾。
（3）避免在多处叙述同一需求：因为一个需求需要更新时，所有对它的描述都必须更新，否则容易导致不一致性，给阅读人员带来困惑。
例：“执行任务时，系统应在不少于每60秒的正常周期内显示出状态信息”。
这个需求是不完整的，有几处含糊：状态信息是什么，如何显示给用户？状态信息间隔真的假定为不少于60秒？每小时甚至每十年显示一条新的状态信息也可以？也许它的意图是显示状态信息的间隔不应超过60秒，那么1毫秒是不是太短？
经过上述分析，重写需求的一种方法如下：1. 在用户界面的XX 位置显示状态信息，状态的刷新间隔为60秒；2. 如果后台进程处理正常，那么应该显示任务已完成的百分比；3. 任务完成时，应显示相关的信息；4. 任务出错时，应该显示XX 错误信息。
例：“如果可能的话，还应瞬间显示出所有下级分支机构的名称。”
该需求中的“如果可能的话”意味着什么，是不是该需求可有可无？还是该需求是否在技术上可行？还是能不能获取到下级分支机构的名称？
重写后如下：如果存在下级分支机构，应当在2秒内显示出所有下级分支机构的名称。
三、案例展示与分析