软件需求分析怎么写

⑴ 软件需求分析说明书中对性能的规定这部分怎么写啊

对性能的规定

1、精度

说明对该软件的输入、输出数据精度的要求，可能包括传输过程中的精度。

2、时间特性要求

说明对于该软件的时间特性要求，如对：

a、响应时间；

b、更新处理时间；

c、数据的转换和传送时间；

d、解题时间；等的要求。

3、灵活性

说明对该软件的灵活性的要求，即当需求发生某些变化时，该软件对这些变化的适应能力，如：

a、操作方式上的变化；

b、运行环境的变化；

c、同其他软件的接口的变化；

d、精度和有效时限的变化；

e、计划的变化或改进。

对于为了提供这些灵活性而进行的专门设计的部分应该加以标明。

4、输入输出要求

解释各输入输出数据类型，并逐项说明其媒体、格式、数值范围、精度等。对软件的数据输出及必须标明的控制输出量进行解释并举例，包括对硬拷贝报告（正常结果输出、状态输出及异常输出）以及图形或显示报告的描述。

5、数据管理能力要求

说明需要管理的文卷和记录的个数、表和文卷的大小规模，要按可预见的增长对数据及其分量的存储要求作出估算。

6、故障处理要求

列出可能的软件、硬件故障以及对各项性能而言所产生的后果和对故障处理的要求。

7、其他专门要求

如用户单位对安全保密的要求，对使用方便的要求，对可维护性、可补充性、易读性、可靠性、运行环境可转换性的特殊要求等。

(1)软件需求分析怎么写扩展阅读：

软件需求分析所要做的工作是深入描述软件的功能和性能，确定软件设计的限制和软件同其它系统元素的接口细节，定义软件的其它有效性需求。

进行需求分析时，应注意一切信息与需求都是站在用户的角度上。尽量避免分析员的主观想象，并尽量将分析进度提交给用户。在不进行直接指导的前提下，让用户进行检查与评价。从而达到需求分析的准确性。

分析员通过需求分析，逐步细化对软件的要求，描述软件要处理的数据域，并给软件开发提供一种可转化为数据设计、结构设计和过程设计的数据和功能表示。在软件完成后，制定的软件规格说明还要为评价软件质量提供依据。

⑵ 软件需求说明怎么写

如何写需求分析报告（软件需求说明书GB856T-88）

近来学校的一些科研项目又在申报了，一些学弟开始Q我一些软件工程上书面的问题。大概的总结了下，写到这里。本文涉及到的是需求分析部分的书写，主要是根据国家标准文档中的要求来的。

在互联网公司或者一些敏捷开发的公司里，其实大家都是秉承着重开发，重讨论，而轻文档的态度。这个轻文档并不是指没有文档或者几乎不做文档，而是在严格的文档流程中解脱出来，只把最最实际的部分写出来。这个特征是有互联网本身迭代周期短，版本发布快等特点决定的。而在实际的兼职项目的时候，同学们就要注意了，最重要的应该就是在签合同的时候一定要附上最清楚的一份需求分析，虽然这份需求说明可能不是按照某些标准文档而来的，描述清楚每个功能达到的效果，而这个效果一定要让客户点头确认，而不能出现“应该是”、“可能是”、“也许是”这样的模糊回答。否则在项目后期就会比较难过了。在学校申请的项目和大型公司项目开发中，是重视文档流程的，一部一部来。所以还是看情况来对待文档的深度和标准。

一、目录：目录要用word的“引用”—>”目录”，自动生成目录，一般都是要三级目录。通常这部分基本都不需要改结构，直接更新页码即可。

二、内容部分。国家标准软件需求说明书G856T-88下载

1引言

1.1编写目的

说明编写这份软件需求说明书的目的，指出预期的读者。

（这部分说明需求分析报告的概况，例如：本X需求分析报告是为S系统而编写的。+S系统的两句话概述。+本X报告旨在使U1（需求者）明确S系统的要求和细节，给U2(开发人员)了解需求实现的难度和困难，最终提供给U3（审核人、管理者）讨论和审核，达到沟通效果）

1.2背景

说明：

a．待开发的软件系统的名称；

b．本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络；

c．该软件系统同其他系统或其他机构的基本的相互来往关系。

（这部分可以将a,b,c分为2部分，例子如下：

1.2.1项目概况

本需求分析报告所预期开发的软件系统是:S。S是（不是则无）SS系统的某一个功能子模块，S和S1、S2等系统之间的联系，以及概述其他系统的状态等等。

1.2.2任务分配

a.任务提出者：xxx

b.软件开发者：xx

c.产品使用者：xx

d.文档编写者：xx

e.预期产品使用者：xx

）

1.3定义

列出本文件中用到的专门术语的定义和外文首字母组词的原词组。

（这部分很简单，就是描述专业词汇，比如

1. XML(Extensible Markup Language)即可扩展标记语言,它与HTML一样,都是SGML(Standard Generalized Markup Language,标准通用标记语言)。

2. Word2,解释。。。

）

1.4参考资料

列出用得着的参考资料，如：

a．本项目的经核准的计划任务书或合同、上级机关的批文；

b．属于本项目的其他已发表的文件；

c．本文件中各处引用的文件、资料、包括所要用到的软件开发标准。列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。

2任务概述

2.1目标

叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料。解释被开发软件与其他有关软件之间的关系。如果本软件产品是一项独立的软件，而且全部内容自含，则说明这一点。如果所定义的产品是一个更大的系统的一个组成部分，则应说明本产品与该系统中其他各组成部分之间的关系，为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。|

（

本模块开发主要是为SS的整体服务，完成SS工作中的XX部分以及相关的工作。其涉及的范围就是，从下达A、B命令后，到给出C结果的过程。具体描述：B1，来完成B11功能；B2，来完成B22功能；等等。本部分是（否）耦合在分词工具包其他部分中的，主要为嵌入方式和先后方式相互交互。

图

图1.该系统的组成同其他各部分的联系和接口

）

2.2用户的特点

列出本软件的最终用户的特点，充分说明操作人员、维护人员的教育水平和技术专长，以及本软件的预期使甩频度。这些是软件设计工作的重要约束

（例如：二次开发和系统调用人员：具有很高的专业知识水平，理解XX的运行机制。可以对开放代码进行阅读和分析，以完成其系统独特的需求，提供给这部分用户开放API手册和Debug版本的源代码即可；预期这部分用户会占本系统总用户量的多大部分。

xx使用者：具有一定的计算机操作能力和知识，了解xx领域的相关概念和用途。提供给这部分用户操作手册即可。预期这部分使用者主要是来简单的xx操作。

维护人员：具有较高的计算机专业水平，可以对常见的系统Bug进行追踪和分析，具有一定的测试能力。这部分用户主要是采用了本系统之后的后期工作维护者。

等等

）

2.3假定和约束

列出进行本软件开发工作的假定和约束，例如经费限制、开发期限等。

（这部分重要是对你有的技术力量、资金状况、人力资源等情况的假设，以使得你可以在什么样的情况和时间范围内完成工作。工期约束，经费约束，人员约束，地理约束，设备约束等几个方面列举说明。）

3需求规定

3.1对功能的规定

用列表的方式（例如IPO表即输入、处理、输出表的形式），逐项定量和定性地叙述对软件所提出的功能要求，说明输入什么量、经怎样的处理、得到什么输出，说明软件应支持的终端数和应支持的并行操作的用户数。

（例如：

INPUT输入

PROCESS处理

OUTPUT输出

LOAD负载量

A

预处理,做怎样的动作，

AA

CC

B

BBBB

Bb

v

C

CCCC

cc

v

表一、xx模块IPO表

对IPO表的简单文字描述。

）

3.2对性能的规定

3.2.1精度

说明对该软件的输入、输出数据精度的要求，可能包括传输过程中的精度。

（例如：

Xx目标处理：1Byt–10M，包括左右边界值。

yy精度范围：….

ZZ的精度：由于xx的特殊性，本系统均采用xx型来进行字符统计运算，概率部分以及其他比率部分精度精确到0.0x%。

）

3.2.2时间特性要求

说明对于该软件的时间特性要求，如对：

a．响应时间；

b．更新处理时间；

c．数据的转换和传送时间；

d．解题时间；等的要求。

(这部分只要一一列举就可以：

由于xxx过程中，需要大量xxxx操作或怎样，故xx解题时间占总时间的最大部分。其次就是xx转换和存储的开销。其具体时间特性要求，如下：

a．xx响应时间：xxms左右；

b．yy更新处理时间：yy；

c．zz数据的转换和传送时间：zz；

d．vv解题时间：vv。

等等

)

3.2.3灵活性

说明对该软件的灵活性的要求，即当需求发生某些变化时，该软件对这些变化的适应能力，如：

a．操作方式上的变化；

b．运行环境的变化；

c．同其他软件的接口的变化；

d．精度和有效时限的变化；

e．计划的变化或改进。

对于为了提供这些灵活性而进行的专门设计的部分应该加以标明。

（这部分按列举来即可，由于本模块第一目的是用于xxx，其次则是xxxx。故本模块的灵活性在于实际应用者的不同。当需求发生某些变化时，该软件对这些变化的适应能力。具体情况如下：

f．操作方式上的变化：采用集成运行制和独立运行制两种模式，集成运行制是把本模块嵌入到分词工具包的主框架中，提供给用户具有一定UI的可操作软件；独立运行制是可以独立运行于后台，并提供给各种程序调用的模式的工作方式，以增强其生命力。

g．运行环境的变化：主采用Windows平台的编译版本运行和调试，在时间允许的情况下，同步开发支持SUSE Linux的服务器版本。；

h．同其他软件的接口的变化：在尽量保证接口不出现变动的情况下，允许接口的重载和再定义。但接口的命名规则是统一的；

i．精度和有效时限的变化：精度在必须调整的条件下，可以上下浮动10个百分点；有效时限则依据现实的测试情况允许稍大范围的变化。

j．计划的变化或改进：工作时间安排会存在必然的浮动，这部分要协同分词工具包课题设计组其他成员一同来进行商定，前期的计划可以稍微有些变动，后期的安排尽量按照计划执行。

等等

）

3.3输人输出要求

解释各输入输出数据类型，并逐项说明其媒体、格式、数值范围、精度等。对软件的数据输出及必须标明的控制输出量进行解释并举例，包括对硬拷贝报告（正常结果输出、状态输出及异常输出）以及图形或显示报告的描述。

（这部分可以把输入输出分为3.3.1输入要求和3.3.2输出要求，如下给出一个单元的例子。

XXX输出

数据名称：XXX输出数据

实际含义：用于XX,表示XXXX

数据类型：Character(字符串)

数据格式：XX

数据约束：由于xxx,，大小在xx以内

）

3.4数据管理能力要求

说明需要管理的文卷和记录的个数、表和文卷的大小规模，要按可预见的增长对数据及其分量的存储要求作出估算。

（

根据实际系统要求列举即可

Name名称

Number数量

Size大小

Increase增长

词典xx

xx

xxxx

并行执行，其大小依据实际xx大文本而增长

）

3.5故障处理要求

列出可能的软件、硬件故障以及对各项性能而言所产生的后果和对故障处理的要求。

（包括软件压力，内存不足，硬件损坏等，这部分可以根据网络到其常见故障。）

3.6其他专门要求

如用户单位对安全保密的要求，对使用方便的要求，对可维护性、可补充性、易读性、可靠性、运行环境可转换性的特殊要求等。

（例如安全保密性：密钥更换等；预期扩展：扩展兼容等；OS更换：Slackware转SUSE等

）

4运行环境规定

4.1设备

列出运行该软件所需要的硬设备。说明其中的新型设备及其专门功能，包括：

a．处理器型号及内存容量；

b．外存容量、联机或脱机、媒体及其存储格式，设备的型号及数量；

c．输入及输出设备的型号和数量，联机或脱机；

d．数据通信设备的型号和数量；

e．功能键及其他专用硬件

（列举说明即可）

4.2支持软件

列出支持软件,包括要用到的操作系统、编译（或汇编）程序、测试支持软件等。

（操作系统和版本：xxxx

支撑环境和版本：xxxx

备用IDE环境和版本：xxxx

与该软件有关的软件组件：xxxx

后续可能扩展环境：xxxx

）

4.3接口

说明该软件同其他软件之间的接口、数据通信协议等。

(例如：

a．用户和主程序调用接口(图中接口1)。这个接口采用封装API形式和函数调用形式，分别以外部调用和内部调用的方式为不同用户提供使用本机械分词工具的入口。例如以xxxx方式调用DLL文件，以xxxx方式调用函数。如下图2所示。

图2.软件接口调用图

b.xx接口(图中接口2)。这里是一个xxx的接口调用过程。xxxx

)

4.4控制

说明控制该软件的运行的方法和控制信号，并说明这些控制信号的来源。

(例如：

下面通过图表的形式，将本模块以及涉及到本模块的软件模块的运行方法、控制信号，以及这些控制信号的来源，其中箭头所指方向对应的模块的控制信号来自箭头另一方向的模块，具体情况如下：

图3 .控制流程图

图3的具体说明情况如下表所示：

Name模块名称

Method运行方式

Signal控制信号

Forward控制去向

主程序模块

运行框架

用户调用或运行

1.调用xx模块

2.调用xx方法

3.调用标准输出模块

xxx模块

xxx

xxx调用

Xxx模块

)

附录：软件设计文档国家标准(GB8567–88)软件设计文档国家标准(GB8567–88)GB8567——88
操作手册（GB8567——88）.doc 数据库设计说明书（GB8567——88）.doc
测试分析报告（GB8567——88）.doc 数据要求说明书（GB856T——88）.doc
测试计划（GB8567——88）.doc 图1.doc
概要设计说明书（GB8567——88）.doc 文件给制实施规定的实例（GB8567-88）.doc
开发进度月报（GB8567——88）.doc 详细设计说明书（GB8567——88）.doc
可行性研究报告（GB8567——88）.doc 项目开发计划（GB856T——88）.doc
模块开发卷宗（GB8567——88）.doc 项目开发总结报告（GB8567——88）.doc
软件需求说明书（GB856T——88）.doc 用户手册（GB8567——88）.doc

⑶ 软件需求分析

自己上网查就能看到许多的版本！！

⑷ 软件的需求分析怎么写啊

1. 引言

1.1编写目的:编写此文档的目的是进一步定制软件开发的细节问题,便于用户与开发商协调工作.本文档面向的读者主要是项目委托单位的管理人员.希望能使本软件开发工作更具体.

1.2项目背景

1.2.1项目委托单位:****公司

1.2.2开发单位:***公司

1.3定义

1.4参考资料

2. 任务概述

2.1目标:

<1> 决策支持:根据公司的要求及时提供所需报表及文件,并在适当时候对各部门领导给予销售及进货等方面的提示

<2>提高效率:利用软件进行管理,避免人工管理的失误以及 延迟性,从而实现高效率的管理.

2.2运行环境:

<1> 硬件方面:Pentium级处理芯片
1兆显存的兼容显卡
256色,800*600的兼容显示器
标准兼容打印机

<2>软件方面: WIN95操作系统

2.3条件与限制:

编程用计算机一台
完成期限2000/7/1
无资金供给

3. 数据概述

数据流程图如下:

3.1静态数据:包括系统登录密码,各数据库所在位置,系统分析原始数据

3.2 动态数据:包括各数据库内各项显示数据,用户登录信息,系统时间

3.3数据库描述:

人事管理数据库:公司内人员的个人详细信息,包括档案信息
销售管理数据库:当日销售记录及以前的销售统计,用于销售分析
财务管理数据库:公司内部账目及收支情况详表
技术管理数据库:公司所需各技术档案的详细记录(包括文档)

3.4 数据字典:

<1>数据流词条描述:

1.数据流名:登录信息
来源:用户的输入
去向:系统内部检验部分
组成:用户名,密码
流通量:每次登录输入一次

2.数据流名:登录结果
来源:系统
去向:用户
组成:返回信息
流通量:每次登录返回一次

3.数据流名:输入修改信息
来源:用户
去向:系统判断部分
组成:根据各数据库内容而不同
流通量:依用户输入而定

4.数据流名:反馈信息
来源:系统判断部分
去向:用户
组成:系统经判断后发回的字符数据
流通量: 依系统当前信息而定

5.数据流名:识别信息
来源:系统内部检验部分
去向:系统判断部分
组成:系统各数据库的标识信息
流通量:用户每次输入流通一次

6.数据流名:处理信息
来源:系统判断部分
去向:各数据库处理部分
组成:读取/修改标识,读取/修改的变量名称
流通量:用户每次输入流通一次

7.数据流名:读取修改
来源:系统判断部分
去向:系统各数据库
组成:读取/修改标识,读取/修改内容
流通量: 用户每次输入流通一次

<2>数据文件词条描述:

1.数据文件名:人事数据
简述:存储人员信息
数据文件组成:人员的各项信息(以CString类型为主)

2.数据文件名:销售数据
简述:存储当日及从前的销售记录
数据文件组成:销售的各项信息

3.数据文件名:财务数据
简述:存储财务管理信息
数据文件组成:财务管理的各项记录

4.数据文件名:技术数据
简述:存储公司内部使用的技术档案信息
数据文件组成:技术档案名称,内容

<3>加工逻辑词条描述:

1.加工名:检验
简要描述:判断用户的许可性
输入数据流:登录信息
输出数据流:登录结果
加工逻辑:判断是否与系统内部用户信息相符合

2.加工名:判断
简要描述:判断用户的操作并进行相应的读取/存储工作
输入数据流:输入修改信息
输出数据流:反馈信息
加工逻辑:判断用户的操作->调用数据库->读取/修改->反馈

3.加工名:人事档案管理
简要描述:对人事数据库进行相应要求的操作,并与判断部分交互
输入数据流:处理信息,读取修改
输出数据流: 读取修改, 处理信息
加工逻辑:判断用户要读取/修改的内容->反馈用户所需信息

4.加工名:销售统计
简要描述:对销售数据库进行相应要求的操作,并与判断部分交互
输入数据流:处理信息,读取修改
输出数据流: 读取修改, 处理信息
加工逻辑:判断用户要读取/修改的内容->反馈用户所需信息

5.加工名:财务统计
简要描述:对财务数据库进行相应要求的操作,并与判断部分交互
输入数据流:处理信息,读取修改
输出数据流: 读取修改, 处理信息
加工逻辑:判断用户要读取/修改的内容->反馈用户所需信息

6.加工名:技术管理
简要描述:对技术统计数据库进行相应要求的操作,并与判断部分交互信息
输入数据流:处理信息,读取修改
输出数据流: 读取修改, 处理信息
加工逻辑:判断用户要读取/修改的内容->反馈用户所需信息

<4>源点及汇点词条描述:

名称:用户
简要描述:既是源点又是汇点,发出动作信息给"检验"和"判断"加工,通过交互界面接受反馈信息有关数据流:登录结果,登录信息,输入修改信息,反馈信息
数目:一个

4. 功能需求

4.1功能划分

可细分为四部分:人事管理,销售管理,财务管理,技术档案管理

4.2功能描述

<1>人事功能:

(1)能对公司内部的所有人员有关档案详细资料记录并保存。
(2)能对数据库内人事档案的数据进行查阅和修改。
(3)能按部门或姓名检索人员。
(4)当某员工的雇用期限达到整年时，按时提醒。

<2>销售统计功能

(1)按日对公司的销售情况进行统计,包括销售额\销售数量\各地区销售比例\不同销售方式的销售量比例以及销售毛利润情况
(2)制定销售情况的月报表\季报表以及年报表对销售情况进行分析,对不同销售人员的业绩进行评定

<3>财务管理功能

(1)协助财务人员进行计算机管理,对库存情况\进货情况\销货进行登录和输出
(2) 根据预设的库存情况提醒进货
(3) 对收款情况进行统计,在应收帐款达到预设值时进行提示

<4>技术管理功能

(1)对技术资料进行登录
(2)对维修记录进行登录和统计,按不同型号的机器进行故障整体分析,并作出分析报告
(3)对维修配件的需求进行管理并及时提示备货

5. 性能需求

5.1数据精确度:因为此数据为公司内部数据,所以要求不能有误差

5.2时间特性:当日销售统计要求有即时性,马上能反应出存货的问题;同时财务管理数据计算当前存货情况,并对进货情况进行估算

5.3 适应性:此软件只在公司内部管理人员的机器上使用,因此不考虑适应性

6. 运行需求

6.1用户界面:

屏幕格式:

(1)要求有菜单及工具栏以方便操作
(2)各数据库信息可在屏幕上直接修改
(3)各数据统计结果可在屏幕上显示
(4)进行系统分析后的结果在另一窗口中显示

报表格式:

(1)人事管理报表只要求有个人的普通数据
(2)销售统计报表要求可分别打印当日统计或之前的统计
(3)财务统计报表要求打印出存货及公司帐务详表
(4)技术管理报表要求可以分别打印技术档案总表和任一技术档案文档内容菜单格式:要求菜单项大致与WIN95标准相同,另外附加的功能做到新的单项中输入输出时间:年份以4位数字表示

6.2硬件接口:需要标准打印机接口进行报表打印

6.3 软件接口:Windows标准接口

7. 其他需求

可使用性:要求容易使用,界面友好

安全保密性:因本数据属于公司内部管理用关键数据,因此除公司管理人员外,其他人员不得访问.要求设有登录密码检验功能,并且此密码可以在以后进行修改

可维护性:要求本软件的维护文档齐全,便于维护

⑸ 需求分析实例软件的需求分析一般怎么写

正好我参加日本的软件比赛时写过 这是我那时候些的需求分析设计书的目录 你看看吧
一. 智能家居背景介绍... 3
（一）. 背景介绍... 3
二. 语音识别智能家居解决方案... 4
（一）. 方案总体介绍... 4
（二）. 语音识别智能家居解决方案实现原理... 6
（三）. 无线技术... 7
三. 方案实例——语音识别智能百叶窗帘... 8
（一）. 实例简介... 8
（二）. 系统功能... 8
（三）. 详细实现... 9
1. 硬件设计... 9
2. 软件设计思路... 12
（四）. 操作方法及步骤... 14
1. 训练：... 14
2. 识别阶段:. 14
四. 总结... 15

⑹ 怎样写软件开发需求分析

1、需求分析文档的重要性
在软件项目开发的生命周期中，可以说需求分析文档占据着很重要的作用。
（1）它是和用户进行交流得出的一个规范结果
（2）它是衡量和评价项目功能是否达到用户需要的标准
（3）它对后期的数据库设计、概要设计、详细设计以及整个编码开发、系统测试起着指引的作用

⑺ 软件 开发项目 需求分析 怎么写最好给个案例看看

代理商和旅游景点管理系统项目开发背景 消费劵管理系统是一个面向广大客户来源以及一个和代理商的业务流程的一个项目，由于该系统涉及的客户面和业务较广，系统的各项功能与各项管理消费劵息息相关，因此做好项目系统需求分析显得至关重要。根据实际情况采用各种技术手段对消费劵的管理，争取代理商、景点和客户之间得到最大限度的需求。编写的目的 为了让开发人员能够很快的了解该项目，了解该项目的需求，知道该项目的具体实现的功能，通过文档信息知道了该项目所涉及到的数据库表和每个表有哪些字段。项目系统需求分析 代理商：1、 代理商以5折优惠从景点出购买消费劵（消费劵有面值不等的，目前未知）。2、 代理商预付一定的预付款（如5万元）从景点处购入2倍的消费劵（就是10万元）。3、 代理商卖出给客户均以7折卖出4、 代理商预付款余额不得低于一定的金额（未知。如：预付款余额不低于2000等）。5、 代理商在预付款余额低于一定的金额后，需要及时补充（如：几个工作日内景点收到补充的预付款）。景点：1、 景点对客户使用的消费劵进行消费劵验证（如：消费劵卡号验证，是否已过期等）。2、 景点对客户所使用的消费劵不得以任何方式返还（如：消费劵1000，用去900，那么也不得返还100元金额）。客户：1、客户使用消费劵必须在消费劵能使用的范围2、客户在使用消费劵必须在消费劵的有效期内使用，预期作废。3、客户使用消费劵消费时，若消费金额＞实际消费金额，应付实际消费金额—消费劵金额。共同补充：1、 预付款余额=预付款当前余额—客户实际消费金额（备注：若客户使用1000元的消费劵消费了800，那么客户实际消费金额=800）功能分析描述 根据登陆人员的权限不同，页面不同所执行不同的操作登陆功能 1、 经理登陆管理2、 员工登陆操作登陆功能描述 1、 代理商经理登陆，经理有权限完善资料，建立工作组，员工信息的录入。添加景点以及景点的相关信息（如：景点的名称，景点的地点，景点经理的联系方式）。管理财政，查看每个景点消费劵的售出量和使用量，对账单，对账表，根据实际情况，打印各个景点的消费劵和消费劵的面值，打印消费劵的数目、该消费劵的折扣，信息都录入数据。根据消费劵的售出情况计算所得的利润。查看预付款余额，不足的及时补充。2、 代理商员工登陆，登陆出售消费劵界面，激活消费劵的金额，记录每个景点的出售的消费劵的面额（激活的），各个景点的消费劵的出售数量。3、 景点经理登陆，经理完善资料，建立工作组，员工信息的录入，添加代理商以及代理商的信息（如：代理商的名称，代理商的地点，代理商经理的联系方式）。查看每个代理商在我们景点销售情况及使用情况。查看每个代理商的预付款余额是否已不足（不足提示该代理商），对账单，对账表。4、 景点员工登陆，登陆收费系统，验证客户所使用的消费劵是否已激活，该客户使用的消费劵是哪个代理商出售的，该消费劵的金额是多少，哪一天消费的，都记录下来。项目涉及数据的分析代理商和景点数据分析 1、代理商和景点的角色分析：经理，员工，涉及到的就是用户名（username），先不用管它是经理还是员工，后面有该用户的权限的，我分析的数据：代理商用户表（AgentUser）主键AIDNumber用户名AUserNameVarchar（10）用户密码AUserPasswordVarchar（20）用户权限（角色表外键）AUserRightsNumber↓角色表主键RIDNumber角色RoleVarchar（12）2、景点信息表：景点信息表主键SIDNumber景点名称ScenicSpotNameVarchar（30）景点地址ScenicSpotAddressVarchar（100）景点联系电话ScenicSpotNOVarchar（15）景点折扣ScenicSpotDisCountNumber消费劵数据分析 消费劵信息表主键CCIDVarcher（20）消费劵面值CCMoneyNumber消费劵属于哪个景点（景点信息表外键）SIDVarchar（20）消费劵折扣SDiscountNumer详细账单表 账单表主键ZidVarcher（20）金额MoneyNumber属于哪个景点（景点信息表外键）SIDNumer对账单，对账表分析 1、 按一定的是时间（比如一个月）会生成一个具体的账单以便于在管理人员的查看和管理，代理商对每个景点的销售消费劵的情况和景点对每个代理商销售的情况都记录保存。2、 按一个月算每个月双方要对账单。打印消费劵分析 1、 不能打印任何面值两个相同的卡号，用一个软件以一个数字开头进行递增。2、 打印每个景点的消费劵，根据该景点在我们代理商的销售情况，按实际情况进行打印（面值，张数）最后补充一个，客户是不是可以上网查询自己的消费劵真假面值，目前在考虑

⑻ 软件需求分析范文

http://www.souku.com.cn/dasous.jsp?key=%C8%ED%BC%FE%B1%A8%B8%E6&search_type=ALL
这里有很多，你到网上搜一下应该有。
参考资料：www.souku.com.cn

http://www.8wen.com/search/docs/%C8%ED%BC%FE%D0%E8%C7%F3%B7%D6%CE%F6%C0%FD%CE%C4/1
呵呵，希望能帮到你

⑼ 项目需求分析怎么写

项目需求分析的概念需求分析是指理解用户需求，就软件功能与客户达成一致，估计软件风险和评估项目代价，最终形成开发计划的一个复杂过程。（这个和我在微软体验到的又不太一样，微软的需求分析大多是市场人员和用户协助小组的人去评估用户的接受程度，这一点也可以理解，因为公司的性质有根本差别）在这个过程中，用户的确是处在主导地位，需求分析工程师和项目经理要负责整理用户需求，为之后的软件设计打下基础。需求分析阶段结束后，要求得到：1.SRS文档(System Requirement Specification); 2.DRM 文档；3.Acceptance Plan. 从广义上理解：需求分析包括需求的获取、分析、规格说明、变更、验证、管理的一系列需求工程。
狭义上理解：需求分析指需求的分析、定义过程。 一、为什么要需求分析需求分析就是分析软件用户的需求是什么.如果投入大量的人力，物力,财力,时间,开发出的软件却没人要,那所有的投入都是徒劳.如果费了很大的精力,开发一个软件,最后却不满足用户的要求,从而要重新开发过,这种返工是让人痛心疾首的.(相信大家都有体会)比如,用户需要一个for linux的软件,而你在软件开发前期忽略了软件的运行环境,忘了向用户询问这个问题,而想当然的认为是开发for windows的软件,当你千辛万苦地开发完成向用户提交时才发现出了问题,那时候你是欲哭无泪了,痕不得找块豆腐一头撞死.
需求分析之所以重要,就因为他具有决策性,方向性,策略性的作用,他在软件开发的过程中具有举足轻重的地位.大家一定要对需求分析具有足够的重视.在一个大型软件系统的开发中,他的作用要远远大于程序设计. 二、需求分析的任务简言之,需求分析的任务就是解决"做什么"的问题,就是要全面地理解用户的各项要求,并准确地表达所接受的用户需求.三、需求分析的过程需求分析阶段的工作,可以分为四个方面:问题识别,分析与综合,制订规格说明,评审.
问题识别
就是从系统角度来理解软件,确定对所开发系统的综合要求,并提出这些需求的实现条件,以及需求应该达到的标准.这些需求包括：功能需求(做什么),性能需求(要达到什么指标),环境需求(如机型,操作系统等),可靠性需求(不发生故障的概率）,安全保密需求,用户界面需求,资源使用需求(软件运行是所需的内存,CPU等),软件成本消耗与开发进度需求,预先估计以后系统可能达到的目标.
分析与综合
逐步细化所有的软件功能,找出系统各元素间的联系,接口特性和设计上的限制,分析他们是否满足需求,剔除不合理部分,增加需要部分.最后,综合成系统的解决方案,给出要开发的系统的详细逻辑模型(做什么的模型).
制订规格说明书
即编制文档,描述需求的文档称为软件需求规格说明书.请注意,需求分析阶段的成果是需求规格说明书(好象软考曾经考过这个问题),向下一阶段提交.
评审
对功能的正确性,完整性和清晰性,以及其它需求给予评价.评审通过才可进行下一阶段的工作,否则重新进行需求分析。 四、需求分析的方法需求分析的方法有很多.这里只强调原型化方法,其它的方法如:结构化方法,动态分析法等(个人认为,对初学者不必深究这些方法,实际上我也从来没用过这些方法)在此不讨论.
原型化方法是十分重要的(是软考等常考的知识点).原型就是软件的一个早期可运行的版本,它实现了目标系统的某些或全部功能.
原型化方法就是尽可能快地建造一个粗糙的系统,这系统实现了目标系统的某些或全部功能,但是这个系统可能在可靠性,界面的友好性或其他方面上存在缺陷.建造这样一个系统的目的是为了考察某一方面的可行性,如算法的可行性,技术的可行性,或考察是否满足用户的需求等.如,为了考察是否满足用户的要求,可以用某些软件工具快速的建造一个原型系统,这个系统只是一个界面,然后听取用户的意见,改进这个原型.以后的目标系统就在原型系统的基础上开发.
原型主要有三种类型(软考考过):探索型,实验型,进化型.探索型:目的是要弄清楚对目标系统的要求,确定所希望的特性,并探讨多种方案的可行性.实验型:用于大规模开发和实现前,考核方案是否合适,规格说明是否可靠.进化型:目的不在于改进规格说明,而是将系统建造得易于变化,在改进原型的过程中,逐步将原型进化成最终系统。
在使用原型化方法是有两种不同的策略:废弃策略,追加策略.废弃策略:先建造一个功能简单而且质量要求不高的模型系统，针对这个系统反复进行修改,形成比较好的思想,据此设计出较完整,准确,一致,可靠的最终系统.系统构造完成后,原来的模型系统就被废弃不用.探索型和实验型属于这种策略。
追加策略:先构造一个功能简单而且质量要求不高的模型系统，作为最终系统的核心,然后通过不断地扩充修改,逐步追加新要求，发展成为最终系统。进化型属于这种策略.