如何写需求分析报告(软件需求说明书GB856T-88)
近来学校的一些科研项目又在申报了,一些学弟开始Q我一些软件工程上书面的问题。大概的总结了下,写到这里。本文涉及到的是需求分析部分的书写,主要是根据国家标准文档中的要求来的。
在互联网公司或者一些敏捷开发的公司里,其实大家都是秉承着重开发,重讨论,而轻文档的态度。这个轻文档并不是指没有文档或者几乎不做文档,而是在严格的文档流程中解脱出来,只把最最实际的部分写出来。这个特征是有互联网本身迭代周期短,版本发布快等特点决定的。而在实际的兼职项目的时候,同学们就要注意了,最重要的应该就是在签合同的时候一定要附上最清楚的一份需求分析,虽然这份需求说明可能不是按照某些标准文档而来的,描述清楚每个功能达到的效果,而这个效果一定要让客户点头确认,而不能出现“应该是”、“可能是”、“也许是”这样的模糊回答。否则在项目后期就会比较难过了。在学校申请的项目和大型公司项目开发中,是重视文档流程的,一部一部来。所以还是看情况来对待文档的深度和标准。
一、目录:目录要用word的“引用”—>”目录”,自动生成目录,一般都是要三级目录。通常这部分基本都不需要改结构,直接更新页码即可。
二、内容部分。国家标准软件需求说明书G856T-88下载
1引言
11编写目的
说明编写这份软件需求说明书的目的,指出预期的读者。
(这部分说明需求分析报告的概况,例如:本X需求分析报告是为S系统而编写的。+S系统的两句话概述。+本X报告旨在使U1(需求者)明确S系统的要求和细节,给U2(开发人员)了解需求实现的难度和困难,最终提供给U3(审核人、管理者)讨论和审核,达到沟通效果)
12背景
说明:
a.待开发的软件系统的名称;
b.本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络;
c.该软件系统同其他系统或其他机构的基本的相互来往关系。
(这部分可以将a,b,c分为2部分,例子如下:
121项目概况
本需求分析报告所预期开发的软件系统是:S。S是(不是则无)SS系统的某一个功能子模块,S和S1、S2等系统之间的联系,以及概述其他系统的状态等等。
122任务分配
a任务提出者:xxx
b软件开发者:xx
c产品使用者:xx
d文档编写者:xx
e预期产品使用者:xx
)
13定义
列出本文件中用到的专门术语的定义和外文首字母组词的原词组。
(这部分很简单,就是描述专业词汇,比如
1XML(ExtensibleMarkupLanguage)即可扩展标记语言,它与HTML一样,都是SGML(StandardGeneralizedMarkupLanguage,标准通用标记语言)。
2Word2,解释。。。
)
14参考资料
列出用得着的参考资料,如:
a.本项目的经核准的计划任务书或合同、上级机关的批文;
b.属于本项目的其他已发表的文件;
c.本文件中各处引用的文件、资料、包括所要用到的软件开发标准。列出这些文件资料的标题、文件编号、发表日期和出版单位,说明能够得到这些文件资料的来源。
2任务概述
21目标
叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料。解释被开发软件与其他有关软件之间的关系。如果本软件产品是一项独立的软件,而且全部内容自含,则说明这一点。如果所定义的产品是一个更大的系统的一个组成部分,则应说明本产品与该系统中其他各组成部分之间的关系,为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。|
(
本模块开发主要是为SS的整体服务,完成SS工作中的XX部分以及相关的工作。其涉及的范围就是,从下达A、B命令后,到给出C结果的过程。具体描述:B1,来完成B11功能;B2,来完成B22功能;等等。本部分是(否)耦合在分词工具包其他部分中的,主要为嵌入方式和先后方式相互交互。
图
图1该系统的组成同其他各部分的联系和接口
)
22用户的特点
列出本软件的最终用户的特点,充分说明 *** 作人员、维护人员的教育水平和技术专长,以及本软件的预期使甩频度。这些是软件设计工作的重要约束
(例如:二次开发和系统调用人员:具有很高的专业知识水平,理解XX的运行机制。可以对开放代码进行阅读和分析,以完成其系统独特的需求,提供给这部分用户开放API手册和Debug版本的源代码即可;预期这部分用户会占本系统总用户量的多大部分。
xx使用者:具有一定的计算机 *** 作能力和知识,了解xx领域的相关概念和用途。提供给这部分用户 *** 作手册即可。预期这部分使用者主要是来简单的xx *** 作。
维护人员:具有较高的计算机专业水平,可以对常见的系统Bug进行追踪和分析,具有一定的测试能力。这部分用户主要是采用了本系统之后的后期工作维护者。
等等
)
23假定和约束
列出进行本软件开发工作的假定和约束,例如经费限制、开发期限等。
(这部分重要是对你有的技术力量、资金状况、人力资源等情况的假设,以使得你可以在什么样的情况和时间范围内完成工作。工期约束,经费约束,人员约束,地理约束,设备约束等几个方面列举说明。)
3需求规定
31对功能的规定
用列表的方式(例如IPO表即输入、处理、输出表的形式),逐项定量和定性地叙述对软件所提出的功能要求,说明输入什么量、经怎样的处理、得到什么输出,说明软件应支持的终端数和应支持的并行 *** 作的用户数。
(例如:
INPUT输入
PROCESS处理
OUTPUT输出
LOAD负载量
A
预处理,做怎样的动作,
AA
CC
B
BBBB
Bb
v
C
CCCC
cc
v
表一、xx模块IPO表
对IPO表的简单文字描述。
)
32对性能的规定
321精度
说明对该软件的输入、输出数据精度的要求,可能包括传输过程中的精度。
(例如:
Xx目标处理:1Byt_10M,包括左右边界值。
yy精度范围:
ZZ的精度:由于xx的特殊性,本系统均采用xx型来进行字符统计运算,概率部分以及其他比率部分精度精确到00x%。
)
322时间特性要求
说明对于该软件的时间特性要求,如对:
a.响应时间;
b.更新处理时间;
c.数据的转换和传送时间;
d.解题时间;等的要求。
(这部分只要一一列举就可以:
由于xxx过程中,需要大量xxxx *** 作或怎样,故xx解题时间占总时间的最大部分。其次就是xx转换和存储的开销。其具体时间特性要求,如下:
a.xx响应时间:xxms左右;
b.yy更新处理时间:yy;
c.zz数据的转换和传送时间:zz;
d.vv解题时间:vv。
等等
)
323灵活性
说明对该软件的灵活性的要求,即当需求发生某些变化时,该软件对这些变化的适应能力,如:
a. *** 作方式上的变化;
b.运行环境的变化;
c.同其他软件的接口的变化;
d.精度和有效时限的变化;
e.计划的变化或改进。
对于为了提供这些灵活性而进行的专门设计的部分应该加以标明。
(这部分按列举来即可,由于本模块第一目的是用于xxx,其次则是xxxx。故本模块的灵活性在于实际应用者的不同。当需求发生某些变化时,该软件对这些变化的适应能力。具体情况如下:
f. *** 作方式上的变化:采用集成运行制和独立运行制两种模式,集成运行制是把本模块嵌入到分词工具包的主框架中,提供给用户具有一定UI的可 *** 作软件;独立运行制是可以独立运行于后台,并提供给各种程序调用的模式的工作方式,以增强其生命力。
g.运行环境的变化:主采用Windows平台的编译版本运行和调试,在时间允许的情况下,同步开发支持SUSELinux的服务器版本。;
h.同其他软件的接口的变化:在尽量保证接口不出现变动的情况下,允许接口的重载和再定义。但接口的命名规则是统一的;
i.精度和有效时限的变化:精度在必须调整的条件下,可以上下浮动10个百分点;有效时限则依据现实的测试情况允许稍大范围的变化。
j.计划的变化或改进:工作时间安排会存在必然的浮动,这部分要协同分词工具包课题设计组其他成员一同来进行商定,前期的计划可以稍微有些变动,后期的安排尽量按照计划执行。
等等
)
33输人输出要求
解释各输入输出数据类型,并逐项说明其媒体、格式、数值范围、精度等。对软件的数据输出及必须标明的控制输出量进行解释并举例,包括对硬拷贝报告(正常结果输出、状态输出及异常输出)以及图形或显示报告的描述。
(这部分可以把输入输出分为331输入要求和332输出要求,如下给出一个单元的例子。
XXX输出
数据名称:XXX输出数据
实际含义:用于XX,表示XXXX
数据类型:Character(字符串)
数据格式:XX
数据约束:由于xxx,,大小在xx以内
)
34数据管理能力要求
说明需要管理的文卷和记录的个数、表和文卷的大小规模,要按可预见的增长对数据及其分量的存储要求作出估算。
(
根据实际系统要求列举即可
Name名称
Number数量
Size大小
Increase增长
词典xx
xx
xxxx
并行执行,其大小依据实际xx大文本而增长
)
35故障处理要求
列出可能的软件、硬件故障以及对各项性能而言所产生的后果和对故障处理的要求。
(包括软件压力,内存不足,硬件损坏等,这部分可以根据百度到其常见故障。)
36其他专门要求
如用户单位对安全保密的要求,对使用方便的要求,对可维护性、可补充性、易读性、可靠性、运行环境可转换性的特殊要求等。
(例如安全保密性:密钥更换等;预期扩展:扩展兼容等;OS更换:Slackware转SUSE等
)
4运行环境规定
41设备
列出运行该软件所需要的硬设备。说明其中的新型设备及其专门功能,包括:
a.处理器型号及内存容量;
b.外存容量、联机或脱机、媒体及其存储格式,设备的型号及数量;
c.输入及输出设备的型号和数量,联机或脱机;
d.数据通信设备的型号和数量;
e.功能键及其他专用硬件
(列举说明即可)
42支持软件
列出支持软件,包括要用到的 *** 作系统、编译(或汇编)程序、测试支持软件等。
( *** 作系统和版本:xxxx
支撑环境和版本:xxxx
备用IDE环境和版本:xxxx
与该软件有关的软件组件:xxxx
后续可能扩展环境:xxxx
)
43接口
说明该软件同其他软件之间的接口、数据通信协议等。
(例如:
a.用户和主程序调用接口(图中接口1)。这个接口采用封装API形式和函数调用形式,分别以外部调用和内部调用的方式为不同用户提供使用本机械分词工具的入口。例如以xxxx方式调用DLL文件,以xxxx方式调用函数。如下图2所示。
图2软件接口调用图
bxx接口(图中接口2)。这里是一个xxx的接口调用过程。xxxx
)
44控制
说明控制该软件的运行的方法和控制信号,并说明这些控制信号的来源。
(例如:
下面通过图表的形式,将本模块以及涉及到本模块的软件模块的运行方法、控制信号,以及这些控制信号的来源,其中箭头所指方向对应的模块的控制信号来自箭头另一方向的模块,具体情况如下:
图3控制流程图
图3的具体说明情况如下表所示:
Name模块名称
Method运行方式
Signal控制信号
Forward控制去向
主程序模块
运行框架
用户调用或运行
1调用xx模块
2调用xx方法
3调用标准输出模块
xxx模块
xxx
xxx调用
Xxx模块
分布式是指不同的业务分布在不同的地方,集群指的是将几台服务器集中在一起,实现同一业务。白话理解的话,比如公司项目上线初期(举例电子商务网站)初期:用户访问量低,只弄了一台服务器,一个tomcat项目运行一个web工程。
中期:用户访问量提高,服务器崩了,为了解决这个问题,购买服务器,增加服务器数量,然后每个服务器中个各放了一份,使用nginx代理转发。(这就是运用集群原理)
后期:用户访问量不断增加,响应速度变慢,服务器又崩了,在不考虑增加服务器带宽、内存和CPU的情况下如何解决这个问题?先解决响应速度变慢,用户频繁调用数据库,在客户端与数据库之间,使用redis缓存。解决之后,又发现问题:由于每台服务器运行一个tomcat,放着一个web工程,用户有可能在商品详情存在大幅度调用数据库,而订单列表调用幅度小,此时就存在着模块之间耦合度高,一个功能升级其他也需要升级,扩展性差,不能灵活部署。是该考虑项目重构,把项目按照模块分为不同的系统(使用zookeeper进行模块之间通信),例如:订单系统,会员系统、搜索系统、商品信息系统。把每个模块进行拆分,用户在哪个系统访问频繁,就针对哪个系统进行对症下药,增加缓存还是使用其他技术。(这样我们就可以单独对这个模块进行服务性能的提升,不用全部都一起提升。也降低了代码的耦合度,模块之间互不影响,即使后期增加开发人员,也可按照敏捷开发思想只对其负责模块进行开发,效率大大提升)。这样一个web工程就拆分成多个web工程(多个tomcat部署)。那这个项目就可以在一台服务器部署多个工程(不同端口进行通信)或者多台服务器运行单个项目。(这就是分布式原理)
总而言之,分布式是以缩短单个任务的执行时间来提升效率的,而集群则是通过提高单位时间内执行的任务数来提升效率。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)