如何编写信息系统开发业务需求报告

合集下载
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

• 例:“执行任务时,系统应在不少 于每60秒的正常周期内显示出状态 信息”。
• 重写需求的一种方法如下:1.在用户 界面的XX位置显示状态信息,状态的 刷新间隔为60秒;2.如果后台进程处 理正常,那么应该显示任务已完成的 百分比;3.任务完成时,应显示相关 的信息;4.任务出错时,应该显示XX 错误信息。
• 1.引言 • 1.1 编写目的
• 描述你编写这篇文档的目的和作用。但最 关键的是,详细说明哪些人可以使用这篇 文档,做什么。
• 1.2 业务背景 • 可以描写与项目相关的单位现状、问题分析与解 决思路,以及触发开发该项目的大背景、政策法 规,等等。 • 1.3 项目目标(或任务概述) • 就是项目能为用户带来什么利益,解决用户什么 问题,或者说怎样才算项目成功。 • 1.4 参考资料 • 参考资料的名称、作者、版本、编写日期。 • 1.5 名词定义 • 文档中可能使用的各种术语或名词的定义与约定, 可以根据需要删减。
2.提高撰写质量的措施
• (1)业务人员和技术人员要建立良好的交 流与合作关系。 • 提倡的让业务人员、技术人员、开发人员 组成一个团队,使用统一的语言,来表达 大家都清楚明白的概念。 • (2)技术人员应该转变观念,积极参与业 务需求的编写,不要认为业务需求与技术 人员无关。
(3)使用业务需求标准模板
4. 非功能性需求 • 主要关注系统的性能、安全性、可靠 性、易用性等等。 • 例:内网考勤要支持高并发操作(预 计并发用户峰值:xxx)。 • 例:数据导出功能。
• 可靠性就是系统可以可靠运行,包括 系统成熟度(数据吞吐量、并发用户 量、连续不停机性能等)、数据容错 度、系统易恢复性,等等。 • 可支持性:在需求分析与设计阶段, 可支持性实际上体现在,我们是否能 有效识别系统可变的需求,并能够提 供合理的方案。
阶段 可行性研究 需求分析 总体设计 详细设计 编码和单元测试
关键问题 系统建设是否可行? 系统必须做什么?
结束标准 可行性研究报告 软件需求说明书
概括地说,应该如何解决这个问题? 推荐的系统架构 怎样具体实现这个系统? 编写正确的程序模块 源程序清单;单元测 试方案和结果
综合测试 系统运维
符合要求的软件 持久的满足用户需要的软件
4.业务需求文档的作用
• 开发公司根据包含在软件需求说明书中描述的 系统来估计开发成本,制定规划并预测进度安 排、工作量和资源; • 开发人员依赖它来理解他们将要开发的系统, 并据此进行编码工作; • 测试人员根据文档中对系统行为的描述制定测 试计划、测试用例,进行测试工作。 • 系统运维人员和技术支持根据文档了解系统的 功能; • 根据业务需求文档编写用户手册。
怎样编写业务需求
• 一、背景知识介绍 • 二、如何编写高质量的业务需 求文档 • 三、实例分析与展示
ຫໍສະໝຸດ Baidu
一、背景知识介绍
1.软件工程学的基本思想
软件工程学的基本思想就是将软件 当作一种工程产品来处理,从时间角 度对软件开发和维护的复杂问题进行 分解,把软件生命的漫长周期依次划 分为若干个相对独立的阶段,并给每 个阶段赋予明确而有限的任务。
• 业务需求文档是我们系统建设过程 树立的一个正确的航标。有了这样 一个航标,就可以使我们最终能够 到达一个正确的彼岸。
二、如何撰写高质量的 业务需求文档
1. 业务需求文档的常见问题
(1)需求过于简单。 (2)需求内容不完整。 (3)需求内容描述不清晰。 (4)需求不具有可行性。 (5)需求文档没有统一撰写格式。
• 例:“如果可能的话,还应瞬间显 示出所有下级分支机构的名称。” • 重写后如下:如果存在下级分支机 构,应当在2秒内显示出所有下级 分支机构的名称。
三、案例展示与分析
• 2.整体概述
• 这部分可以对系统进行一个整 体性框架性地描述。
3. 功能需求 • 一个一个的详细描述系统中的每个功能模块(或 子系统),包括业务描述、功能描述、输入输出、 表单样式、数据来源等等。这部分是业务需求文 档中最主要的部分。 3.1 功能描述 • 可以用自然语言描述模块的功能。对一些流程性 的事务,用自然语言比较繁琐的,可以画流程图 来辅助描述。 3.2 实现方式 • 从用户界面的角度,描述系统的功能。
3. 业务需求文档编写的一般原则
• (1)完整性:对具体需求的描述应该完整 清楚。 • (2)一致性:对于同一业务描写,不能出 现多义性的描述,应当是一致,相互之间 没有矛盾。 • (3)避免在多处叙述同一需求:因为一个 需求需要更新时,所有对它的描述都必须 更新,否则容易导致不一致性,给阅读人 员带来困惑。
综合测试方案和结果
2.需求分析的重要性
• 1.在失败的项目中,需求不明确、需求不 完整和需求变化等方面的因素占到了60%。 • 2.软件的需求分析是软件生存周期的重要 阶段,它是联系用户与软件开发者的纽带。
3.业务需求文档的定义 • 业务需求文档是对一个待开发 的系统的描述,是系统开发人 员与用户就产生一个什么样的 系统相互交流的产物,是系统 各项后续开发的基础。
相关文档
最新文档