如何编写信息系统开发业务需求_第1页
如何编写信息系统开发业务需求_第2页
如何编写信息系统开发业务需求_第3页
如何编写信息系统开发业务需求_第4页
如何编写信息系统开发业务需求_第5页
已阅读5页,还剩17页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

1、怎样编写业务需求 一、背景知识介绍 二、如何编写高质量的业务需求文档 三、实例分析与展示一、背景知识介绍1.软件工程学的基本思想 软件工程学的基本思想就是将软件软件工程学的基本思想就是将软件当作一种工程产品来处理,从时间角当作一种工程产品来处理,从时间角度对软件开发和维护的复杂问题进行度对软件开发和维护的复杂问题进行分解,把软件生命的漫长周期依次划分解,把软件生命的漫长周期依次划分为若干个相对独立的阶段,并给每分为若干个相对独立的阶段,并给每个阶段赋予明确而有限的任务。个阶段赋予明确而有限的任务。阶段阶段关键问题关键问题结束标准结束标准可行性研究系统建设是否可行?可行性研究报告需求分析系统必须

2、做什么?软件需求说明书总体设计概括地说,应该如何解决这个问题? 推荐的系统架构详细设计怎样具体实现这个系统?编码和单元测试编写正确的程序模块源程序清单;单元测试方案和结果综合测试符合要求的软件综合测试方案和结果系统运维持久的满足用户需要的软件2.需求分析的重要性 1.在失败的项目中,需求不明确、需求不完整和需求变化等方面的因素占到了60。 2.软件的需求分析是软件生存周期的重要阶段,它是联系用户与软件开发者的纽带。3.业务需求文档的定义 业务需求文档是对一个待开发的系统的描述,是系统开发人员与用户就产生一个什么样的系统相互交流的产物,是系统各项后续开发的基础。4.业务需求文档的作用 开发公司根

3、据包含在软件需求说明书中描述的开发公司根据包含在软件需求说明书中描述的系统来估计开发成本,制定规划并预测进度安系统来估计开发成本,制定规划并预测进度安排、工作量和资源;排、工作量和资源; 开发人员依赖它来理解他们将要开发的系统,开发人员依赖它来理解他们将要开发的系统,并据此进行编码工作;并据此进行编码工作; 测试人员根据文档中对系统行为的描述制定测测试人员根据文档中对系统行为的描述制定测试计划、测试用例,进行测试工作。试计划、测试用例,进行测试工作。 系统运维人员和技术支持根据文档了解系统的系统运维人员和技术支持根据文档了解系统的功能;功能; 根据业务需求文档编写用户手册。根据业务需求文档编写

4、用户手册。 业务需求文档是我们系统建设过程业务需求文档是我们系统建设过程树立的一个正确的航标。有了这样树立的一个正确的航标。有了这样一个航标,就可以使我们最终能够一个航标,就可以使我们最终能够到达一个正确的彼岸到达一个正确的彼岸。二、如何撰写高质量的二、如何撰写高质量的业务需求文档业务需求文档1. 业务需求文档的常见问题(1)需求过于简单。(2)需求内容不完整。(3)需求内容描述不清晰。(4)需求不具有可行性。(5)需求文档没有统一撰写格式。2.提高撰写质量的措施 (1)业务人员和技术人员要建立良好的交流与合作关系。 提倡的让业务人员、技术人员、开发人员提倡的让业务人员、技术人员、开发人员组成

5、一个团队,使用统一的语言,来表达组成一个团队,使用统一的语言,来表达大家都清楚明白的概念。大家都清楚明白的概念。 (2)技术人员应该转变观念,积极参与业务需求的编写,不要认为业务需求与技术人员无关。(3)使用业务需求标准模板 1引言 1.1 编写目的 描述你编写这篇文档的目的和作用。但最关键的是,详细说明哪些人可以使用这篇文档,做什么。 1.2 业务背景 可以描写与项目相关的单位现状、问题分析与解决思路,以及触发开发该项目的大背景、政策法规,等等。 1.3 项目目标(或任务概述) 就是项目能为用户带来什么利益,解决用户什么问题,或者说怎样才算项目成功。 1.4 参考资料 参考资料的名称、作者、

6、版本、编写日期。 1.5 名词定义 文档中可能使用的各种术语或名词的定义与约定,可以根据需要删减。 2整体概述 这部分可以对系统进行一个整体性框架性地描述。3. 功能需求 一个一个的详细描述系统中的每个功能模块(或子系统),包括业务描述、功能描述、输入输出、表单样式、数据来源等等。这部分是业务需求文档中最主要的部分。3.1 功能描述 可以用自然语言描述模块的功能。对一些流程性的事务,用自然语言比较繁琐的,可以画流程图来辅助描述。3.2 实现方式 从用户界面的角度,描述系统的功能。4. 非功能性需求 主要关注系统的性能、安全性、可靠性、易用性等等。 例:内网考勤要支持高并发操作(预计并发用户峰值

7、:xxx)。 例:数据导出功能。 可靠性就是系统可以可靠运行,包括系统成熟度(数据吞吐量、并发用户量、连续不停机性能等)、数据容错度、系统易恢复性,等等。 可支持性:在需求分析与设计阶段,可支持性实际上体现在,我们是否能有效识别系统可变的需求,并能够提供合理的方案。 3. 业务需求文档编写的一般原则 (1)完整性:对具体需求的描述应该完整清楚。 (2)一致性:对于同一业务描写,不能出现多义性的描述,应当是一致,相互之间没有矛盾。 (3)避免在多处叙述同一需求:因为一个需求需要更新时,所有对它的描述都必须更新,否则容易导致不一致性,给阅读人员带来困惑。 例:“执行任务时,系统应在不少于每60秒的正常周期内显示出状态信息”。 重写需求的一种方法如下:1.在用户界面的XX位置显示状态信息,状态的刷新间隔为60秒;2.如果后台进程处理正常,那么应该显示任务已完成的百分比;

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论